Edytujesz 5 kroků, jak oddělit verzování kódu od konfigurace

Testů přes skutečné uživatelské rozhraní drž co nejméně. Jsou pomalé a křehké: stačí posunout tlačítko a přestanou fungovat. Piš je jen pro kritické cesty – přihlášení, dokončení objednávky, smazání účtu. Vždy hledej prvek podle stabilního identifikátoru, ne podle textu, který se překládá. Počkej na stav, ne na pevný počet sekund; pevné čekání je nejčastější důvod, proč testy na pomalém počítači padají. A když test spadne, podívej se nejdřív, jestli není chyba v testu samotném.<br><br>Verzování není jen číslo v U<br><br>Další častá chyba je ignorování změny licence u již používané knihovny. Projekt může přejít z permisivní licence na copyleftovou a vy se to dozvíte až při auditu. Proto se vyplatí sledovat oznámení o vydání nových verzí a mít v projektu zmrazenou verzi, kterou ověříte. Aktualizace bez kontroly licence je riziko, které se neprojeví hned, ale o to hůř se řeší zpětně.<br><br>Praktický postup: veďte si seznam všech přímých i nepřímých závislostí včetně jejich licencí. U každé položky poznamenejte, zda ji distribuujete, nebo jen používáte. Pokud distribuujete, ověřte, zda licence vyžaduje zveřejnění zdrojového kódu, uvedení autora nebo zachování textu licence. Nástroje pro analýzu závislostí tento přehled zvládnou automaticky, ale jejich výstup je nutné číst, ne jen archivovat.<br><br>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.<br><br>Jakmile jazyk zvolíte, držte se ho alespoň půl roku. Přechod na jiný jazyk je mnohem snazší, když už máte za sebou první hotový projekt, protože principy jako cykly, podmínky, funkce a datové struktury se opakují. Sledujte, zda vás práce s jazykem baví, nebo zda vás spíše frustruje. Frustrace z nástroje je legitimní důvod ke změně, ale frustrace z vlastní neznalosti je důvod k vytrvání. Rozhodujte se podle dokončených projektů, ne podle pocitů z prvního týdne.<br><br>Závislost na open source tedy není jen otázka licence. Je to kombinace právních podmínek, aktivity komunity a toho, jak software používáte. Kdo tyto tři věci drží odděleně a kontroluje je průběžně, vyhne se překvapením při vydání produktu i při jeho dlouhodobé údržbě.<br><br>Kopírování licence nestačí, rozhoduje soulad s vaším produktem Nejčastější chyba je předpoklad, že když je něco open source, můžu to použít kdekoli. Není to pravda. Copyleftové licence vyžadují, abyste při šíření odvozeného díla zachovali stejná práva. To znamená, že pokud kód vložíte do uzavřeného produktu a distribuujete jej, můžete být nuceni zveřejnit vlastní úpravy. U interního nasazení, kde software neopouští firmu, se povinnosti často neuplatní. Rozdíl mezi distribucí a používáním je zásadní a bývá zdrojem sporů.<br><br>Open source licence řeší něco jiného, než si většina vývojářů myslí. Neřídí, jak je software kvalitní ani jak snadno se udržuje. Určuje pouze práva k šíření a úpravám kódu. Z toho plyne první past: tým si vybere knihovnu podle licence, ale zapomene zjistit, kdo ji skutečně vyvíjí, jak často vydává opravy a zda vůbec reaguje na hlášené chyby. Licence je právní rámec, ne záruka budoucnosti.<br><br>Typická chyba je snaha verzovat všechny konfigurace ve stejné větvi jako kód s odůvodněním, že se to tak dělalo vždy. Druhá chyba je ukládat tajemství do gitignore a myslet si, že jsou v bezpečí. Gitignore není trezor, pouze brání nechtěnému přidání. Pokud už tajný klíč unikl do historie, nestačí ho smazat v dalším commitu. Je nutné klíč zneplatnit a vyměnit, protože historie zůstává dostupná všem, kdo mají přístup k repozitáři.<br><br>Verzovat kód a verzovat konfiguraci v jednom repozitáři je nejčastější zdroj konfliktů, nechtěných commitů a tajných klíčů v historii. Kód se mění v logických celcích, konfigurace se mění podle prostředí, tajemství a času nasazení. Dokud obojí leží v jedné větvi, každý deploy znamená ruční mazání řádků, které do gitu nepatří, nebo naopak zapomenutý soubor, který shodí produkci. Oddělení není jen o složkách, ale o tom, kdo co smí měnit a jak se to dostane na server.<br><br>Pro oddělení se vyplatí zavést šablony a generátory. Konfigurační soubory pište jako šablony s placeholdery a hodnoty doplňujte při nasazení z bezpečného úložiště. Tím se konfigurace stává reprodukovatelnou a verze kódu určuje, jaké klíče aplikace očekává. Když se změní název proměnné, změní se i šablona, ale hodnoty zůstávají mimo repozitář. Výsledkem je, že historie kódu je čistá a konfigurace se dá kdykoli vrátit zpět bez zásahu do zdrojáků.