Kas yra CI/CD? Nuolatinė integracija ir diegimas paprastai paaiškinti

CI/CD – tai programinės įrangos pristatymo būdas, kai kiekvienas kodo pakeitimas automatiškai sukuriamas, patikrinamas ir – jei praeina – paruošiamas išleidimui arba išleidžiamas. CI (nuolatinė integracija) reiškia, kad pakeitimai dažnai sujungiami ir kiekvieną kartą tikrinami automatiniais testais. CD (nuolatinis pristatymas arba diegimas) reiškia, kad pakeitimai, kurie praeina, supakuojami ir nukreipiami link naudotojų su mažai arba visai be rankinio darbo.

Esmė paprasta: pagauti klaidas minutes po jų padarymo, o ne savaites vėliau, kai jas aptinka klientas.

Kodėl CI/CD svarbus kuriant su DI

DI kūrimo įrankiai keičia kodą greitai. Vienas užklausimas gali paliesti dešimt failų. Tas greitis puikus, kol pakeitimas apmokėjimo puslapyje tyliai sugadina prisijungimo puslapį, ir niekas to nepastebi, kol naudotojas jums nerašo el. laiško.

CI/CD yra saugos tinklas būtent tam. Vietoj to, kad tikėtumėte, jog kiekvienas pakeitimas tvarkingas, konvejeris kiekvieną kartą atlieka tuos pačius patikrinimus:

• Ar programa vis dar sukuriama be klaidų?
• Ar automatiniai testai vis dar praeina?
• Ar kodas atitinka projekto taisykles (tipus, formatavimą, saugumo patikrinimus)?

Jei kuris nors patikrinimas nepavyksta, pakeitimas sustabdomas dar prieš pasiekiant naudotojus. Kuo greičiau keičiasi jūsų kodas, tuo vertingesnis tampa patikrinimas, kuris niekada nepavargsta ir nepraleidžia žingsnio.

Kasdienis palyginimas

Pagalvokite apie kepyklą, kuri kiekvieną rytą parduoda duoną parduotuvėms.

• Be CI/CD kiekvienas kepėjas savaitę tobulina savo receptą, o penktadienio vakarą visi sujungia pakeitimus ir tikisi, kad duona vis dar kils. Kai nekyla, niekas nežino, kieno pakeitimas tai sukėlė.
• Su CI kiekvienas mažas receptūros pakeitimas iš karto kepamas bandomajame batone ir patikrinamas – skonis, svoris, forma. Blogas pakeitimas pastebimas tą pačią dieną, ir tiksliai žinote, kuris tai buvo.
• Su CD batonai, kurie praeina patikrinimą, iš karto keliauja į pristatymo furgoną, supakuoti ir pažymėti visada vienodai, o ne kažkas penktą ryto rankiniu būdu pakuoja dėžes.

Patikrinimas nepadaro kepėjų geresnių. Jis padaro jų klaidas pigias.

Kaip veikia CI/CD konvejeris

Konvejeris – tai žingsnių sąrašas, kurį CI/CD paslauga automatiškai vykdo, kai kas nors įvyksta – paprastai kai kas nors įkelia kodą į repozitoriją, pavyzdžiui, GitHub. Tipinis konvejeris atrodo taip:

Kiekvienas žingsnis vykdomas švarioje mašinoje, o ne kieno nors nešiojamajame, todėl „veikia mano kompiuteryje“ nebėra pasiteisinimas. Jei žingsnis nepavyksta, konvejeris sustoja ir praneša tam, kas padarė pakeitimą.

Žingsniai aprašyti konfigūracijos faile, kuris gyvena kartu su kodu. Pavyzdžiui, GitHub Actions tai YAML failas repozitorijos aplanke .github/workflows.

Nuolatinis pristatymas ir nuolatinis diegimas

„CD“ yra dviprasmiškas, ir žmonės jį naudoja abiem prasmėmis:

Nuolatinis diegimas veikia gerai tik tuomet, kai testai geri. Jei jūsų testai nepadengia apmokėjimo, nuolatinis diegimas nuoširdžiai išleis sugedusį apmokėjimą.

Darbo pavyzdys: rezervacijų programa su konvejeriu

Tarkime, turite kirpyklos rezervacijų programą, o jos kodas yra GitHub repozitorijoje. Prašote DI kūrimo įrankio: „pridėk 10 % nuolaidą pirmą kartą atvykstantiems klientams.“

1. Pakeitimas įkeliamas į naują šaką ir atidaromas pull request.
2. Paleidžiamas konvejeris. Jis įdiegia paketus ir sukuria programą – tai praeina.
3. Paleidžiami testai. Vienas testas, „grįžtantis klientas moka pilną kainą“, nepraeina: nuolaida taikoma visiems.
4. Pull request rodo raudoną kryžių. Pakeitimo negalima sujungti.
5. Paprašote DI tai ištaisyti. Jis įkelia pataisą; konvejeris paleidžiamas iš naujo ir viskas praeina.
6. Pakeitimas sujungiamas. Konvejeris jį diegia į testavimo aplinką, kur išbandote bandomą rezervaciją.
7. Patvirtinate, ir jis diegiamas į gamybą.

Be konvejerio 3 žingsnis būtų įvykęs klientų piniginėse.

Pagrindiniai terminai

Dažni klaidingi įsitikinimai

• „CI/CD reiškia, kad mano programa ištestuota.“ Konvejeris vykdo tik tuos testus, kuriuos turite. Jei testų nėra, CI įrodo tik tai, kad programa sukuriama – nieko daugiau. Paprašykite DI parašyti testus srautams, kurie svarbiausi.
• „CI/CD skirtas tik didelėms įmonėms.“ Hostinguojami įrankiai, pavyzdžiui, GitHub Actions, sąrankai reikalauja trumpo konfigūracijos failo, o mažos komandos jais naudojasi nuolat. Pastangų reikalauja testai, o ne įrankiai.
• „Automatinis diegimas reiškia, kad niekas nieko netikrina.“ Geri konvejeriai prideda patikrinimus, o ne juos pašalina. Daugelis komandų prieš gamybą palieka žmogaus patvirtinimo žingsnį.
• „Jei konvejeris žalias, programa veikia.“ Tai reiškia, kad automatiniai patikrinimai praėjo. Vis tiek pats turėtumėte išbandyti pakeitimą, geriausia peržiūroje ar testavimo aplinkoje.
• „CI/CD pakeičia atsargines kopijas.“ Nepakeičia. Duomenų bazės migracija, kuri praeina testus, vis tiek gali sugadinti tikrus duomenis. Laikykite atsargines kopijas ir būdą grįžti atgal.

Ko paprašyti iš DI kūrėjo

• „Parašyk automatinius testus registracijai, prisijungimui ir apmokėjimui ir parodyk, kaip juos paleisti.“
• „Nustatyk GitHub Actions darbo eigą, kuri įdiegia priklausomybes, sukuria programą ir paleidžia testus kiekvienam pull request.“
• „Pridėk tipų tikrinimą ir linterį prie konvejerio ir padaryk, kad jis nepavyktų dėl klaidų.“
• „Paaiškink paprasta kalba, ką daro kiekvienas konvejerio žingsnis.“
• „Kas nutinka, jei diegimas nepavyksta per pusę? Kaip atšaukti?“
• „Patikrink, kad jokie slaptažodžiai nėra įrašyti į repozitoriją ar išspausdinti konvejerio žurnaluose.“

Jei jūsų programa naudoja API raktus, konvejeriui jų taip pat reikia – saugomų užšifruotų paslapčių CI įrankyje, o ne konfigūracijos faile. Žr. aplinkos kintamuosius ir paslaptis.

CI/CD ir Mythex

Mythex tau nevykdo CI konvejerio, bet patenkina keletą tų pačių poreikių savaip:

• Kontrolės taškai. Po kiekvieno sėkmingo agento ciklo Mythex išsaugo git kontrolės tašką, o Grįžti į šį tašką atkuria projektą, jei pakeitimas nepavyko. Žr. Pokalbis.
• Programos testavimas. Įveskite /test, ir agentas naršys tavo gyvą peržiūrą kaip naudotojas bei praneš apie sugedusius srautus – naudinga prieš kiekvieną publikavimą. Žr. Programos testavimas.
• Publikavimas yra sąmoningas žingsnis. Pakeitimai pirmiausia atsiranda privačioje peržiūroje; viešoji programa atsinaujina tik vėl publikavus – arčiau nuolatinio pristatymo nei nuolatinio diegimo.
• GitHub sinchronizacija (Pro). Sinchronizuokite projektą su GitHub repozitorija ir galėsite pridėti savo GitHub Actions darbo eigas, kad testai vyktų kiekvieno įkėlimo metu. Žr. GitHub ir eksportas.

Rankiniam testavimo prieš paleidimą sąrašui žr. kaip ištestuoti programą prieš paleidimą, o darbui su versijų valdymu – kaip naudoti Git su DI kuriama programa.

Klausimai