Nuolatinė integracija (PI) ir nuolatinis pristatymas (CD) įkūnija kultūrą, veikimo principų rinkinį ir praktikos rinkinį, leidžiantį programų kūrimo komandoms dažniau ir patikimiau pateikti kodo pakeitimus. Įgyvendinimas taip pat žinomas kaip CI / CD dujotiekis.
CI / CD yra viena iš geriausių praktikų, kurias gali įgyvendinti „devops“ komandos. Tai taip pat yra geros metodikos geriausia praktika, nes ji leidžia programinės įrangos kūrimo komandoms sutelkti dėmesį į verslo reikalavimų, kodo kokybės ir saugumo atitiktį, nes diegimo žingsniai yra automatizuoti.
CI / CD apibrėžta
Nuolatinė integracija yra kodavimo filosofija ir praktikos rinkinys, skatinantis kūrimo komandas įgyvendinti nedidelius pakeitimus ir dažnai tikrinti kodą versijų valdymo saugyklose. Kadangi daugumai šiuolaikinių programų reikia sukurti kodą skirtingose platformose ir įrankiuose, komandai reikalingas mechanizmas, kuris integruotų ir patvirtintų jo pakeitimus.
Techninis KI tikslas yra sukurti nuoseklų ir automatizuotą būdą kurti, pakuoti ir išbandyti programas. Esant nuosekliam integracijos procesui, komandos dažniau pakeičia kodą, o tai lemia geresnį bendradarbiavimą ir programinės įrangos kokybę.
Nuolatinis pristatymasimasi ten, kur baigiasi nuolatinė integracija. CD automatizuoja programų pristatymą į pasirinktą infrastruktūros aplinką. Daugelis komandų dirba su keliomis aplinkomis, išskyrus gamybinę, pvz., Kūrimo ir bandymo aplinkomis, o CD užtikrina, kad yra automatizuotas būdas pakeisti kodo pakeitimus.
CI / CD įrankiai padeda išsaugoti aplinkos parametrus, kurie turi būti supakuoti kiekvieną pristatymą. Tada CI / CD automatika atlieka visus būtinus paslaugų skambučius į žiniatinklio serverius, duomenų bazes ir kitas paslaugas, kurias gali tekti paleisti iš naujo, arba vykdydami kitas procedūras, kai diegiamos programos.
Reikia nuolatinės integracijos ir nuolatinio pristatymonuolatinis testavimasnes tikslas yra pateikti vartotojams kokybiškas programas ir kodą. Nuolatinis testavimas dažnai įgyvendinamas kaip automatinės regresijos, našumo ir kitų testų rinkinys, vykdomas CI / CD.
Subrendusi CI / CD išskleidimo praktika turi galimybę įdiegti nuolatinį diegimą, kai programų pakeitimai vykdomi per CI / CD vamzdyną, o perduoti versijos yra diegiamos tiesiai į gamybos aplinką. Komandos, praktikuojančios nepertraukiamą pristatymą, pasirenka gamybą pagal dienos ar net valandos tvarkaraštį, nors nuolatinis pristatymas ne visada yra optimalus kiekvienai verslo programai.
Susijęs vaizdo įrašas: Kaip greičiau pristatyti kodą naudojant CI / CD
Kaip nuolatinė integracija pagerina bendradarbiavimą ir kokybę
Nuolatinė integracija yra plėtros filosofija, paremta procesų mechanika ir tam tikra automatika. Praktikuodami KI, kūrėjai dažnai įtraukia kodą į versijų valdymo talpyklą, o dauguma komandų turi minimalų kodo įvedimo standartą bent kasdien. To priežastis yra ta, kad defektus ir kitas programinės įrangos kokybės problemas lengviau nustatyti mažesniais kodų skirtumais, o ne didesniais, sukurtais per ilgą laiką. Be to, kai kūrėjai dirba su trumpesniais įsipareigojimų vykdymo ciklais, rečiau, kad keli kūrėjai redaguoja tą patį kodą ir reikalauja sujungti vykdydami.
Komandos, įgyvendinančios nuolatinę integraciją, dažnai pradeda nuo versijų valdymo konfigūracijos ir praktikos apibrėžimų. Nors kodas tikrinamas dažnai, funkcijos ir taisymai įgyvendinami tiek trumpuoju, tiek ilgesniu laikotarpiu. Kūrėjų komandos, praktikuojančios nuolatinę integraciją, naudoja skirtingas technikas, norėdamos kontroliuoti, kokios funkcijos ir kodas yra paruošti gamybai.
Daugelis komandų naudoja funkcijos vėliavos, konfigūravimo mechanizmas funkcijoms ir kodui įjungti arba išjungti vykdymo metu. Funkcijos, kurios vis dar kuriamos, kode yra suvyniotos su funkcijų vėliavomis, kartu su pagrindiniu filialu diegiamos gamybai ir išjungiamos, kol bus paruoštos naudoti. Remiantis neseniai atlikta apklausa, 63 proc. Komandų, naudojančių funkcijų žymes, praneša apie geresnį testavimą ir aukštesnės kokybės programinę įrangą. Funkcijos žymėjimo įrankiai, tokie kaip „CloudBees“ išleidimas, „Optimizely“ išleidimas ir „LaunchDarkly“, integruojami su CI / CD įrankiais ir įgalina funkcijų lygio konfigūracijas.
Kita funkcijų valdymo technika yraversijos valdymo šakojimas. Filialų strategija, pvz., „Gitflow“, yra pasirinkta siekiant apibrėžti protokolus, kaip naujas kodas sujungiamas į standartines šakas, skirtas kūrimui, testavimui ir gamybai. Kuriamos papildomos funkcijų šakos toms, kurioms prireiks ilgesnių kūrimo ciklų. Kai funkcija bus baigta, kūrėjai galės sujungti pakeitimus iš funkcijų šakų į pirminę kūrimo šaką. Šis metodas veikia gerai, tačiau gali būti sunku valdyti, jei vienu metu yra kuriama daugybė funkcijų.
Tada pats sukūrimo procesas automatizuojamas pakuojant visą programinę įrangą, duomenų bazę ir kitus komponentus. Pvz., Jei kuriate „Java“ programą, CI visus statinius žiniatinklio serverio failus, tokius kaip HTML, CSS ir „JavaScript“, supakuotų kartu su „Java“ programa ir bet kokiais duomenų bazės scenarijais.
CI ne tik supakuoja visus programinės įrangos ir duomenų bazės komponentus, bet ir automatika taip pat atliks vieneto testus ir kitus bandymus. Šis testavimas pateikia kūrėjams atsiliepimą, kad jų kodo pakeitimai nesužeidė jokių esamų vieneto testų.
Dauguma CI / CD įrankių leidžia kūrėjams pradėti kurti pagal poreikį, kuriuos sukelia kodo įvykdymai versijų valdymo saugykloje arba pagal nustatytą tvarkaraštį. Komandos turi aptarti sudarymo tvarkaraštį, kuris geriausiai tinka komandos dydžiui, numatomų kasdienių įsipareigojimų skaičiui ir kitiems taikymo aspektams. Geriausia praktika, užtikrinanti, kad įsipareigojimai ir kaupimai būtų greiti, priešingu atveju tai gali trukdyti komandoms, bandančioms greitai koduoti ir dažnai įsipareigoti, pažangą.
Nuolatinis testavimas viršija testavimo automatizavimą
Automatizuotos testavimo sistemos padeda kokybės užtikrinimo inžinieriams apibrėžti, atlikti ir automatizuoti įvairius bandymus, kurie gali padėti kūrimo komandoms žinoti, ar programinės įrangos kūrimas praeina, ar nepavyksta. Jie apima funkcionalumo testus, kurie yra sukurti kiekvieno sprinto pabaigoje ir sujungiami į regresijos testas visai programai. Šie regresijos testai informuoja komandą, ar kodo pakeitimas nepavyko atlikti vieno ar daugiau testų, sukurtų visose programos funkcinėse srityse, kur yra testo aprėptis.
Geriausia praktika yra įgalinti ir reikalauti, kad kūrėjai atliktų visus regresijos testus ar jų dalį savo vietinėje aplinkoje. Šis žingsnis užtikrina, kad kūrėjai skiria kodą versijų valdymui tik po to, kai regresijos testai perduoda kodo pakeitimus.
Regresijos testai yra tik pradžia. Našumo testavimas, API testavimas, statinio kodo analizė, saugumo testavimas ir kitos testavimo formos taip pat gali būti automatizuotos. Svarbiausia yra sugebėti suaktyvinti šiuos bandymus naudojant komandinę eilutę, „webhook“ ar žiniatinklio tarnybą ir kad jie atsakytų sėkmingai arba nesėkmingai.
Kai bandymai bus automatizuoti, nuolatiniai bandymai reiškia, kad automatika yra integruota į CI / CD vamzdyną. Kai kurie vieneto ir funkcionalumo testai gali būti integruoti į CI, kuris pažymi problemas prieš integracijos procesą arba jo metu. Testai, kuriems reikalinga visa pristatymo aplinka, pvz., Našumo ir saugumo testai, dažnai integruojami į kompaktinius diskus ir atliekami po to, kai versijos pateikiamos tikslinėms aplinkoms.
CD vamzdynas automatizuoja kelių aplinkų pakeitimus
Nuolatinis pristatymas yra automatika, nukreipianti programas į pristatymo aplinką. Daugumoje kūrėjų komandų paprastai yra viena ar daugiau kūrimo ir bandymo aplinkų, kuriose bandymai ir peržiūra atliekami programų pakeitimai. CI / CD įrankis, pvz., „Jenkins“, „CircleCI“, AWS „CodeBuild“, „Azure DevOps“, „Atlassian Bamboo“ arba „Travis CI“, naudojamas automatizuoti veiksmus ir teikti ataskaitas.
Tipiškame kompaktinių diskų įrenginyje yra kūrimo, bandymo ir diegimo etapai. Įmantresni vamzdynai apima šiuos veiksmus:
- Kodo ištraukimas iš versijų valdymo ir versijos vykdymas.
- Vykdykite visus būtinus infrastruktūros veiksmus, kurie yra automatizuoti kaip kodas, kad atsistotų ar suardytų debesų infrastruktūrą.
- Kodo perkėlimas į tikslinę skaičiavimo aplinką.
- Aplinkos kintamųjų valdymas ir konfigūravimas tikslinei aplinkai.
- Programos komponentų perkėlimas į atitinkamas paslaugas, pvz., Žiniatinklio serverius, API paslaugas ir duomenų bazių paslaugas.
- Vykdydami bet kokius veiksmus, reikalingus iš naujo paleisti tarnybas ar iškviesti paslaugų galinius taškus, reikalingus naujiems kodo paspaudimams.
- Nuolatinių bandymų ir atkūrimo aplinkų vykdymas, jei bandymai nepavyksta.
- Žurnalo duomenų ir įspėjimų apie pristatymo būseną teikimas.
Pavyzdžiui, „Jenkins“ vartotojai apibrėžia savo vamzdynus „Jenkinsfile“, kuriame aprašomi įvairūs etapai, pvz., Sukūrimas, bandymas ir diegimas. Aplinkos kintamieji, parinktys, slaptieji raktai, sertifikatai ir kiti parametrai deklaruojami faile, o po to nurodomi etapais. Įrašo skiltyje tvarkomos klaidų sąlygos ir pranešimai.
Sudėtingesniame kompaktiniame diske gali būti atliekami kiti veiksmai, tokie kaip duomenų sinchronizavimas, informacijos išteklių archyvavimas arba programų ir bibliotekų pataisymas. CI / CD įrankiai paprastai palaiko papildinių rinką. Pavyzdžiui, „Jenkins“ pateikia daugiau nei 1500 papildinių, kurie palaiko integraciją su trečiųjų šalių platformomis, vartotojo sąsają, administravimą, šaltinio kodo valdymą ir komponavimo valdymą.
Pasirinkus CI / CD įrankį, kūrėjų komandos turi įsitikinti, kad visi aplinkos kintamieji yra sukonfigūruoti ne programoje. CI / CD įrankiai leidžia nustatyti šiuos kintamuosius, užmaskuoti kintamuosius, pvz., Slaptažodžius ir paskyros raktus, ir juos sukonfigūruoti diegiant tikslinei aplinkai.
CD įrankiai taip pat teikia informacijos suvestinę ir ataskaitų teikimo funkcijas. Jei versijos ar pristatymai nepavyksta, jie įspėja kūrėjus su informacija apie gedimus. Jie integruojami su versijų valdymu ir judriomis priemonėmis, todėl juos galima naudoti norint sužinoti, kokie kodo pakeitimai ir vartotojo istorijos sudarė paketą.
Įdiegti CI / CD vamzdynai su „Kubernetes“ ir be serverio architektūromis
Daugelis komandų, eksploatuojančių CI / CD vamzdynus debesų aplinkoje, taip pat naudoja tokius konteinerius kaip „Docker“ ir orkestro sistemas, tokias kaip „Kubernetes“. Konteineriai leidžia pakuoti ir gabenti standartiniais, nešiojamais būdais. Konteineriai leidžia lengvai išplėsti ar išardyti aplinką, turinčią kintantį darbo krūvį.
Yra daugybė būdų, kaip kartu naudoti konteinerius, infrastruktūrą kaip kodą ir CI / CD vamzdynus. Galite ištirti parinktis naudodamiesi tokiomis mokymo priemonėmis kaip „Kubernetes“ su „Jenkins“ arba „Kubernetes“ su „Azure DevOps“.
Kompiuterių be serverio architektūros yra dar vienas būdas diegti ir keisti programas. Be serverio aplinkoje infrastruktūrą visiškai valdo debesijos paslaugų teikėjas, o programa sunaudoja išteklius, jei reikia, atsižvelgiant į jos konfigūraciją. Pavyzdžiui, AWS programose be serverio vykdomos programos veikia kaip „Lambda“ funkcijos, o diegimas gali būti integruotas į „Jenkins CI / CD“ vamzdyną su papildiniu.
CI / CD leidžia dažniau diegti kodą
Apibendrinant galima pasakyti, kad CI paketai ir programinės įrangos testai sukuria ir įspėja kūrėjus, jei jų pakeitimai nesėkmingi. CD yra automatika, teikianti infrastruktūros pokyčius ir atliekanti papildomus bandymus.
CI / CD vamzdynai skirti įmonėms, norinčioms dažnai tobulinti programas ir reikalaujančioms patikimo pristatymo proceso. Papildomos pastangos standartizuoti komponavimo versijas, kurti bandymus ir automatizuoti diegimą yra kodo pakeitimų diegimo procesas. Kai tai bus padaryta, tai leis komandoms sutelkti dėmesį į programų tobulinimo procesą ir mažiau į sistemos detales, kad jos būtų pristatytos į kompiuterinę aplinką.
CI / kompaktinis diskas yra geriausia praktika, nes jis sprendžia nesuderinamumą tarp kūrėjų, norinčių dažnai atlikti pakeitimus, atliekant operacijas, kurios nori stabilių programų. Įdiegę automatizavimą, kūrėjai gali paskatinti pokyčius dažniau. Operacijų komandos mato didesnį stabilumą, nes aplinkose yra standartinės konfigūracijos, pristatymo procese atliekamas nuolatinis testavimas, aplinkos kintamieji yra atskirti nuo programos, o grąžinimo procedūros yra automatizuotos.
CI / CD vamzdynų įgyvendinimo poveikį galima įvertinti kaip pagrindinį efektyvumo rodiklį (KPI). Tokie KPI, kaip diegimo dažnis, keitimo laikas ir vidutinis laikas iki atsistatymo (MTTR) nuo įvykio, dažnai yra patobulinti, kai įdiegiama CI / CD su nuolatiniu testavimu. Tačiau CI / CD yra tik vienas procesas, galintis paskatinti šiuos patobulinimus, ir yra kitų būtinų sąlygų diegimo dažniams pagerinti.
Norint pradėti naudoti CI / CD, kūrimo komandos ir operatyvinės komandos turi bendradarbiauti nustatydamos technologijas, praktiką ir prioritetus. Komandos turi pasiekti bendrą sutarimą dėl tinkamo požiūrio į savo verslą ir technologijas, kad, kai tik bus sukurtas KI / CD, komanda būtų laive ir nuosekliai laikytųsi praktikos.
