CI/CD Pipeline - jak řešíme v Dactylu nasazování webových aplikací

,,Nasazíno!”

Tohle je oblíbený výkřik našich vývojářů. Nezmiňujeme teď žádnou událost z jejich soukromých životů. Hovoříme o časté události vývojového cyklu každého projektu. Ano, jedná se o nasazení nové verze projektu na produkční prostředí. Jak to u nás chodí? Pojďte se začíst do dalšího odbornějšího článku. 

Od manuálního kopírování k automatizovanému nástroji

Jako firma jsme prošli více stadii – od manuálního kopírování změněných souborů přes FTP anebo konzolové kopírování přes SCP až po zavedení verzovacího systému GIT, kde bylo konečně možné stahovat změny daného prostředí inteligentně a bez konfliktů. 

Nebylo to ale pohodlné. Stále to od programátora vyžadovalo přihlášení na daný server přes příkazový řádek a zadávání sad příkazů. Brzy proto přišel čas zkusit najít nějakou automatizovanou pomůcku. Pár let jsme zkoušeli Jenkins, který je napsaný v Javě a mohl běžet lokálně na našich serverech. Uvítali bychom sice přívětivější grafické rozhraní, ale komplexně to dělalo, co mělo. Náš mobilní tým už ho navíc předtím delší čas používal na některé procesy, takže jeho zaběhnutí netrvalo dlouho. 

První 2-3 roky jsme všechny projekty verzovali na lokálním GIT úložišti v jednom brněnském datacentru. Čas ale utíkal, a jak se naše firma pořád rozrůstala, do vývoje začalo přicházet mnohem víc procesů, třeba revize programového kódu, testování projektů, tvorba kopií na různé prostředí apod. Tehdy jsme navždy řekli sbohem Jenkinsu a přešli na modernější řešení, které zvládalo všechny zaznamenané problémy. 

GitLab – aplikace, kterou používáme dodnes

Na pomoc jsme si ho poprvé vzali cca někdy na přelomu let 2016/2017. GitLab je moderní (nejen) webový správce Git repozitářů, velmi inspirovaný populární službou GitHub. Svou koncepcí je zaměřený primárně na práci se zdrojovým kódem, čímž se odlišuje od klasických ,,manažerských” nástrojů typu Redmine. Oproti GitHubu je určen hlavně do prostředí intranetu, tedy pro neveřejné projekty. 

Co GitLab umí a čím se vyznačuje? 

• Jedná se o komfortní prohlížeč kódu s úzkou návazností na Git.
• Umožňuje jednoduše přidávat komentáře k jednotlivým komitům nebo přímo ke konkrétním řádkům kódu.
• Poskytuje issue tracking.
• Disponuje jednoduchou Wiki s podporou Markdown.
• Má plynulé a skvěle ovladatelné UI (napsané ve Vue.js).
• Těší nás jeho merge requests (obdoba pull requestu z GitHub) – vytvoření požadavku na začlenění komitu z jedné vývojové větve do druhé, kde pověření členové mohou rozhodnout, jestli ho začlenit nebo ne, případně u něho vést diskuzi.
• Podporuje REST API.
• Přináší Service Desk.
• Funguje automatizace nasazení kódu a procesů nad kódem aka CI/CD. 

Automatizace nasazení kódu a spouštění procesů nad kódem 

Pojďme si tuto záležitost přiblížit na reálném příkladu. Po tom, co vývojář spustí vyvinutý kód, v GitLabu se nad kódem automaticky spustí 2 procesy: 

1. kontrola kvality kódu,
2. projektové testy. 

Pro kontrolu kvality kódu používáme modul Codeclimate. Výsledkem je bodové hodnocení, o kolik se kód zhoršil/zlepšil od minulého komitu. Přináší také přehled doporučených úprav a problémových míst. 

Projektové testy jsou definované přímo v kódu. Při našich webových projektech se většinou jedná o unit testy psané pro Codeception modul, jehož úspěšnost je povinná. 

Pokud testy neprojdou, automatizovaný proces (jinak řečeno Pipeline, [pajplajna]) se zastaví a zablokuje začlenění komitu do hlavní větve. Vývojáři zároveň přijde na e-mail oznámení o problému s jeho komitem a vyzve ho k opravě. 

V případě úspěchu testů je hlavní vývojář nebo revizor schopný začlenit změny do hlavní větve. Kód by ale měl projít ještě manuálně, a pokud se mu něco nezdá, dané části kódu okomentovat a přiřadit vývojáři zpět. 

Při spokojenosti revizora a začlenění změn do hlavní větve náš automatizovaný proces vyvolá spuštění další pajplajny, která má za úkol změny nasadit na první mimolokální prostředí (testovací prostředí, zkráceně test env). V něm pracují naši nerobotičtí testeři. Snaží se odhalit všechny chyby, které by se bez nich mohly dostat až ke klientovi. 

Nasazení na test env je automatické bez potřeby manuální akce. Ta stejná pajplajna umožňuje jedním kliknutím nasadit kopii projektu na druhé mimolokální prostředí, čímž je staging, někdy též nazývané klientské testovací prostředí. Tam už musíme být opatrnější, protože klient si tam může chystat data pro pozdější přenos na produkci. 

Když jsme u té produkce – o nasazení na ni se stará další, v pořadí třetí, pajplajna. Spustí se po tom, co vývojář pověřený nasazením začlení změny z hlavní vývojové větve do produkční větve. Tato akce je volitelná, ale zároveň doporučená hned po začlenění. Jenom tak může produkční větev zrcadlit reálný stav produkce na serveru. 

V tomto bodě jsou změny venku, a pokud je to možné, testujeme nové úpravy i na produkci. V opačném případě nezbývá nic jiného, než se modlit.

Tak k našemu stylu nasazování práce na aplikacích. Autorem tohoto textu je Martin Kéri, náš senior PHP Developer.