Kas ir CI/CD? Nepārtrauktā integrācija un piegāde vienkārši izskaidrota

CI/CD ir programmatūras piegādes veids, kurā katra koda izmaiņa tiek automātiski veidota, pārbaudīta un — ja tā iztur pārbaudi — sagatavota izlaišanai vai izlaista. CI (nepārtrauktā integrācija) nozīmē, ka izmaiņas bieži tiek apvienotas un katru reizi pārbaudītas ar automatizētiem testiem. CD (nepārtrauktā piegāde vai izvietošana) nozīmē, ka izmaiņas, kas iztur pārbaudi, tiek iepakotas un virzītas uz jūsu lietotājiem ar nelielu vai bez manuāla darba.

Ideja ir vienkārša: noķert kļūdas minūtes pēc to rašanās, nevis nedēļas vēlāk, kad tās atrod klients.

Kāpēc CI/CD ir svarīgs, veidojot ar MI

MI veidotāji koda izmaiņas veic ātri. Viena uzvedne var skart desmit failus. Šis ātrums ir lielisks, līdz izmaiņa norēķina lapā klusi salauž pieteikšanās lapu un neviens to nepamana, kamēr lietotājs jums neuzraksta e-pastu.

CI/CD ir drošības tīkls tieši šai situācijai. Tā vietā, lai paļautos, ka katra izmaiņa ir kārtībā, cauruļvads katru reizi veic vienas un tās pašas pārbaudes:

• Vai lietotne joprojām veidojas bez kļūdām?
• Vai automatizētie testi joprojām iztur?
• Vai kods ievēro projekta noteikumus (tipus, formatējumu, drošības pārbaudes)?

Ja kāda pārbaude neizdodas, izmaiņa tiek apturēta, pirms tā sasniedz lietotājus. Jo ātrāk mainās jūsu kods, jo vērtīgāka ir pārbaude, kas nekad nenogurst un neizlaiž soli.

Ikdienas salīdzinājums

Iedomājieties maiznīcu, kas katru rītu piegādā maizi veikaliem.

• Bez CI/CD katrs maiznieks nedēļu strādā pie savām receptes izmaiņām, tad piektdienas vakarā visi tās apvieno un cer, ka maize joprojām pacelsies. Kad tā nepaceļas, neviens nezina, kura izmaiņa to izraisīja.
• Ar CI katra maza receptes izmaiņa uzreiz tiek izcepta testa klaipā un pārbaudīta — garša, svars, forma. Slikta izmaiņa tiek atklāta tajā pašā dienā, un jūs precīzi zināt, kura tā bija.
• Ar CD klaipi, kas iztur pārbaudi, tieši nonāk piegādes furgonā, iepakoti un marķēti vienmēr vienādi, nevis kāds piecos no rīta iepako kastes ar rokām.

Pārbaude nepadara maiznieku labāku. Tā padara viņu kļūdas lētas.

Kā darbojas CI/CD cauruļvads

Cauruļvads ir soļu saraksts, ko CI/CD pakalpojums automātiski izpilda, kad kaut kas notiek — parasti, kad kāds nosūta kodu uz repozitoriju, piemēram, GitHub. Tipisks cauruļvads izskatās šādi:

Katrs solis darbojas uz tīras mašīnas, nevis kāda klēpjdatora, tāpēc attaisnojums „tas strādā manā datorā” beidzas. Ja kāds solis neizdodas, cauruļvads apstājas un paziņo tam, kurš izmaiņu veica.

Soļi ir definēti konfigurācijas failā, kas atrodas kopā ar kodu. Piemēram, GitHub Actions tas ir YAML fails repozitorija mapē .github/workflows.

Nepārtrauktā piegāde pret nepārtrauktu izvietošanu

„CD” ir neviennozīmīgs, un cilvēki to lieto abos veidos:

Nepārtrauktā izvietošana labi darbojas tikai tad, ja testi ir labi. Ja jūsu testi neaptver norēķinu, nepārtrauktā izvietošana labprāt izvietos salauztu norēķinu.

Praktisks piemērs: rezervāciju lietotne ar cauruļvadu

Pieņemsim, ka jums ir salona rezervāciju lietotne, un tās kods atrodas GitHub repozitorijā. Jūs lūdzat MI veidotāju: „Pievieno 10% atlaidi pirmreizējiem klientiem.”

1. Izmaiņa tiek nosūtīta uz jaunu atzaru, un tiek atvērts pull request.
2. Cauruļvads sākas. Tas instalē pakotnes un veido lietotni — šis solis izdodas.
3. Tas izpilda testus. Viens tests, „atgriezies klients maksā pilnu cenu”, neizdodas: atlaide tiek piemērota visiem.
4. Pull request rāda sarkanu krustiņu. Izmaiņu nevar apvienot.
5. Jūs lūdzat MI to salabot. Tas nosūta labojumu; cauruļvads atkal tiek palaists, un viss izdodas.
6. Izmaiņa tiek apvienota. Cauruļvads to izvieto staging vidē, kur jūs izmēģināt testa rezervāciju.
7. Jūs apstiprināt, un tā tiek izvietota produkcijā.

Bez cauruļvada 3. solī šī kļūda būtu nonākusi jūsu klientu makās.

Galvenie termini

Biežākie maldi

• „CI/CD nozīmē, ka mana lietotne ir pārbaudīta.” Cauruļvads izpilda tikai tos testus, kas jums ir. Ja testu nav, CI pierāda tikai to, ka lietotne tiek veidota — nekas vairāk. Lūdziet MI uzrakstīt testus vissvarīgākajām plūsmām.
• „CI/CD ir tikai lielām kompānijām.” Hostētiem rīkiem, piemēram, GitHub Actions, uzstādīšanai vajag īsu konfigurācijas failu, un mazas komandas tos lieto visu laiku. Pūles prasa testi, nevis rīki.
• „Automātiska izvietošana nozīmē, ka neviens nepārbauda neko.” Labi cauruļvadi pievieno pārbaudes, nevis noņem tās. Daudzas komandas pirms produkcijas saglabā cilvēka apstiprinājuma soli.
• „Ja cauruļvads ir zaļš, lietotne darbojas.” Tas nozīmē, ka automatizētās pārbaudes ir izietas. Izmaiņu joprojām vajadzētu izmēģināt pašam, ideālā gadījumā priekšskatījumā vai staging vidē.
• „CI/CD aizvieto dublējumus.” Nē. Slikta datubāzes migrācija, kas iztur testus, joprojām var sabojāt reālus datus. Glabājiet dublējumus un veidu, kā atgriezties.

Ko jautāt savam MI veidotājam

• „Uzraksti automatizētus testus reģistrācijai, pieteikšanās procesam un norēķinam un parādi, kā tos palaist.”
• „Uzstādi GitHub Actions darbplūsmu, kas katram pull request instalē atkarības, veido lietotni un izpilda testus.”
• „Pievieno cauruļvadam tipu pārbaudi un lintētāju un liec tam neizdoties kļūdu gadījumā.”
• „Vienkāršā valodā paskaidro, ko dara katrs cauruļvada solis.”
• „Kas notiek, ja izvietošana neizdodas pusceļā? Kā atgriezties?”
• „Pārbaudi, vai repozitorijā vai cauruļvada žurnālos nav iekodētu noslēpumu.”

Ja jūsu lietotnē tiek izmantotas API atslēgas, arī cauruļvadam tās vajag — glabātas CI rīka šifrētos noslēpumos, nekad konfigurācijas failā. Skatiet vides mainīgie un noslēpumi.

CI/CD un Mythex

Mythex jums CI cauruļvadu neizpilda, taču tas apmierina dažas no tām pašām vajadzībām savā veidā:

• Kontrolpunkti. Pēc katras veiksmīgas aģenta kārtas Mythex saglabā git kontrolpunktu, un Atgriezties šajā punktā atjauno projektu, ja izmaiņa nogāja greizi. Skatiet Čats.
• Lietotnes testēšana. Ierakstiet /test, un aģents klikšķina pa jūsu tiešraides priekšskatījumu kā lietotājs un ziņo par salauztām plūsmām — noderīgi pirms katras publicēšanas. Skatiet Lietotnes testēšana.
• Publicēšana ir apzināts solis. Izmaiņas vispirms parādās privātajā priekšskatījumā; jūsu publiskā lietotne atjaunojas tikai tad, kad publicējat vēlreiz — tuvāk nepārtrauktai piegādei nekā nepārtrauktai izvietošanai.
• GitHub sinhronizācija (Pro). Sinhronizējiet projektu ar GitHub repozitoriju, un varat pievienot savas GitHub Actions darbplūsmas, lai katrā nosūtīšanā palaistu testus. Skatiet GitHub un eksports.

Sarakstam par to, ko pārbaudīt ar rokām pirms tiešraides, skatiet kā pārbaudīt savu lietotni pirms palaišanas, bet darbam ar versiju kontroli — kā lietot Git MI veidotā lietotnē.

Jautājumi