Když Git nepoužíváš, přijdeš o práci i klid

Větve, konflikty a jak je řešit bez paniky Větve ti umožní zkoušet změny, aniž bys rozbil hlavní verzi. Vytvoříš ji příkazem git branch nazev a přepneš se pomocí git checkout nazev. Když na větvi dokončíš práci, sloučíš ji do hlavní pomocí git merge. Právě při sloučení vznikají konflikty, pokud se stejná část souboru změnila na dvou místech. Git ti je označí v souboru a ty musíš ručně rozhodnout, která verze zůstane. Nenechávej konflikt nevyřešený a necommituj ho – vznikne zmatek, který se těžko rozplétá.

Začněte tím, že si před odhadem ujasníte, kde analytika končí a implementace začíná. Analytika obvykle zahrnuje sběr požadavků, rozpracování scénářů, návrh datových toků, dohodu s byznysem a zápis akceptačních kritérií. Implementace je pak samotný kód, testy, revize a nasazení. Pokud tyto hranice nejsou pojmenované, lidé si pod pojmem „hotovo" představují různé věci a odhad se rozpadne při prvním upřesňování.

Past, na kterou doplatí každý začátečník Nejčastější chyba je snaha zavést vše najednou. Tým si přečte o orchestrátorech, CI serverech a monitoringu a začne je nasazovat paralelně. Výsledkem je změť nástrojů, kterým nikdo pořádně nerozumí, a zpomalení místo zrychlení. Začněte jedním krokem, který bolí nejvíc. Pokud jsou nasazení ruční a v pátek večer, zaveďte nejdřív jednoduchou pipeline, která po každém commitu spustí testy. Teprve když to funguje spolehlivě, přidejte automatické nasazení do testovacího prostředí. Až potom řešte produkci. Každý krok by měl mít jasného vlastníka a měřitelný výsledek, jinak se z DevOps stane jen další byrokracie.

Kde se chyby opakují nejčastě

Na závěr mějte pravidla krátká a vynutitelná. Napište je do souboru v repozitáři, ať jsou po ruce. Automatizujte, co jde: testy, kontrolu stylu, ochranu větví. Lidské dohady nahraďte jasnými pravidly a tým přestane řešit proces a začne řešit práci.

Začněte malým, ale dokončeným krokem. Zvolte jednu službu, jeden repozitář a jednu pipeline. Dotáhněte ji do stavu, kdy ji používá celý tým denně. Teprve pak rozšiřujte na další části systému. Vyhnete se tak vyhoření a získáte skutečnou zkušenost, na které se dá stavět. DevOps je cesta, ne cíl.

Důležité je také nastavit monitoring a logování dřív, než je budete potřebovat. Bez zpětné vazby z produkce nepoznáte, jestli se změna povedla. Stačí sbírat základní metriky: počet chyb, dobu odezvy a vytížení. Tyto údaje pak používejte při rozhodování, co dál zlepšovat. Vyhněte se ale sbírání všeho jen proto, že to jde. Příliš mnoho dat bez kontextu vede k tomu, že se na alarms nikdo nedívá. Lepší je méně signálů, kterým tým věří.

DevOps není nástroj ani jednorázový projekt. Je to způsob, jakým vývojáři a provozní tým spolupracují na tom, aby se změny dostávaly do produkce rychle, bezpečně a opakovaně. V praxi to znamená, že někdo, kdo napíše kód, nese odpovědnost i za to, jak tento kód běží. Nejde o to koupit si sadu nástrojů, ale změnit každodenní postupy. První krok je přiznat, kde v současnosti trávíte nejvíce času ručními zásahy: nasazování, rollbacky, řešení rozdílů mezi vývojovým a produkčním prostředím.

Začít se dá bez velkých investic. Sepište si, co všechno se musí stát mezi commitem a funkční aplikací v produkci. Zjistíte, že většina kroků je stejná, jen je dělá jiný člověk nebo jiný skript. První užitečná věc je sjednotit konfiguraci prostředí, ideálně pomocí souborů, které jsou součástí repozitáře. Když vývojář spustí aplikaci lokálně stejně jako v produkci, zmizí celá třída chyb, které se jinak řeší až po nasazení. Vyhněte se ručním úpravám na serveru, protože ty se nikde nezaznamenají a příští nasazení je přepíše.

Lidé jsou nakonec důležitější než nástroje. DevOps vyžaduje, aby se vývojáři nebáli mluvit o provozu a provozní tým se nebál ptát na změny v kódu. Zaveďte krátké společné schůzky, kde se řeší překážky, ne obviňování. Chyby berte jako informaci, ne jako selhání jednotlivce. Bez této kultury budou sebelepší nástroje jen drahá dekorace. Pokud se tým bojí cokoliv změnit, žádná automatizace to nespraví.

Git se nejlépe učí na malém projektu. Založ si složku s několika textovými soubory, zkoušej větve, maž je a znovu vytvářej. Neboj se experimentovat; dokud máš commitnutou fungující verzi, můžeš se k ní vrátit. Když si osvojíš základní cyklus add, commit, branch, merge, přestane být verzování překážkou a stane se nástrojem, který ti dává jistotu.

Pro spouštění v CI slouží příkaz pytest s parametrem --junitxml, který vytvoří strojově čitelný výstup. Pokrytí kódu změříte pluginem pytest-cov a příkazem pytest --cov=. Neusilujte ale o stoprocentní pokrytí za každou cenu. Důležité je pokrýt logiku a hraniční případy, ne každý řádek. pytest nabízí i možnost přeskakovat testy pomocí skipif nebo označit očekávaná selhání přes xfail. Tyto značky udržují sadu testů čitelnou i ve chvíli, kdy některé části ještě nejsou hotové.