Nepārtraukta integrācija (CI) un nepārtraukta piegāde (CD) iemieso kultūru, darbības principu kopumu un prakses apkopojumu, kas ļauj lietojumprogrammu izstrādes komandām biežāk un uzticamāk piegādāt kodu izmaiņas. Īstenošana ir pazīstama arī kā CI / CD cauruļvads.
CI / CD ir viena no labākajām praksēm, ko devops komandas var ieviest. Tā ir arī ātras metodoloģijas paraugprakse, jo tā ļauj programmatūras izstrādes komandām koncentrēties uz biznesa prasību izpildi, koda kvalitāti un drošību, jo izvietošanas darbības ir automatizētas.
KI / CD definēts
Nepārtraukta integrācija ir kodēšanas filozofija un prakses kopums, kas mudina izstrādes komandas ieviest nelielas izmaiņas un bieži pārbaudīt kodu versiju kontroles krātuvēs. Tā kā lielākajai daļai mūsdienu lietojumprogrammu ir nepieciešams izstrādāt kodu dažādās platformās un rīkos, komandai ir nepieciešams mehānisms, lai tās integrētu un apstiprinātu.
KI tehniskais mērķis ir izveidot konsekventu un automatizētu veidu, kā veidot, pakot un testēt lietojumprogrammas. Ievērojot integrācijas procesa konsekvenci, komandas biežāk veic koda izmaiņas biežāk, kas nodrošina labāku sadarbību un programmatūras kvalitāti.
Nepārtraukta piegādeuzņem, kur beidzas nepārtraukta integrācija. Kompaktdisks automatizē lietojumprogrammu piegādi izvēlētajām infrastruktūras vidēm. Lielākā daļa komandu strādā ar vairākām vidēm, izņemot ražošanu, piemēram, izstrādes un testēšanas vidi, un kompaktdiski nodrošina, ka ir automatizēts veids, kā panākt koda izmaiņas.
CI / CD rīki palīdz saglabāt videi raksturīgos parametrus, kas jāiepako katrā piegādē. Pēc tam CI / CD automatizācija veic visus nepieciešamos servisa izsaukumus uz tīmekļa serveriem, datu bāzēm un citiem pakalpojumiem, kas, iespējams, būs jārestartē vai jāievēro citas procedūras, kad tiek izvietotas lietojumprogrammas.
Nepieciešama nepārtraukta integrācija un nepārtraukta piegādenepārtraukta testēšanajo mērķis ir piegādāt lietotājiem kvalitatīvas lietojumprogrammas un kodu. Nepārtraukta testēšana bieži tiek īstenota kā automatizētas regresijas, veiktspējas un citu testu kopa, kas tiek izpildīta CI / CD cauruļvadā.
Nobriedušai CI / CD devops praksei ir iespēja ieviest nepārtrauktu izvietošanu, kad lietojumprogrammu izmaiņas notiek caur CI / CD cauruļvadu un pārejas būvējumi tiek izvietoti tieši ražošanas vidēs. Komandas, kas praktizē nepārtrauktu piegādi, izvēlas izmantot ražošanu pēc dienas vai pat stundas grafika, lai gan nepārtraukta piegāde ne vienmēr ir optimāla katrai uzņēmējdarbības lietošanai.
Saistītais video: kā ātrāk piegādāt kodu, izmantojot CI / CD
Kā nepārtraukta integrācija uzlabo sadarbību un kvalitāti
Nepārtraukta integrācija ir attīstības filozofija, kuru atbalsta procesu mehānika un zināma automatizācija. Praktizējot CI, izstrādātāji bieži ievada savu kodu versiju kontroles krātuvē, un lielākajai daļai komandu ir minimāls standarts koda piešķiršanai vismaz katru dienu. Pamatojums tam ir tāds, ka defektus un citas programmatūras kvalitātes problēmas ir vieglāk identificēt ar mazākiem kodu diferenciāliem, nevis lielākiem, kas izstrādāti ilgākā laika posmā. Turklāt, kad izstrādātāji strādā ar īsākiem saistību izpildes cikliem, maz ticams, ka vairāki izstrādātāji, veicot saistības, rediģē vienu un to pašu kodu un pieprasa apvienošanu.
Komandas, kas ievieš nepārtrauktu integrāciju, bieži sākas ar versiju vadības konfigurāciju un praktizē definīcijas. Kaut arī koda pārbaude tiek veikta bieži, funkcijas un labojumi tiek ieviesti gan īsā, gan ilgākā laika posmā. Izstrādes komandas, kas praktizē nepārtrauktu integrāciju, izmanto dažādas metodes, lai kontrolētu, kuras funkcijas un kods ir gatavi ražošanai.
Daudzas komandas izmanto iezīmju karogi, konfigurācijas mehānisms funkciju un koda ieslēgšanai vai izslēgšanai darbības laikā. Funkcijas, kas joprojām tiek izstrādātas, tiek iesaiņotas ar funkciju karodziņiem kodā, izvietotas kopā ar galveno atzaru līdz ražošanai un izslēgtas, līdz tās ir gatavas lietošanai. Saskaņā ar neseno aptauju 63 procenti komandu, kas izmanto funkciju karodziņus, ziņo par labāku testēšanu un augstākas kvalitātes programmatūru. Funkciju atzīmēšanas rīki, piemēram, CloudBees izlaišana, Optimizely izlaišana un LaunchDarkly, tiek integrēti ar CI / CD rīkiem un iespējo funkciju līmeņa konfigurācijas.
Vēl viena līdzekļu pārvaldības tehnika irversiju vadības atzarošana. Tāda filiāles stratēģija kā Gitflow tiek izvēlēta, lai definētu protokolus par to, kā jaunais kods tiek apvienots standarta filiālēs izstrādei, testēšanai un ražošanai. Tiem, kuriem būs nepieciešami ilgāki izstrādes cikli, tiek izveidotas papildu funkciju filiāles. Kad līdzeklis ir pabeigts, izstrādātāji var apvienot izmaiņas no funkciju filiālēm primārajā izstrādes nozarē. Šī pieeja darbojas labi, taču to var kļūt grūti pārvaldīt, ja vienlaikus tiek izstrādātas daudzas funkcijas.
Pēc tam pats būvēšanas process tiek automatizēts, iesaiņojot visu programmatūru, datu bāzi un citas sastāvdaļas. Piemēram, ja izstrādājat Java lietojumprogrammu, CI visus statiskos tīmekļa servera failus, piemēram, HTML, CSS un JavaScript, iesaiņotu kopā ar Java lietojumprogrammu un visiem datu bāzes skriptiem.
CI ne tikai iesaiņo visu programmatūru un datu bāzes komponentus, bet arī automatizācija veiks vienību testus un citas pārbaudes. Šī pārbaude sniedz atgriezenisko saiti izstrādātājiem, ka viņu koda izmaiņas neizjauca nevienu esošo vienības testu.
Lielākā daļa CI / CD rīku ļauj izstrādātājiem sākt veidot pēc pieprasījuma, ko izraisa koda saistības versiju vadības krātuvē vai pēc noteikta grafika. Komandām jāapspriež izveides grafiks, kas vislabāk atbilst komandas lielumam, sagaidāmo ikdienas saistību skaitam un citiem apsvērumiem par lietošanu. Labākā prakse, lai nodrošinātu ātru apņemšanos un izveidi, pretējā gadījumā tas var kavēt to komandu progresu, kuras mēģina ātri kodēt un bieži veikt saistības.
Nepārtraukta testēšana pārsniedz testa automatizāciju
Automatizētie testēšanas ietvari kvalitātes nodrošināšanas inženieriem palīdz noteikt, izpildīt un automatizēt dažāda veida testus, kas var palīdzēt izstrādes komandām uzzināt, vai programmatūras izveide ir veiksmīga vai neizdevusies. Tie ietver funkcionalitātes testus, kas tiek izstrādāti katra sprinta beigās un apkopoti a regresijas tests visai lietojumprogrammai. Pēc tam šie regresijas testi informē komandu, vai koda maiņa neizdevās vienā vai vairākos testos, kas izstrādāti visās lietojumprogrammas funkcionālajās jomās, kur ir testa pārklājums.
Vislabākā prakse ir ļaut izstrādātājiem prasīt visu regresijas testu vai tā apakškopu vietējā vidē. Šis solis nodrošina, ka izstrādātāji piešķir kodu versiju kontrolei tikai pēc tam, kad regresijas testi nodod koda izmaiņas.
Regresijas testi ir tikai sākums. Veiktspējas testēšanu, API testēšanu, statisko kodu analīzi, drošības testēšanu un citas testēšanas formas var arī automatizēt. Galvenais ir spēt aktivizēt šos testus, izmantojot komandrindu, tīmekļa āķi vai tīmekļa pakalpojumu, un lai tie atbildētu ar veiksmes vai neveiksmes statusa kodiem.
Kad testēšana ir automatizēta, nepārtraukta testēšana nozīmē, ka automatizācija ir integrēta CI / CD cauruļvadā. Dažas vienības un funkcionalitātes pārbaudes var integrēt KI, kas atzīmē problēmas pirms integrācijas procesa vai tā laikā. Testi, kuriem nepieciešama pilna piegādes vide, piemēram, veiktspēja un drošības pārbaude, bieži tiek integrēti CD un tiek veikti pēc būvējumu piegādes mērķa vidē.
CD cauruļvads automatizē izmaiņas vairākās vidēs
Nepārtraukta piegāde ir automatizācija, kas novirza lietojumprogrammas uz piegādes vidi. Lielākajai daļai izstrādes komandu parasti ir viena vai vairākas izstrādes un testēšanas vides, kur testēšanai un pārskatīšanai tiek veiktas lietojumprogrammu izmaiņas. Darbību automatizēšanai un pārskatu sniegšanai tiek izmantots CI / CD rīks, piemēram, Jenkins, CircleCI, AWS CodeBuild, Azure DevOps, Atlassian Bamboo vai Travis CI.
Tipiskam CD cauruļvadam ir izveidošanas, testēšanas un izvietošanas posmi. Sarežģītāki cauruļvadi ietver daudzas no šīm darbībām:
- Koda izvilkšana no versiju vadības un būvēšanas izpilde.
- Veicot visas nepieciešamās infrastruktūras darbības, kas tiek automatizētas kā kods, lai pieceltos vai nojauktu mākoņa infrastruktūru.
- Koda pārvietošana uz mērķa skaitļošanas vidi.
- Vides mainīgo pārvaldīšana un konfigurēšana mērķa videi.
- Lietojumprogrammu komponentu pārvietošana uz atbilstošajiem pakalpojumiem, piemēram, tīmekļa serveriem, API pakalpojumiem un datu bāzes pakalpojumiem.
- Veicot visas darbības, kas nepieciešamas, lai restartētu pakalpojumus vai izsauktu pakalpojumu galapunktus, kas nepieciešami jauniem koda nospiedumiem.
- Nepārtrauktu testu un atcelšanas vides veikšana, ja testi neizdodas.
- Žurnāla datu un brīdinājumu sniegšana par piegādes stāvokli.
Piemēram, Jenkins lietotāji definē savus cauruļvadus Jenkinsfile, kas apraksta dažādus posmus, piemēram, izveidi, testēšanu un izvietošanu. Vides mainīgie, opcijas, slepenās atslēgas, sertifikāti un citi parametri tiek deklarēti failā un pēc tam atsauces pa posmiem. Ziņas sadaļā tiek apstrādāti kļūdu nosacījumi un paziņojumi.
Sarežģītākam kompaktdiskam var būt citas darbības, piemēram, datu sinhronizēšana, informācijas resursu arhivēšana vai lietojumprogrammu un bibliotēku ielāpu veikšana. CI / CD rīki parasti atbalsta spraudņu tirgu. Piemēram, Jenkins uzskaita vairāk nekā 1500 spraudņus, kas atbalsta integrāciju ar trešo pušu platformām, lietotāja saskarni, administrēšanu, pirmkodu pārvaldību un būvniecības pārvaldību.
Kad ir atlasīts CI / CD rīks, izstrādes komandām jāpārliecinās, ka visi vides mainīgie ir konfigurēti ārpus lietojumprogrammas. CI / CD rīki ļauj iestatīt šos mainīgos, maskēt mainīgos, piemēram, paroles un konta atslēgas, un konfigurēt tos izvietošanas laikā mērķa videi.
Kompaktdisku rīki nodrošina arī informācijas paneli un ziņošanas funkcijas. Ja būvēšana vai piegāde neizdodas, viņi brīdina izstrādātājus ar informāciju par kļūmēm. Tie integrējas versiju kontrolē un veiklos rīkos, tāpēc tos var izmantot, lai uzzinātu, kādas koda izmaiņas un lietotāju stāsti veidoja būvējumu.
CI / CD cauruļvadu ieviešana ar Kubernetes un bez servera arhitektūrām
Daudzas komandas, kas mākoņu vidēs izmanto CI / CD cauruļvadus, izmanto arī tādus konteinerus kā Docker un orķestrēšanas sistēmas, piemēram, Kubernetes. Konteineri ļauj iesaiņot un pārvadāt standarta, pārnēsājamos veidos. Konteineri ļauj ērti palielināt vai nojaukt vidi, kurai ir mainīga slodze.
Ir daudz pieeju konteineru, infrastruktūras kā koda un CI / CD cauruļvadu izmantošanai kopā. Varat izpētīt opcijas, izmantojot tādas apmācības kā Kubernetes ar Jenkins vai Kubernetes ar Azure DevOps.
Bezserveru skaitļošanas arhitektūras piedāvā vēl vienu iespēju lietotņu izvietošanai un mērogošanai. Bez servera vidē infrastruktūru pilnībā pārvalda mākoņa pakalpojumu sniedzējs, un lietojumprogramma pēc nepieciešamības patērē resursus, pamatojoties uz tās konfigurāciju. Piemēram, AWS bez servera lietojumprogrammas darbojas kā Lambda funkcijas, un izvietojumus var integrēt Jenkins CI / CD cauruļvadā ar spraudni.
CI / CD ļauj biežāk ievietot kodu
Rezumējot, CI paketes un testēšanas programmatūra veido un brīdina izstrādātājus, ja viņu izmaiņas neizdevās nevienā vienības testā. CD ir automatizācija, kas nodrošina izmaiņas infrastruktūrā un veic papildu testus.
CI / CD cauruļvadi ir paredzēti uzņēmumiem, kuri vēlas bieži uzlabot lietojumprogrammas un kuriem nepieciešams uzticams piegādes process. Papildu centieni standartizēt būvējumus, izstrādāt testus un automatizēt izvietošanu ir koda izmaiņu izvietošanas ražošanas process. Kad tas ir izveidots, tas ļauj komandām koncentrēties uz lietojumprogrammu uzlabošanas procesu un mazāk uz sistēmas detaļām, lai to piegādātu skaitļošanas vidē.
CI / CD ir labākā prakse, jo tā novērš nesakritību starp izstrādātājiem, kuri vēlas bieži veikt izmaiņas, ar darbībām, kas vēlas stabilas lietojumprogrammas. Ieviešot automatizāciju, izstrādātāji var biežāk virzīt izmaiņas. Operāciju komandas redz lielāku stabilitāti, jo vidēm ir standarta konfigurācijas, piegādes procesā notiek nepārtraukta pārbaude, vides mainīgie tiek atdalīti no lietojumprogrammas un atcelšanas procedūras tiek automatizētas.
CI / CD cauruļvadu ieviešanas ietekmi var izmērīt kā devops galveno veiktspējas rādītāju (KPI). Bieži tiek uzlaboti tādi KPI kā izvietošanas biežums, izmaiņu izpildes laiks un vidējais laiks līdz atgūšanai (MTTR) no incidenta, kad tiek ieviesta CI / CD ar nepārtrauktu testēšanu. Tomēr CI / CD ir tikai viens process, kas var veicināt šos uzlabojumus, un ir arī citi priekšnosacījumi, lai uzlabotu izvietošanas frekvences.
Lai sāktu darbu ar CI / CD, izstrādātājiem un operatīvajām komandām ir jāsadarbojas tehnoloģiju, prakses un prioritāšu jomā. Komandām jāattīsta vienprātība par pareizajām pieejām savam biznesam un tehnoloģijām, lai pēc CI / CD uzstādīšanas komanda būtu uz klāja, konsekventi ievērojot šādu praksi.
