Zaznamenali jste někdy zkratku CI/CD a nejste si zcela jisti, co se za ní skrývá?
V ideálním světě jsou softwaroví inženýři najímáni, aby psali kód, který se následně nasazuje do produkčního prostředí, aby ho mohla používat společnost, která daný produkt potřebuje. Pro uspokojení potřeb trhu (často označovaného jako uživatelé/klienti) je nezbytné, aby finální produkty byly bez jakýchkoli defektů.
Běžný postup vývojářů spočívá v práci na samostatných větvích a následném vytvoření takzvaného pull requestu (žádosti o sloučení), který aktualizuje hlavní větev o nově provedené změny. V rámci tohoto procesu se také ujala praxe psaní testů, které mají zajistit, že nově zavedené úpravy nebudou generovat nežádoucí chyby. Ve většině případů vývojáři při práci na určité funkci nevytvoří pull request dříve, než s danou funkcionalitou zcela skončí. V takovém případě, když jsou konečně připraveni, se často stává:
- Tráví značné množství času snahou uvést svůj kód do souladu se změnami, které se mezitím udály v produkčním prostředí.
- Během tohoto procesu jsou nuceni řešit četné konflikty při slučování větví.
- Existuje také riziko, že naruší produkční větev, což negativně ovlivní i ostatní vývojáře, kteří z této větve čerpají, dokud není problém objeven a napraven.
Pokud jste se někdy ocitli v podobné situaci, jistě potvrdíte, že to může být velice frustrující – nikdo přece nechce trávit svůj pracovní den tímto způsobem.
Jak tedy z této situace ven?
Kontinuální integrace
Pro prevenci scénářů, které jsem popsal výše, mohou vývojářské týmy začít používat postup nazývaný kontinuální integrace. Jak již název napovídá, jde o neustálé začleňování změn kódu provedených vývojáři do sdílené větve/úložiště. Kód určený k integraci musí projít ověřovacím testem, aby se zajistilo, že nepoškodí aplikaci. Teprve po úspěšném absolvování testu je kód integrován.
Pro lepší pochopení si představme reálný scénář, kde pracuje tým o deseti vývojářích. Tito vývojáři vytvářejí lokálně větve, ve kterých píší kód pro implementaci určitých funkcí. Namísto odesílání pull requestů až po dokončení celé funkce se rozhodnou posílat pull requesty s menšími změnami. Příkladem může být vytvoření nového modálního okna, pokud vývojář pracuje na funkci pro správu jednotlivých úkolů v aplikaci. Místo čekání na dokončení celé funkcionality, vývojář za dodržení principů kontinuální integrace odesílá tuto malou změnu (v porovnání s tím, na čem pracuje) a vytváří pull request ke sloučení s hlavním kódem.
Než je tato nová změna integrována, musí projít sérií testů.
Softwarové týmy využívají nástroje jako Travis CI k nastavení těchto integračních procesů a testů. Pomocí takových nástrojů jsou testy automatizované, takže se spouští hned, jakmile je odeslán pull request do cílové větve vybrané během nastavení.
Výsledky testů jsou následně vygenerovány a vývojář, který vytvořil pull request, si může výsledky prohlédnout a provést potřebné opravy. Výhody dodržování tohoto postupu, tedy integrace co nejmenších změn a provádění ověřovacích testů, jsou následující:
- Tým, který je zapojen do procesu, bude schopen snadno identifikovat příčiny selhání sestavení nebo testu. Tím se snižuje riziko odeslání chyby do produkčního prostředí.
- Pokud tým automatizuje celý proces, získá luxus více času věnovat se produktivním činnostem.
Je důležité si uvědomit, že tato praxe podporuje časté odesílání kódu do hlavní větve. Tento postup však bude neefektivní, pokud ostatní členové týmu nebudou stahovat aktuální kód z hlavní větve, aby udrželi své lokální úložiště aktualizované.
Druhy testů
Při tvorbě testů, které budou součástí integračního procesu, je vhodné zvážit následující typy testování:
- Integrační testy – kombinují jednotlivé softwarové moduly a testují je jako celek.
- Unit testy – testují jednotlivé softwarové jednotky nebo komponenty, jako jsou metody nebo funkce.
- UI testy – ověřují, že software funguje správně z pohledu uživatele.
- Akceptační testy – ověřují, zda software splňuje obchodní požadavky.
Je důležité poznamenat, že není nutné testovat všechny tyto oblasti, protože některé z nich mohou být již zahrnuty v kódu napsaném vývojářem.
Nástroje pro kontinuální integraci
Bez zbytečných podrobností, zde je seznam nástrojů, které můžete začít používat ve svých stávajících i nových projektech:
- Travis CI – známý především v open source světě, slibuje hladké otestování vašeho kódu během několika minut.
- Circle CI – nabízí výkon, flexibilitu a kontrolu pro automatizaci vašeho potrubí od sestavení až po nasazení.
- Jenkins – poskytuje stovky pluginů pro podporu vytváření, nasazování a automatizace jakéhokoli projektu.
Pokud jste v Jenkinsu nováčky, doporučuji vám tento Udemy kurz, kde se naučíte kontinuální integraci s Javou a .NET.
Kontinuální nasazování
K čemu je dobré, když funkce, kterou vytvoříte, leží v úložišti týdny nebo měsíce, než je nasazena do produkčního prostředí? I když vývojářské týmy usilovně pracují na integraci malých změn do hlavní větve, mohou tyto změny co nejrychleji dostat do produkčního prostředí.
Cílem kontinuálního nasazování je dostat provedené změny k uživatelům ihned, jakmile je vývojáři integrují do hlavní větve.
Stejně jako u kontinuální integrace, i v případě kontinuálního nasazování jsou nastaveny automatizované testy a kontroly, které zajistí ověření nově integrovaných změn. Nasazení proběhne pouze tehdy, když tyto testy projdou.
Aby tým mohl těžit z praxe kontinuálního nasazování, je nutné, aby měl zavedeno následující:
- Automatizované testování je základním pilířem všech postupů kontinuálního inženýrství. V případě kontinuálního nasazování musí kód, který má být nasazen, splňovat standardy, které tým stanovil pro to, co zamýšlí nabídnout koncovým uživatelům. V ideálním případě by test měl selhat, pokud je nová změna pod prahovou hodnotou, a neměla by být integrována. V opačném případě by se měla integrovat.
- Navzdory tomu, že jsou automatizované testy nastaveny, je možné, že některé chyby se dostanou až do produkčního prostředí. Proto je nutné, aby byl tým schopen vrátit zpět provedenou změnu – neboli rollback. Tím by se měl produkční kód uvést do stavu před provedením nové změny.
- Monitorovací systémy jsou nezbytné pro sledování změn, které byly zavedeny do produkčního prostředí. Díky tomu je tým schopen sledovat chyby, se kterými se uživatelé setkávají při používání nasazených změn.
Již zmiňované nástroje pro kontinuální integraci vám obvykle poskytují i funkce pro nastavení kontinuálního nasazování. Existuje však i spousta dalších, o kterých si můžete také přečíst.
Závěr
Produktivita vývojářského týmu je klíčová pro úspěch každého podnikání. Pro zajištění jejich produktivity je nutné zavést postupy, které ji podporují. Kontinuální integrace a nasazování jsou příklady těchto postupů.
Díky kontinuální integraci mohou týmy denně odesílat velké množství kódu. To usnadňuje nasazování nových změn k uživatelům co nejdříve. Nasazení těchto změn umožňuje získat zpětnou vazbu od uživatelů. Společnost tak bude moci inovovat na základě obdržené zpětné vazby, což je výhodné pro všechny zúčastněné.
Můžete se také naučit, jak rozšířit a optimalizovat CI/CD.
Pokud jste vývojář a máte zájem se naučit CI/CD, podívejte se na tento skvělý kurz.
Líbil se vám tento článek? Co takhle ho sdílet s ostatními?