CI/CD: Čo je continuous integration a continuous delivery

Autor: Michaela Kojnoková

ProgramovanieQA testovanie softvéru

CI/CD je spôsob práce, ktorý spája automatizovanú integráciu kódu, priebežné testovanie a nasadenie do produkcie do jedného procesu. Každá zmena, ktorá sa odošle do repozitára, prejde rovnakou sériou kontrol až po produkčné prostredie. Tímy tak doručujú nové funkcie rýchlejšie, s menším rizikom chýb a s prehľadom o tom, čo presne ide von.

Čo je CI/CD a prečo je dôležité?

CI/CD predstavuje skratku pre dve anglické slovné spojenia. CI znamená Continuous Integration, teda kontinuálnu integráciu. Skratka CD má dva možné významy: Continuous Delivery (priebežné dodávanie) alebo Continuous Deployment (priebežné nasadzovanie). Rozdiel medzi nimi nájdeš nižšie, pretože práve on rozhoduje o tom, kto stlačí posledné tlačidlo pred produkciou.

Ide o súbor praktík, ktorých cieľom je automatizovať vývoj softvéru a uľahčiť aj urýchliť celý pracovný proces. CI/CD je súčasťou DevOps kultúry, pretože prepája vývoj, testovanie a prevádzku a umožňuje im spolupracovať rýchlejšie a spoľahlivejšie.

Vďaka CI/CD sa každá zmena v kóde automaticky integruje, testuje a pripravuje na nasadenie. To skracuje čas medzi vývojom novej funkcionality a jej dodaním používateľom.

Čo je continuous integration (CI)?

Continuous integration (CI) do slovenčiny prekladáme ako kontinuálna integrácia. Už samotný názov naznačuje, že ide o spôsob práce, pri ktorom sa nové alebo opravené časti kódu pravidelne integrujú do spoločného Git repozitára, kde sa následne aj testujú. Jednotlivé zmeny sú vďaka tomu menšie, rovnako ako prípadné chyby či komplikácie. Tie sa potom opravujú oveľa jednoduchšie, než keby sa celý kód napísal naraz a testoval až na konci.

CI je základným pilierom CI/CD a jeho cieľom je udržiavať kód stabilný, kvalitný a neustále pripravený na ďalší krok. Zároveň pomáha minimalizovať riziko vzniku chýb, ktoré by sa inak mohli prejaviť až v neskorších fázach vývoja.

Ako funguje CI v praxi?

V praxi CI funguje tak, že tím integruje zmeny v kóde do repozitára niekoľkokrát denne. Nečaká pritom na koniec dňa, týždňa ani iného časového obdobia. Po tom, ako sa zmena objaví na serveri, sa automaticky spúšťa testovanie, analýza kvality kódu a ďalšie kontroly. Tie zabezpečujú, že je všetko v poriadku a tím môže bez problémov pokračovať v práci.

Ak sa objavia chyby, oprava sa môže začať okamžite. Vďaka tomu sa proces zbytočne nekomplikuje, skracuje sa čas dodania a šetria sa náklady.

Continuous delivery vs. continuous deployment: V čom je rozdiel?

Po CI nasleduje CD, teda continuous delivery (priebežné dodávanie). Niektorí si ho mýlia s continuous deployment, ktoré označuje priebežné nasadzovanie. Hoci tieto dva pojmy znejú veľmi podobne, existuje medzi nimi zásadný rozdiel: ide o to, kto alebo čo rozhoduje o finálnom nasadení kódu do produkcie.

Čo je continuous delivery?

Continuous delivery znamená, že po tom, ako sa do repozitára dostane zmena, sa okamžite otestuje a pripraví na nasadenie do produkcie. Všetky kroky sú automatizované, okrem posledného, ktorým je finálne nasadenie. To sa spúšťa manuálne, zvyčajne až po schválení vydania.

Výhodou continuous delivery je, že uľahčuje celý proces práce a skracuje čas doručenia softvéru alebo aplikácie. Zároveň ti však ponecháva kontrolu nad tým, kedy kód prejde do produkcie. Tento prístup je vhodný najmä pre tímy, ktoré pracujú v regulovaných odvetviach alebo potrebujú manuálnu kontrolu pred každým vydaním.

Čo je continuous deployment?

Continuous deployment posúva automatizáciu o krok ďalej. Okrem testovania a prípravy nového kódu ho automaticky nasadzuje priamo do produkcie, a to bez nutnosti manuálneho zásahu. Aplikácia alebo iný softvér tak môže byť pravidelne aktualizovaný, pričom si to ani nemusíš všimnúť.

Pre continuous deployment sa rozhodujú tímy, ktoré chcú skrátiť čas medzi napísaním kódu a jeho dostupnosťou pre používateľa na minimum. Podmienkou je dôveryhodná testovacia sada, pretože jediné, čo stojí medzi chybou a produkciou, sú automatizované testy. Mnohé tímy preto kombinujú continuous deployment s prepínačmi funkcií (feature flags), ktoré umožňujú aktivovať novú funkciu pre používateľov až v správnom čase.

CI/CD pipeline: 8 krokov od commitu po produkciu

Moderná CI/CD pipeline pozostáva z viacerých navzájom prepojených krokov. Každá zmena v kóde tak prejde kontrolovaným, automatizovaným a opakovateľným procesom. Celá pipeline slúži ako štandardizovaná „diaľnica“ pre kód od vývoja k používateľovi.

1. Commit (zaznamenanie zmeny)

Tento krok iniciuje celý proces CI/CD. V praxi ide o uloženie nového kódu alebo opravu existujúceho, teda o zaznamenanie zmeny v Git repozitári. Niektoré tímy ešte pred samotným commitom používajú takzvané pre-commit kontroly, ktoré automaticky validujú časť kódu. Ich úlohou je najmä:

• skontrolovať syntaktické chyby,
• spustiť lintery (kontrolu štýlu kódu),
• spustiť statickú analýzu kódu,
• skontrolovať formátovanie,
• zablokovať commit, ak kód neprejde kontrolami.

Pre-commit kontroly fungujú ako filter, ktorý zabraňuje odoslaniu commitu s chybami. Vďaka nim získaš rýchlejšiu spätnú väzbu a v CI/CD pipeline sa objaví menej chýb.

Samotný commit by mal byť dobre premyslený a štruktúrovaný, aby boli zmeny v kóde jasne zdokumentované a ľahko sledovateľné. Vďaka tomu môžeš viesť presnú históriu aktualizácií, čo je dôležité pre teba aj pre ostatných v tíme.

Odporúčame ti:

Commituj menšie zmeny a častejšie. Znížiš tak pravdepodobnosť konfliktov a chýb v ďalších fázach pipeline.

2. Source (zdrojový kód)

Po prvom kroku nasleduje načítanie zdrojového kódu z repozitára a jeho príprava na spracovanie. Systém overuje, či je konfigurácia projektu kompletná a či má k dispozícii všetky potrebné súbory, aby sa mohol pripraviť na ďalšie kroky procesu.

V tejto fáze sa rieši aj to, v ktorej vetve sa tvoja zmena nachádza. Môže ísť o produkčný alebo integračný kód, nový vývoj alebo rýchlu opravu. Zároveň platí, že čím menej vetiev projekt používa, tým rýchlejšie je možné ich integrovať do hlavnej vetvy. Ak tím pracuje s dlhodobými alebo početnými vetvami, kód sa vyvíja izolovane, pri spájaní vznikajú konflikty a integrácia zmien je náročnejšia.

Výskum DORA (DevOps Research and Assessment) dlhodobo ukazuje, že najvýkonnejšie IT tímy majú len niekoľko aktívnych vetiev, integrujú zmeny denne alebo častejšie a vyhýbajú sa veľkým zlúčeniam. DORA zároveň sleduje päť metrík, ktoré sa bežne používajú na meranie kvality CI/CD procesu:

• deployment frequency, teda ako často tím nasadzuje do produkcie,
• lead time for changes, teda čas od commitu po nasadenie,
• change failure rate, teda podiel nasadení, ktoré spôsobia problém v produkcii,
• failed deployment recovery time, teda ako rýchlo sa tím zotaví po zlyhanom nasadení,
• rework rate, teda podiel neplánovaných nasadení, ktoré vyvolal incident v produkcii.

Z pohľadu testovania sú najzaujímavejšie change failure rate a rework rate. Obe hovoria priamo o tom, ako dobre pipeline zachytí chyby skôr, než sa dostanú k používateľovi.

3. Build (zostavenie aplikácie)

V tomto kroku sa kód zostavuje do nasaditeľných artefaktov. Môžu nimi byť knižnice, kontajnery alebo binárne súbory. Softvér a aplikácie zároveň potrebujú rôzne knižnice alebo balíčky, ktoré build fáza automaticky stiahne a zahrnie. Pre JavaScript sa najčastejšie používajú nástroje npm, pnpm alebo yarn, pre Javu zas Maven alebo Gradle.

Pri modernom vývoji sa kód často balí do takzvaného Docker image, ktorý spravidla obsahuje aplikáciu, potrebné knižnice, konfiguráciu, runtime aj základ operačného systému. Docker image je zároveň základom pre orchestráciu cez Kubernetes. Kubernetes je systém, ktorý spravuje beh kontajnerov naprieč viacerými servermi: rozhoduje, kde sa ktorý kontajner spustí, reštartuje spadnuté inštancie a zvyšuje alebo znižuje ich počet podľa záťaže. V CI/CD pipeline preberá kontajner z build fázy a nasadzuje ho do cieľového prostredia.

Súčasťou tohto kroku bývajú aj rýchle kontroly, ktorých cieľom je odhaliť prípadné chyby v syntaxi alebo formátovaní. Ak neodhalia žiadne problémy, kód je pripravený na ďalší krok pipeline.

4. Artifact repository (repozitár artefaktov)

Artifact repository je úložisko, do ktorého sa ukladajú všetky výsledky buildu. Ide o hotové artefakty, ktoré vzniknú zo zdrojového kódu. Artefaktami môžu byť napríklad:

• knižnice,
• balíčky,
• Docker image,
• spustiteľné súbory vo formátoch .exe, .jar, .war a podobne,
• konfiguračné balíčky,
• skripty.

Ukladanie artefaktov do repozitára je dôležité najmä preto, aby boli všetky výstupy z buildu na jednom mieste, ku ktorému má prístup celý tím. Zároveň umožňuje ukladať jednotlivé verzie buildu, ku ktorým sa môžeš kedykoľvek vrátiť. Táto funkcia rollbacku je v poisťovníckom prostredí kritická, lebo umožňuje rýchly návrat k predchádzajúcej verzii, ak sa v produkcii objaví neočakávaný problém.

5. Test (automatické testovanie)

Aj napriek tomu, že v predchádzajúcich krokoch prebiehajú menšie kontroly, je potrebné vykonať hĺbkovú kontrolu, ktorá potvrdí, že je kód správny a stabilný. Testy prebiehajú automaticky pri každej zmene v kóde, takže do procesu nemusíš manuálne zasahovať. Tento prístup sa označuje ako continuous testing.

Poradie testov nie je náhodné. Pipeline spúšťa najprv tie najrýchlejšie, aby zlyhala čo najskôr a nezdržiavala vývoj zbytočne dlho:

• Unit testy testujú malé časti kódu izolovane. Bežia v sekundách a je ich najviac.
• Integračné testy overujú, či jednotlivé moduly alebo komponenty správne spolupracujú. Trvajú dlhšie a je ich menej.
• Funkčné testy overujú správanie aplikácie proti požiadavke, teda či robí to, čo je v zadaní.

Toto usporiadanie sa označuje ako testovacia pyramída. Čím vyššie v pipeline test stojí, tým je pomalší a krehkejší, preto ich má byť menej.

Odporúčame ti:

Ak chceš ísť do hĺbky v téme automatizovaného testovania, pozri si článok o CI/CD pri testovaní softvéru na msgtester.sk.

6. Security (bezpečnostné kontroly)

Bezpečnostné kontroly patria priamo do pipeline, nie na koniec projektu. Tento prístup sa označuje ako DevSecOps a jeho podstatou je, že zraniteľnosť sa hľadá v rovnakom momente ako funkčná chyba. V regulovaných odvetviach, medzi ktoré patrí aj poisťovníctvo, býva takáto kontrola aj podmienkou auditu.

V pipeline sa najčastejšie stretneš s tromi typmi kontrol:

• SAST (static application security testing) analyzuje zdrojový kód bez jeho spustenia a hľadá známe nebezpečné vzory.
• SCA (software composition analysis) kontroluje knižnice tretích strán a hlási tie, ktoré majú známu zraniteľnosť.
• DAST (dynamic application security testing) testuje už bežiacu aplikáciu zvonku, podobne ako by to skúšal útočník.

Osobitnou kategóriou je kontrola tajomstiev v repozitári. Skenery hľadajú heslá, API kľúče a certifikáty, ktoré niekto omylom commitol. Práve toto býva najčastejší a zároveň najlacnejšie opraviteľný nález.

7. Acceptance test (akceptačné testovanie)

Po klasickom testovaní nasleduje akceptačné testovanie, pri ktorom sa overuje, či aplikácia:

• spĺňa funkčné požiadavky,
• zodpovedá požiadavkám klienta,
• funguje správne aj z pohľadu koncového používateľa,
• je pripravená na reálne používanie.

V tomto kroku sa využívajú najmä tieto typy testov:

• End-to-end testy (E2E) simulujú reálne používanie aplikácie naprieč celým tokom.
• UI testy overujú, že používateľské rozhranie funguje a reaguje tak, ako má.
• Behavior-driven development testy (BDD) potvrdzujú, že aplikácia sa správa v súlade s očakávaniami klienta.

Samostatnou vetvou sú nefunkčné testy, teda záťažové a výkonnostné. Nepatria medzi akceptačné testy, pretože neoverujú, či aplikácia robí správnu vec, ale ako sa správa pod tlakom. V pipeline preto bežia ako vlastná fáza, najčastejšie proti prostrediu, ktoré sa parametrami blíži produkcii. Merať výkon na testovacom serveri s inou konfiguráciou nemá výpovednú hodnotu.

8. Deploy a monitoring (nasadenie a sledovanie)

Deploy je krok, v ktorom sa aplikácia presúva do cieľového prostredia. Spôsob nasadenia závisí od nastavenia tímu a zvoleného prístupu. Na výber sú dve možnosti, ktoré sú opísané vyššie:

• Continuous delivery: kód je pripravený na nasadenie, no jeho spustenie vyžaduje manuálne schválenie.
• Continuous deployment: po splnení všetkých podmienok sa kód automaticky nasadzuje priamo do produkcie.

Pokročilé tímy nenasadzujú novú verziu naraz pre všetkých. Pri blue-green deployment beží popri produkčnej verzii druhé, identické prostredie s novou verziou. Prepnutie prevádzky je otázkou jedného kroku a rovnako rýchly je aj návrat späť, ak sa niečo pokazí. Canary release ide inou cestou: novú verziu dostane najprv malý podiel používateľov, tím sleduje metriky a až potom rozšíri nasadenie na zvyšok. Obe stratégie sú z pohľadu testovania zaujímavé tým, že časť overovania sa presúva do produkcie, kde sú reálni používatelia a reálne dáta.

Nasadením proces nekončí. Bez monitoringu nevieš, či verzia funguje, len to, že sa nasadila. Preto po deploy nasleduje sledovanie chybovosti, času odozvy a kľúčových biznis metrík, najčastejšie s automatickým upozornením pri prekročení hranice. K tomu patrí pripravený a vyskúšaný rollback. Návrat k predchádzajúcej verzii musí byť rovnako rutinný ako samotné nasadenie, inak sa z neho v krízovej situácii stane improvizácia.

Výhody CI/CD pre firmy a vývojové tímy

CI/CD má prínosy pre firmu aj pre jednotlivca v tíme. Medzi tie hlavné patria:

• Rýchlejšie doručovanie nových funkcionalít, pretože automatizácia skracuje čas medzi napísaním kódu a jeho nasadením.
• Vyššia kvalita softvéru, keďže priebežné automatizované testovanie odhalí aj drobné chyby, ktoré by neskôr mohli viesť k väčším problémom.
• Menej manuálnej práce a chýb, pretože automatizované procesy znižujú riziko ľudského zlyhania.
• Lepšia spolupráca tímov. Vývoj, testovanie a prevádzka pracujú nad jedným procesom, nie vedľa seba.
• Stabilnejšie aplikácie, lebo častejšie a menšie vydania znamenajú menej výpadkov a jednoduchšie hľadanie príčiny.
• Nepretržitá spätná väzba, ktorá umožňuje riešiť problém v momente jeho vzniku, nie o dva týždne.
• Nižšie náklady na opravu chýb, keďže chyba nájdená v pipeline stojí zlomok toho, čo stojí chyba nahlásená zákazníkom.
• Vyššia konkurencieschopnosť, pretože firma dokáže rýchlejšie reagovať na zmeny na trhu a na požiadavky regulátora.

Čo CI/CD stojí a kde najčastejšie bolí

CI/CD nie je zadarmo a väčšina jeho problémov sa neprejaví pri zavedení, ale po pol roku prevádzky. Toto sú štyri veci, na ktoré tímy narážajú najčastejšie:

• Nestabilné testy (flaky tests). Test, ktorý raz prejde a raz spadne bez zmeny kódu, je horší než žiadny. Tím ho po čase začne ignorovať a s ním aj ostatné červené buildy.
• Údržba testovacej sady. Automatizovaný test je kód a starne rovnako ako produkčný. Bez pravidelného čistenia sa sada zmení na balast, ktorý predlžuje pipeline a nikto mu neverí.
• Náklady na infraštruktúru. Runnery, testovacie prostredia a paralelné spúšťanie stoja peniaze za cloud aj čas na údržbu.
• Falošný pocit istoty. Zelená pipeline hovorí len to, že prešli testy, ktoré niekto napísal. O tom, čo nikto netestuje, mlčí.

Žiadny z týchto bodov nie je dôvod CI/CD nezavádzať. Sú to však náklady, s ktorými treba počítať pri plánovaní kapacity tímu, nie prekvapenia, na ktoré sa príde po polroku prevádzky.

CI/CD nástroje: Jenkins, GitLab CI/CD, GitHub Actions a ďalšie

Ak chceš CI/CD využívať naplno, potrebuješ spoľahlivé a overené nástroje. Niektoré z nich sú určené priamo na CI alebo CD, iné sa zameriavajú na špecifické úlohy, ako je riadenie vývoja či priebežné testovanie.

Mnohé z týchto nástrojov sú open-source, čo znamená, že ich môžeš používať bezplatne. K dispozícii sú však aj platené riešenia, ktoré zvyčajne ponúkajú skúšobné verzie. Niektoré z nich fungujú ako SaaS služby v cloude, takže nemusíš nič inštalovať ani udržiavať lokálne.

Medzi najpopulárnejšie CI/CD nástroje patria:

• Jenkins: jeden z najrozšírenejších nástrojov na CI. Keďže ide o open-source riešenie, je dostupný zadarmo a ponúka vysokú mieru flexibility. Má rozsiahlu komunitu a tisíce pluginov, na oplátku si vyžaduje viac konfigurácie a vlastnú prevádzku.
• GitLab CI/CD: riešenie umožňujúce spúšťanie testov a nasadzovanie nového kódu priamo z GitLab repozitára. Tímy ho obľubujú najmä pre jednoduchosť, YAML konfiguráciu a natívnu podporu DevOps praktík.
• GitHub Actions: nástroj integrovaný priamo do GitHubu, ktorý slúži na automatizáciu CI/CD pipeline a mnohých ďalších procesov. Jeho výhodou je jednoduché používanie a rozsiahla knižnica hotových šablón.
• CircleCI: cloudová platforma využívaná najmä tímami pracujúcimi na väčších projektoch. Je vhodná pre tých, ktorí kladú dôraz na rýchlosť a paralelné spúšťanie.
• Docker: hoci nejde o klasický CI/CD nástroj, zohráva dôležitú úlohu pri vytváraní konzistentných prostredí, v ktorých aplikácie fungujú rovnako vo všetkých fázach vývoja.

Okrem vymenovaných riešení sa v moderných pipeline často stretneš aj s Azure DevOps, TeamCity či Bitbucket Pipelines. Výber nástroja závisí od toho, kde máš kód uložený, aký veľký je tím a aké integrácie potrebuješ.

CI/CD v poisťovníctve

Poisťovníctvo patrí k odvetviam, kde CI/CD zohráva kľúčovú úlohu. Ide o sektor s komplexnými systémami, prísnymi legislatívnymi požiadavkami a neustálym tlakom na rýchle reagovanie na zmeny trhu. Poisťovne pracujú s veľkým objemom dát, zložitými procesmi a produktmi, ktoré je potrebné pravidelne aktualizovať, či kvôli reguláciám, konkurencii alebo interným inováciám. CI/CD prináša do tohto prostredia stabilitu, rýchlosť a automatizáciu, ktoré rozsiahle systémové zmeny vyžadujú.

Regulované prostredie kladie na pipeline jednu požiadavku navyše: dohľadateľnosť. Pri audite musí byť možné doložiť, ktorá verzia kódu bola nasadená, kedy, kým schválená a ktorými testami prešla. Práve preto sú artefakty, logy z pipeline a záznam o schválení rovnako dôležité ako samotné testy.

Digitalizácia poisťovníctva kladie na IT tímy čoraz vyššie nároky. Zákazníci očakávajú rýchle uzatváranie zmlúv online, transparentné spracovanie škodových udalostí a moderné mobilné aplikácie. Bez CI/CD by sa tieto zmeny nedali dodávať v takej rýchlosti a kvalite, akú zákazníci očakávajú.

Ako msg life využíva CI/CD v praxi

Spoločnosť msg life využíva CI/CD na priebežnú integráciu a dodávanie zmien v rámci msg.Insurance Suite. Ide o komplexné softvérové riešenie pre správu poistných produktov. Keďže poisťovacie procesy zahŕňajú výpočty poistného, správu zmlúv, spracovanie poistných udalostí či generovanie regulovaných dokumentov, je nevyhnutné, aby bola každá zmena v systéme dôkladne otestovaná vo všetkých fázach CI/CD pipeline. Automatizované testy overujú logiku, legislatívne pravidlá aj správnosť procesov, zatiaľ čo continuous delivery umožňuje rýchle a spoľahlivé nasadzovanie aktualizácií pre klientov.

Agilný vývoj softvéru má v msg life vysokú prioritu. Preto sa pri vývoji a dodávaní softvérových verzií používa continuous integration aj continuous delivery. Softvérová aplikácia je rozdelená do viacerých menších nasaditeľných jednotiek, napríklad Docker kontajnerov, z ktorých každý predstavuje samostatnú biznis funkciu a môže byť nasadený nezávisle.

Použitie Docker kontajnerov umožňuje implementovať stratégiu immutable deployment (nemeniteľné nasadenie), ktorej cieľom je používať rovnaké nasadenie vo všetkých fázach vývoja a vopred eliminovať možné problémy.

Nasadzovací systém (deployment pipeline), ktorý zahŕňa všetky fázy spracovania a overovania softvéru až po jeho vydanie, je plne automatizovaný. Zabezpečuje, aby sa zmeny z vývoja dostali ku koncovým používateľom presne podľa plánu: čo najrýchlejšie a vo vysokej kvalite. Každá zmena je pritom priamo integrovaná do celého systému.

Zdieľaj článok

CI/CD: Čo je continuous integration a continuous delivery

Michaela Kojnoková

Vyštudovala som informatiku na ŽU a TUKE a už niekoľko rokov pôsobím v oblasti softvérového testovania. Špecializujem sa na automatizáciu testov, Python a DevOps procesy. Popri práci ma baví vzdelávať sa ďalej v oblasti machine learningu a vývoja umelej inteligencie a objavovať možnosti jej využitia v praxi. Svoje skúsenosti a poznatky z oblasti AI, testovania a moderných technológií taktiež pravidelne zdieľam prostredníctvom odborných článkov.