Mi a CI/CD? Folyamatos integráció és kézbesítés egyszerűen

A CI/CD olyan szoftverkiadási módszer, amelyben minden kódmódosítást automatikusan lefordítanak, tesztelnek, és – ha átmegy a teszten – előkészítenek a kiadásra vagy kiadják. A CI (folyamatos integráció) azt jelenti, hogy a változtatásokat gyakran egyesítik, és minden alkalommal automatikus tesztek ellenőrzik őket. A CD (folyamatos kézbesítés vagy telepítés) azt jelenti, hogy a sikeres változtatásokat csomagolják és a felhasználók felé juttatják, kevés vagy semmi kézi munkával.

A lényeg egyszerű: a hibákat percekkel az elkövetésük után elkapni, nem hetekkel később, amikor egy vásárló találja meg őket.

Miért fontos a CI/CD, ha AI-val építesz

Az AI-építők gyorsan módosítanak a kódon. Egy egyetlen prompt akár tíz fájlt is érinthet. Ez a sebesség remek, amíg a fizetési oldal egy módosítása csendben el nem rontja a bejelentkezési oldalt, és senki nem veszi észre, amíg egy felhasználó meg nem ír neked.

A CI/CD pontosan erre a hálóra való. Ahelyett, hogy azt feltételeznéd, hogy minden változtatás rendben van, egy folyamat minden alkalommal ugyanazokat az ellenőrzéseket futtatja:

• Hibák nélkül lefordul még az app?
• Még mindig átmennek az automatikus tesztek?
• Betartja a kód a projekt szabályait (típusok, formázás, biztonsági ellenőrzések)?

Ha bármelyik ellenőrzés elbukik, a változtatást még azelőtt megállítják, hogy a felhasználókhoz érne. Minél gyorsabban változik a kódod, annál értékesebb egy olyan ellenőrzés, amely sosem fárad el és nem hagy ki lépést.

Mindennapi hasonlat

Gondolj egy pékségre, amely minden reggel kenyeret ad el a boltoknak.

• CI/CD nélkül minden pék egy hétig a saját receptjén finomít, majd pénteken este mindenki összerakja a változtatásait, és reméli, hogy a kenyér megkel. Ha nem kel meg, senki nem tudja, kinek a változtatása okozta.
• CI-vel minden apró receptmódosítást azonnal sütnek egy tesztkenyérben, és ellenőrzik: íz, tömeg, forma. A rossz változtatást még aznap elkapják, és pontosan tudják, melyik volt az.
• CD-vel az ellenőrzésen átjutott kenyerek egyenesen a szállítóautóra kerülnek, mindig ugyanúgy csomagolva és címkézve, ahelyett, hogy valaki reggel 5-kor kézzel pakolná a dobozokat.

Az ellenőrzés nem teszi jobb pékekké őket. Olcsóvá teszi a hibáikat.

Hogyan működik a CI/CD-folyamat

A folyamat (pipeline) olyan lépések sorozata, amelyet egy CI/CD-szolgáltatás automatikusan futtat, amikor valami történik – általában amikor valaki kódot tölt fel egy tárolóba, például a GitHubra. Egy tipikus folyamat így néz ki:

Minden lépés tiszta gépen fut, nem valakinek a laptopján, így a „nálam működik” már nem kifogás. Ha egy lépés elbukik, a folyamat megáll, és szól annak, aki a változtatást készítette.

A lépéseket egy konfigurációs fájl írja le, amely a kóddal együtt él. A GitHub Actionsben például ez egy YAML-fájl a tároló .github/workflows mappájában.

Folyamatos kézbesítés vs folyamatos telepítés

A „CD” kétértelmű, és az emberek mindkét értelemben használják:

A folyamatos telepítés csak akkor működik jól, ha a tesztek jók. Ha a teszteid nem fedik le a fizetést, a folyamatos telepítés vidáman kiad egy törött fizetési oldalt.

Példa: foglalóapp folyamattal

Tegyük fel, hogy van egy szalonfoglaló appod, a kódja pedig egy GitHub-tárolóban van. Az AI-építőnek ezt kéred: „Adj 10% kedvezményt az első alkalommal érkező vásárlóknak.”

1. A változtatás egy új ágra kerül feltöltésre, és lehívási kérés (pull request) nyílik.
2. Elindul a folyamat. Telepíti a csomagokat és lefordítja az appot – ez átmegy.
3. Lefuttatja a teszteket. Egy teszt, „a visszatérő vásárló teljes árat fizet”, elbukik: a kedvezmény mindenkire érvényes.
4. A lehívási kérésen piros kereszt látszik. A változtatás nem egyesíthető.
5. Megkéred az AI-t, hogy javítsa. Feltölt egy javítást; a folyamat újra fut, és minden átmegy.
6. A változtatást egyesítik. A folyamat staging környezetbe telepíti, ahol kipróbálsz egy tesztfoglalást.
7. Jóváhagyod, és az élesbe települ.

A folyamat nélkül a 3. lépés a vásárlóid pénztárcájában történt volna meg.

Kulcsfogalmak

Gyakori tévhitek

• „A CI/CD azt jelenti, hogy az appom tesztelve van.” A folyamat csak azokat a teszteket futtatja, amelyek vannak. Ha nincs teszt, a CI csak azt bizonyítja, hogy az app lefordul – többet semmit. Kérd meg az AI-t, hogy írjon teszteket a legfontosabb folyamatokhoz.
• „A CI/CD csak nagy cégeknek való.” Az olyan hosztolt eszközök, mint a GitHub Actions, rövid konfigurációs fájllal beállíthatók, és a kis csapatok folyamatosan használják őket. A munkát a tesztek jelentik, nem az eszköz.
• „Az automatikus telepítés azt jelenti, hogy senki nem ellenőriz semmit.” A jó folyamatok ellenőrzéseket adnak hozzá, nem vesznek el. Sok csapat megtartja az emberi jóváhagyást az élesítés előtt.
• „Ha a folyamat zöld, az app működik.” Azt jelenti, hogy az automatikus ellenőrzések átmentek. A változtatást akkor is magadnak kell kipróbálnod, lehetőleg előnézetben vagy staging-en.
• „A CI/CD helyettesíti a mentéseket.” Nem. Egy rossz adatbázis-migráció, amely átmegy a teszteken, még mindig károsíthatja a valódi adatokat. Tarts mentéseket és visszaállítási lehetőséget.

Mit kérj az AI-építőtől

• „Írj automatikus teszteket a regisztrációra, bejelentkezésre és a pénztárra, és mutasd meg, hogyan kell futtatni őket.”
• „Állíts be egy GitHub Actions munkafolyamatot, amely minden lehívási kérésnél telepíti a függőségeket, lefordítja az appot és lefuttatja a teszteket.”
• „Adj típusellenőrzést és linter a folyamathoz, és hibánál buktassa meg.”
• „Magyarázd el közérthetően, mit csinál a folyamat minden lépése.”
• „Mi történik, ha a telepítés félúton elbukik? Hogyan görgetem vissza?”
• „Ellenőrizd, hogy nincsenek-e titkok beégetve a tárolóba, vagy kiírva a folyamat naplóiba.”

Ha az appod API-kulcsokat használ, a folyamatnak is szüksége van rájuk – titkosított titokként tárolva a CI-eszközben, soha nem a konfigurációs fájlban. Lásd környezeti változók és titkok.

CI/CD és a Mythex

A Mythex nem futtat helyetted CI-folyamatot, de több ugyanilyen igényt a maga módján lefed:

• Ellenőrzőpontok. Minden sikeres ügynöki kör után a Mythex git-ellenőrzőpontot ment, és a Visszaállítás erre a pontra visszaforgatja a projektet, ha egy változtatás rosszul sült el. Lásd Chat.
• Alkalmazástesztelés. Írd be a /test parancsot, és az ügynök úgy kattintgat át az élő előnézeten, mint egy felhasználó, és jelenti a hibás folyamatokat – hasznos minden közzététel előtt. Lásd Alkalmazástesztelés.
• A közzététel tudatos lépés. A változtatások először a privát előnézetben jelennek meg; a nyilvános appod csak újbóli közzétételkor frissül – ez inkább a folyamatos kézbesítéshez, mint a folyamatos telepítéshez áll közel.
• GitHub-szinkronizálás (Pro). Ha a projektet szinkronizálod egy GitHub-tárolóval, saját GitHub Actions munkafolyamatokat adhatsz hozzá, amelyek minden feltöltésnél tesztelnek. Lásd GitHub és exportálás.

Az élesítés előtt kézzel tesztelendő dolgok listájához lásd hogyan teszteld az appodat indítás előtt, a verziókezeléssel való munkához pedig hogyan használj Gitet AI-val épített appnál.

Kérdések