Ano ang CI/CD? Continuous Integration at Delivery, Ipinaliwanag nang Simple

Ang CI/CD ay paraan ng paglalabas ng software kung saan awtomatikong binubuo, sinusubukan, at, kung pumasa, inihahanda para ilabas o inilalabas ang bawat pagbabago sa code. CI (continuous integration) ibig sabihin, madalas pinagsasama ang mga pagbabago at sinusuri ng automated tests sa bawat pagkakataon. CD (continuous delivery o deployment) ibig sabihin, ang mga pagbabagong pumasa ay pinapakete at itinutulak patungo sa users nang kaunti o walang manwal na trabaho.

Simple ang layunin: mahuli ang pagkakamali ilang minuto pagkatapos itong gawin, hindi linggo pagkatapos kapag nakita ito ng customer.

Bakit mahalaga ang CI/CD kapag gumagawa ka gamit ang AI

Mabilis gumawa ng pagbabago sa code ang AI builders. Isang prompt lang ay puwedeng gumalaw sa sampung file. Mainam iyon hanggang sa isang pagbabago sa checkout page ay tahimik na masira ang login page, at walang makakapansin hanggang may magpadala sa iyo ng email tungkol dito.

Ang CI/CD ang safety net para sa eksaktong sitwasyong ito. Sa halip na magtiwala na maayos ang bawat pagbabago, pareho ang tseke na pinapatakbo ng pipeline sa bawat pagkakataon:

• Nabubuo pa rin ba nang walang error ang app?
• Pumapasa pa rin ba ang automated tests?
• Sumusunod ba ang code sa mga patakaran ng project (types, formatting, security checks)?

Kapag may pumalyang tseke, hihinto ang pagbabago bago makarating sa users. Kung mas mabilis magbago ang code mo, mas mahalaga ang tseke na hindi napapagod at hindi lumalaktaw ng hakbang.

Isang halimbawang pang-araw-araw

Isipin ang isang panaderya na nagbebenta ng tinapay sa mga tindahan tuwing umaga.

• Kung walang CI/CD, ang bawat panadero ay magtatrabaho nang mag-isa sa sariling pagbabago ng recipe sa loob ng isang linggo, tapos sabay-sabay nila itong pagsasamahin tuwing Biyernes ng gabi at aasa na tataas pa rin ang tinapay. Kapag hindi ito tumaas, walang nakakaalam kung kaninong pagbabago ang may sala.
• Kung may CI, bawat maliit na pagbabago sa recipe ay agad na niluluto bilang test loaf at sinusuri: lasa, bigat, hugis. Nahuhuli ang masamang pagbabago sa parehong araw, at alam mo kung alin ito eksakto.
• Kung may CD, ang mga tinapay na pumasa sa inspeksyon ay dumidiretso sa delivery van, nakapakete at may label sa parehong paraan tuwing, sa halip na may nag-iimpake ng kahon nang manwal ng 5am.

Hindi ginagawang mas magaling ng inspeksyon ang mga panadero. Ginagawa lang nitong mura ang kanilang mga pagkakamali.

Paano gumagana ang CI/CD pipeline

Ang pipeline ay listahan ng mga hakbang na awtomatikong pinapatakbo ng isang CI/CD service kapag may nangyari, kadalasan kapag may nag-push ng code sa repository gaya ng GitHub. Ganito ang karaniwang pipeline:

Tumatakbo ang bawat hakbang sa malinis na makina, hindi sa laptop ng isang tao, kaya hindi na magagamit ang “gumagana sa computer ko.” Kapag pumalya ang isang hakbang, hihinto ang pipeline at sasabihin ito sa gumawa ng pagbabago.

Nakasulat ang mga hakbang sa configuration file na kasama ng code. Sa GitHub Actions, halimbawa, isa itong YAML file sa folder na .github/workflows ng repository.

Continuous delivery vs continuous deployment

Malabo ang “CD” at magkaiba ang gamit ng mga tao dito:

Gumagana nang maayos ang continuous deployment kapag maganda ang mga test. Kung hindi sakop ng tests mo ang checkout, masayang ilalabas ng continuous deployment ang sirang checkout.

Isang halimbawang gawa: booking app na may pipeline

Isipin mong may salon booking app ka, at nasa GitHub repository ang code nito. Hiniling mo sa AI builder na “magdagdag ng 10% discount para sa first-time customers.”

1. Ipinadala ang pagbabago sa bagong branch at nagbukas ng pull request.
2. Nagsimula ang pipeline. Nag-install ito ng packages at nagbuo ng app. Pumasa ito.
3. Pinatakbo nito ang tests. Isang test, “ang returning customer ay nagbabayad ng buong presyo,” ang pumalya: ina-apply ang discount sa lahat.
4. Nagpapakita ang pull request ng pulang krus. Hindi ito puwedeng i-merge.
5. Hiniling mong ayusin ito ng AI. Nag-push ito ng pagwawasto; tumakbo ulit ang pipeline at pumasa na ang lahat.
6. Na-merge ang pagbabago. Dinala ito ng pipeline sa staging environment, kung saan sumubok ka ng test booking.
7. Inaprubahan mo, at dinala ito sa production.

Kung wala ang pipeline, sa hakbang 3 ay mangyayari na ang discount bug sa bulsa ng mga customer mo.

Mahahalagang termino

Mga karaniwang maling akala

• “Ibig sabihin ng CI/CD na nasubukan na ang app ko.” Ang pipeline ay nagpapatakbo lang ng tests na mayroon ka. Kung walang tests, napapatunayan lang ng CI na nabubuo ang app, wala nang iba. Hilingin sa AI mo na gumawa ng tests para sa mga daloy na pinakamahalaga.
• “Para lang ito sa malalaking kumpanya.” Madaling i-set up ang mga hosted tool gaya ng GitHub Actions gamit ang maikling configuration file, at ginagamit ito ng maliliit na team nang madalas. Ang tests ang nangangailangan ng pagsisikap, hindi ang tooling.
• “Kapag awtomatiko ang deployment, walang nagche-check ng anuman.” Nagdaragdag ng tseke ang mabubuting pipeline, hindi nag-aalis. Maraming team ang nagpapanatili ng human approval step bago ang production.
• “Kapag berde ang pipeline, gumagana ang app.” Ibig sabihin lang nito ay pumasa ang automated checks. Dapat mo pa ring subukan ang pagbabago nang mag-isa, mas mabuti sa preview o sa staging.
• “Pumapalit ang CI/CD sa backups.” Hindi. Ang masamang database migration na pumasa sa tests ay puwede pa ring makasira ng totoong data. Panatilihin ang backups at paraan ng rollback.

Ano ang itatanong sa AI builder mo

• “Sumulat ng automated tests para sa sign-up, login at checkout, at ipakita kung paano patakbuhin ang mga ito.”
• “Mag-set up ng GitHub Actions workflow na nag-i-install ng dependencies, nagbubuo ng app at nagpapatakbo ng tests sa bawat pull request.”
• “Magdagdag ng type check at linter sa pipeline, at gawin itong pumalya kapag may error.”
• “Ipaliwanag sa simpleng Ingles ang bawat hakbang ng pipeline.”
• “Ano ang mangyayari kung kalahati lang ang na-deploy? Paano ako magro-rollback?”
• “Tiyakin na walang secrets na nakasulat sa code sa repository o naka-print sa pipeline logs.”

Kung gumagamit ng API keys ang app mo, kailangan din ng pipeline ang mga ito, naka-store bilang encrypted secrets sa CI tool, hindi sa configuration file. Tingnan ang environment variables at secrets.

CI/CD at Mythex

Hindi nagpapatakbo ang Mythex ng CI pipeline para sa iyo, pero tinutugunan nito ang ilan sa parehong pangangailangan sa sarili nitong paraan:

• Checkpoints. Pagkatapos ng bawat matagumpay na agent turn, nagse-save ang Mythex ng git checkpoint, at ibinabalik ng Revert to this point ang project kapag pumalpak ang pagbabago. Tingnan ang Chat.
• App Testing. I-type ang /test at ki-click-an ng agent ang live preview mo na parang user, at iuulat ang mga sirang daloy. Kapaki-pakinabang bago ang bawat publish. Tingnan ang App Testing.
• Sinadyang hakbang ang pag-publish. Unang lumalabas ang mga pagbabago sa pribadong preview; nagbabago lang ang public app mo kapag nag-publish ka ulit. Mas malapit ito sa continuous delivery kaysa sa continuous deployment.
• GitHub sync (Pro). I-sync ang project sa GitHub repository at puwede kang magdagdag ng sarili mong GitHub Actions workflows para magpatakbo ng tests sa bawat push. Tingnan ang GitHub and export.

Para sa checklist ng mga dapat mong subukan nang mano-mano bago mag-live, tingnan ang paano subukan ang app mo bago ilunsad, at para sa version control, tingnan ang paano gamitin ang Git sa app na gawa ng AI.

Mga tanong