CI/CD dnes využíva vraj až 90 percent programátorov-profesionálov. Niet sa čo čudovať. Kontinuálna integrácia a kontinuálne doručovanie majú v podstate len samé výhody. V bart-e ich, v takej či onakej forme, využívame na každom projekte. Prečo? Lebo nám záleží na zvyšovaní kvality našej práce.
Na úvod trošku teórie. Continuous Integration and Continuous Deployment (CI/CD) je súbor postupov softvérového inžinierstva. V rámci nich sa zavádza najmä minimalizácia kontaktu reálnych ľudí s testingom a deployom. V skratke, developerov nahrádza efektívnejšia, rýchlejšia a spoľahlivejšia automatizácia. CI časť zvyčajne zahŕňa automatizovanú kontrolu kódu pri každom commite a CD zas kontinuálny deploy do živého prostredia po každej zmene, nie až pri veľkých features. Aké výhody z toho plynú?
1. Krajší kód
Náš CI/CD postup je nastavený tak, že pri každom mergovaní kód automaticky prechádza cez pipeline, čo je systém pozostávajúci z viacerých úloh/jobov. Medzi ne patrí napríklad kontrola formátovania, statická analýza či testovací build. Nový príspevok do projektu sa teda upravuje tak, aby ladil so zvyškom a pri mergovaní sa objavili len skutočné zmeny a reálne konflikty, nie aj inak použité odsadenia či zbytočné premenné. To zjednodušuje samotný merge a zabezpečuje prehľadnosť projektu.
2. Menej chýb
V rámci mergovania sa vykonáva aj séria jednoduchých unit a integračných testov. Voláme ich “lacné”, lebo samotný proces testingu trvá len niekoľko minút a nezahlcuje preto veľa zdrojov, a teda ani nemíňa veľa peňazí. Unit testy testujú len jednotlivé funkcie alebo malé časti kódu bez vonkajších závislostí. Integračné zas kontrolujú, ako spolu komunikujú komponenty v rámci jedného systému (napr. v API, na FE alebo v microservise). Tým, že tieto testy spúšťame ihneď po commite kódu, programátor sa vie okamžite vrátiť ku svojej feature a kód opraviť. Ak by sa spúšťali až o deň, dva či tri neskôr, prípadne až pri deployi, je možné, že vývojár si už ani nespomenie, čo a ako to vlastne robil, a oprava bude preňho náročnejšia.
Niekedy navyše siahame aj po tzv. drahých end-to-end testoch. Nespúšťajú sa však na každý commit, ale pravidelne v časových intervaloch, pred posunom buildu do testingu alebo pred nasadením feature do produkcie. Tieto testy trvajú aj niekoľko hodín a vyžadujú si rozbehnutie všetkých servís aj browsera, aby automatizovane “klikal” namiesto používateľa. Hoci sú oveľa náročnejšie na zdroje, pred deployom sa ich spustenie rozhodne oplatí.
Vďaka vhodnej kombinácii lacných a drahých testov dokážeme odchytiť väčšinu chýb a opraviť ich včas. Celý projekt sa tak stáva bezpečnejším, pretože zabránime preneseniu chýb do produkčného prostredia a znížime teda riziko vzniku problémov, ktoré by objavil až používateľ.
3. Rýchlejší vývoj
Keďže sú všetky testy a kontrolné body v procese vývoja automatizované, nemíňame na nich “ľudský” čas a máme priestor premýšľať nad vecami, ktoré sú dôležité. Napríklad viac komunikovať s klientom, adresovať zmeny jeho požiadaviek alebo experimentovať a skúšať nové funkcionality. Vďaka tomu sa do projektov dostanú aj novinky, ktoré by sme možno bez CI/CD ani len nezačali vyvíjať. Nebol by na to jednoducho čas ani chuť…
4. Lepšia kontrola
Častá integrácia znamená aj to, že sem tam doplníme do projektu povedzme len 10 riadkov kódu. Takýto malý kód vieme pri nasadzovaní poriadne skontrolovať, okamžite vyriešiť prípadné konflikty a rýchlejšie doručiť aktualizáciu zákazníkovi. Ak by sme mergovali až po dokončení celých veľkých funkcionalít, riadkov kódu by bolo podstatne viac. Veľa čítania spravidla znamená zníženie pozornosti. Po prvej tisícke riadkov programátor zväčša rezignuje, označí merge request do projektu ako, obrazne povedané, LGTM (looks good to me), navhrne riešenia len pre najkritickejšie chyby a považuje prácu za hotovú. Kratší kód teda znamená kvalitnejšiu kontrolu a tým pádom, samozrejme, kvalitnejší produkt.
5. Zníženie nákladov
Táto výhoda je, ako vždy, diskutabilná. Samozrejme, nastaviť procesy a napísať testy si vyžaduje programátorský čas, ktorého nie je práve málo. Ak však zvážime, koľko prostriedkov nám táto investícia v konečnom dôsledku ušetrí, určite sa to oplatí. A navyše, menej chýb v kóde znamená menej času na opravy, čo sa rovná ďalším úsporám.
Podľa mňa sa prvky CI/CD vývoja oplatia aj na naozaj malé projekty. Napríklad pipelines sú dostupné prakticky každému programátorovi, pretože ich spúšťanie ponúka GitLab vo svojom free tiere zadarmo. Takto si to ľudia môžu ohmatať, otestovať a vyhodnotiť ich užitočnosť. Obzvlášť, ak sa im nechce ručne buildovať, čakať, potom kontrolovať a opravovať a zas dookola. Samozrejme ale treba zvážiť, čo sa oplatí, a čo nie. Žiaden postup nie je univerzálny ani efektívny pre všetko.
A pri veľkých projektoch s viacčlennými tímami? Ak chceme vyvíjať kvalitne, CI/CD je tu takmer nutnosť. Každý človek totiž predstavuje riziko chyby, ktorú program jednoducho neurobí. Nechajme teda na ľudí kreatívnu prácu, vymýšľanie a analyzovanie a všetko ostatné nech radšej robí stroj/AI. Takto sa skvele dopĺňame a dokážeme vyvíjať naozaj kvalitné digitálne produkty.
