Větev, nebo trvalá integrace: co snesete v týmu

Nespoléhejte na to, že si každý pamatuje pravidla. Napište je do souboru v repozitáři a odkažte na něj v popisu projektu. Stačí pět až deset bodů: odkud větvit, jak pojmenovávat commity, kdy slučovat, kdo schvaluje. Nový člověk v týmu tak nemusí hádat a vy nemusíte řešit stejné otázky pořád dokola. Pravidla ale musí být krátká, jinak je nikdo nečte.

Častou chybou je, že vývojáři simulují příliš mnoho nebo příliš málo. Příliš mnoho simulace vede k testům, které neodhalí skutečné problémy, protože se chovají jinak než produkce. Příliš málo simulace znamená, že testy jsou pomalé a nespolehlivé. Držte se pravidla: simulujte jen to, co nemůžete mít pod kontrolou, a to věrně. Pokud externí služba vrací data v určitém formátu, váš simulátor musí vracet stejný formát včetně okrajových případů, jako jsou prázdné odpovědi, chybové kódy nebo neočekávané typy.

Při návrhu podpory pro vzdálený vývoj se nejčastěji chybuje v tom, že se řeší až samotný provoz. Tým se soustředí na to, jak se vývojář připojí, ale zapomene na to, co bude potřebovat za měsíc, až se projekt rozroste. Přitom právě podpora vývoje určuje, jestli vzdálená spolupráce vydrží tlak. Pokud ji podceníte, dřív nebo později narazíte na výpadky, zpomalení a frustraci na obou stranách.

Pro datové vstupy použijte fixture soubory nebo továrny na testovací data. Místo ručního vytváření objektů v každém testu definujte šablony s výchozími hodnotami a v konkrétních testech měňte jen to, co je podstatné. Vazby mezi daty simulujte pomocí jednoduchých struktur, které respektují referenční integritu. Například místo skutečné databáze použijte kolekci v paměti, která se na začátku testu naplní a na konci vyčistí. Pokud testujete chování při výpadku, simulujte chyby – vyhoďte výjimku, nastavte časový limit nebo vracejte neúplná data.

Dalším častým omylem je ignorování latence a stability připojení. Vzdálený vývoj neznamená jen jinou kancelář, ale i jinou síť. Testujte proto práci s repozitářem, buildy a databázemi z prostředí, které odpovídá tomu vzdálenému. Pokud něco trvá déle než pár sekund, hledejte příčinu dřív, než se to stane každodenní realitou. Malá prodleva u každé operace se nasčítá do hodin.

Testovat aplikaci, která komunikuje s externími systémy, je ošidné. Pokud spoléháte na skutečné služby, testy jsou pomalé, nespolehlivé a drahé. Řešením je nahradit tyto služby testovacími dvojníky – falešnými objekty, stuby nebo mocky. V tomto článku si ukážeme, jak na to, abyste odstranili závislost na živých externích službách a přesto otestovali všechny důležité scénáře.

Kde se podpora láme nejčastěji Největší problém bývá v tom, že se podpora vývoje řeší odděleně od zbytku infrastruktury. Vývojář pak narazí na to, že mu chybí oprávnění, které nikdo nepřidělil, nebo že prostředí neodpovídá tomu, na co je zvyklý. Vyhněte se tomu tak, že přístupy a prostředí popíšete jako kód. Když se změna zapíše do verzovacího systému, je dohledatelná a opakovatelná. Ruční nastavení se dřív nebo později rozpadne.

Většina týmů se pře o to, jestli používat feature větve, nebo commitovat přímo do hlavní linie. Rozhodnutí není ideologické, ale praktické: záleží na tom, jak často vydáváte, jak velký je tým a jestli máte automatické testy. Pokud testy chybí, trvalá integrace znamená, že rozbitý kód blokuje všechny. Pokud testy máte, přímé commity do hlavní větve výrazně zkracují cestu od nápadu k nasazení.

Při návrhu testů dbejte na izolaci. Každý test by měl mít vlastní instanci falešné služby, aby se výsledky neovlivňovaly. Pokud používáte dependency injection, je to snadné – v testu předáte mock, v produkci skutečnou implementaci. Vyhněte se globálním stavům a singletonům, které by mohly unikat mezi testy. Také nezapomeňte testovat, že aplikace volá externí službu správným způsobem – tedy že předává správné parametry a volá ji ve správný čas. K tomu slouží ověřovací metody na mockách.

Triky pro simulaci chyb a zpoždění Externí služby občas selžou, odpovídají pomalu nebo vracejí neplatná data. Právě tyto stavy je nutné testovat. Do falešné implementace proto zabudujte možnost simulovat chyby – například nastavitelný příznak shouldFail nebo frontu odpovědí. Můžete tak ověřit, že aplikace správně zpracuje výjimku, zobrazí uživateli srozumitelnou zprávu a nezhroutí se. Podobně simulujte zpoždění: přidejte umělé čekání, abyste zjistili, zda aplikace nezamrzne nebo zda správně aplikuje timeout.

Hlavní větev držte vždy nasaditelnou. To znamená, že každý commit do ní by měl projít testy a být schopný jít do produkce. Pokud potřebujete práci uložit, ale ještě není hotová, použijte větev nebo koncept, ne hlavní linii. Rozbitá hlavní větev zastaví celý tým – všichni na ní staví a nikdo nemůže bezpečně pokračovat. Oprava se pak dělá pod tlakem a vznikají další chyby.