Šta je CI/CD? Kontinuirana integracija i isporuka objašnjene jednostavno

CI/CD je način isporuke softvera u kojem se svaka izmena koda automatski gradi, testira i, ako prođe, priprema za izdanje ili puštanje. CI (kontinuirana integracija) znači da se izmene često spajaju i da ih automatski testovi proveravaju svaki put. CD (kontinuirana isporuka ili postavljanje) znači da se izmene koje prođu šalju ka korisnicima uz malo ili nimalo ručnog rada.

Smisao je jednostavan: uhvatiti greške nekoliko minuta posle nastanka, a ne nedeljama kasnije kada ih kupac primeti.

Zašto je CI/CD važan kada praviš aplikaciju uz AI

AI alati brzo prave izmene koda. Jedan prompt može da dotakne deset fajlova. Ta brzina je odlična sve dok izmena stranice za plaćanje tiho ne pokvari prijavu, a niko to ne primeti dok korisnik ne pošalje imejl.

CI/CD je mreža sigurnosti upravo za to. Umesto da veruješ da je svaka izmena u redu, pipeline pokreće iste provere svaki put:

• Da li se aplikacija i dalje gradi bez grešaka?
• Da li automatski testovi i dalje prolaze?
• Da li kod prati pravila projekta (tipovi, formatiranje, bezbednosne provere)?

Ako bilo koja provera ne uspe, izmena se zaustavlja pre nego što stigne do korisnika. Što su izmene koda brže, to je vrednija provera koja nikada ne umara i ne preskače korak.

Svakodnevna analogija

Zamisli pekaru koja svakog jutra snabdeva hleb prodavnice.

• Bez CI/CD, svaki pekar sedmicu radi na svojim izmenama recepta, pa se sve spoji u petak uveče i svi se nadaju da će hleb da naraste. Kada ne naraste, niko ne zna čija je izmena kriva.
• Sa CI, svaka mala izmena recepta odmah se peče u probnoj peciva i proverava: ukus, težina, oblik. Loša izmena se uhvati istog dana, i tačno se zna koja je bila.
• Sa CD, hlebovi koji prođu kontrolu odmah idu u kombi za isporuku, upakovani i obeleženi uvek na isti način, umesto da neko u 5 ujutru pakuje kutije ručno.

Kontrola ne čini pekare boljim. Ona čini njihove greške jeftinim.

Kako radi CI/CD pipeline

Pipeline je niz koraka koje CI/CD servis automatski pokreće kad se nešto desi, obično kada neko pošalje kod u repozitorijum poput GitHub-a. Tipičan pipeline izgleda ovako:

Svaki korak se izvršava na čistoj mašini, a ne na nečijem laptopu, pa „kod mene radi“ više nije izgovor. Ako korak ne uspe, pipeline se zaustavlja i javlja onome ko je napravio izmenu.

Koraci su definisani u konfiguracionom fajlu koji živi uz kod. Na primer, u GitHub Actions to je YAML fajl u folderu .github/workflows repozitorijuma.

Kontinuirana isporuka naspram kontinuiranog postavljanja

Deo „CD“ je višeznačan, a ljudi ga koriste na oba načina:

Kontinuirano postavljanje dobro radi samo ako su testovi dobri. Ako testovi ne pokrivaju plaćanje, kontinuirano postavljanje će veselo isporučiti pokvareno plaćanje.

Praktičan primer: aplikacija za rezervacije sa pipeline-om

Zamisli aplikaciju za rezervacije u salonu, čiji je kod u GitHub repozitorijumu. Od AI alata zatražiš: „Dodaj popust od 10% za kupce koji dolaze prvi put.“

1. Izmena se šalje na novu granu i otvara se pull request.
2. Pipeline počinje. Instalira pakete i gradi aplikaciju, što prolazi.
3. Pokreće testove. Jedan test, „kupac koji se vraća plaća punu cenu“, ne prolazi: popust se primenjuje na sve.
4. Pull request pokazuje crveni krst. Izmena ne može da se spoji.
5. Zamoliš AI da to popravi. On šalje ispravku; pipeline se ponovo pokreće i sve prolazi.
6. Izmena se spaja. Pipeline je postavlja na staging okruženje, gde probaš test rezervaciju.
7. Odobravaš i postavlja se na produkciju.

Bez pipeline-a, korak 3 bi se dogodio u novčanicima tvojih kupaca.

Ključni pojmovi

Česte zablude

• „CI/CD znači da je moja aplikacija testirana.“ Pipeline pokreće samo testove koje imaš. Ako nema testova, CI dokazuje samo da se aplikacija gradi, ništa više. Zamoli AI da napiše testove za tokove koji su najvažniji.
• „CI/CD je samo za velike kompanije.“ Hostovani alati poput GitHub Actions zahtevaju kratak konfiguracioni fajl i mali timovi ih koriste svakodnevno. Napor je u testovima, a ne u alatu.
• „Automatsko postavljanje znači da niko ništa ne proverava.“ Dobri pipeline-ovi dodaju provere, ne uklanjaju ih. Mnogi timovi zadržavaju ljudsko odobravanje pre produkcije.
• „Ako je pipeline zelen, aplikacija radi.“ To znači da su automatske provere prošle. I dalje treba sam da probaš izmenu, po mogućnosti u pregledu ili na stagingu.
• „CI/CD zamenjuje rezervne kopije.“ Ne zamenjuje. Loša migracija baze koja prođe testove i dalje može da ošteti prave podatke. Čuvaj rezervne kopije i način za vraćanje.

Šta tražiti od svog AI alata

• „Napiši automatske testove za registraciju, prijavu i plaćanje, i pokaži mi kako da ih pokrenem.“
• „Postavi GitHub Actions workflow koji instalira zavisnosti, gradi aplikaciju i pokreće testove na svakom pull requestu.“
• „Dodaj proveru tipova i linter u pipeline i neka padne na greškama.“
• „Objasni jednostavnim jezikom šta radi svaki korak pipeline-a.“
• „Šta se dešava ako postavljanje pukne na pola? Kako da vratim promenu?“
• „Proveri da nijedna tajna nije ugrađena u repozitorijum niti ispisana u logovima pipeline-a.“

Ako tvoja aplikacija koristi API ključeve, pipeline im takođe treba, sačuvane kao šifrovane tajne u CI alatu, nikada u konfiguracionom fajlu. Pogledaj promenljive okruženja i tajne.

CI/CD i Mythex

Mythex ne pokreće CI pipeline umesto tebe, ali pokriva nekoliko istih potreba na svoj način:

• Checkpoint-i. Posle svakog uspešnog koraka agenta, Mythex čuva git checkpoint, a Vrati na ovu tačku vraća projekat unazad ako je izmena pošla po zlu. Pogledaj Chat.
• App Testing. Ukucaj /test i agent klikće kroz tvoj živi pregled kao korisnik i prijavljuje pokvarene tokove, korisno pre svakog objavljivanja. Pogledaj App Testing.
• Objavljivanje je namerni korak. Izmene se prvo pojavljuju u privatnom pregledu; tvoja javna aplikacija se menja tek kada ponovo objaviš. To je bliže kontinuiranoj isporuci nego kontinuiranom postavljanju.
• GitHub sinhronizacija (Pro). Sinhronizuj projekat sa GitHub repozitorijumom i možeš da dodaš sopstvene GitHub Actions workflow-e za pokretanje testova pri svakom push-u. Pogledaj GitHub i izvoz.

Za kontrolnu listu onoga što treba ručno testirati pre objavljivanja, pogledaj kako testirati aplikaciju pre lansiranja, a za rad sa verzijama, kako koristiti Git sa aplikacijom pravljenom uz AI.

Pitanja