DevOps, o kterém většina začátečníků zakopne

Další pastí je nesprávné nastavení oprávnění pro token. Pokud potřebujete nasadit na vzdálený server, použijte buď osobní přístupový token, nebo nasadzovací klíč. Nejbezpečnější je vytvořit samostatný deploy token s minimálními právy, který uložíte do Secrets v nastavení repozitáře. Nikdy nedávejte token přímo do YAML souboru, protože by se mohl dostat do historie commitů. Vždy odkazujte na proměnnou, třeba $ secrets.DEPLOY_TOKEN , a v nastavení repozitáře ji definujte.

Posledním doporučením je testovat pipeline na menší větvi, ne rovnou na main. Vytvořte si větvičku s názvem test-actions, kde si ověříte, že všechny kroky fungují, a teprve poté změnu sloučíte. Tím se vyhnete situaci, kdy rozbijete produkční nasazení kvůli překlepu v YAML. Až budete mít pipeline stabilní, můžete přidat i nasazení do stagingu před produkci, aby se chyby odhalily dřív.

Stabilita databáze také závisí na správě připojení. Sdílená připojení jsou sice úsporná, ale pokud je aplikace používá nesprávně, může dojít k vyčerpání dostupných připojení a k pádu celého systému. Nastavte si maximální počet připojení, časové limity a nezapomeňte na ověření, že se připojení po dokončení transakce správně uvolňuje. Častou chybou je držet připojení otevřené při dlouhých operacích nebo při čekání na uživatelský vstup – to zbytečně blokuje zdroje a zhoršuje odezvu pro ostatní uživatele.

Při psaní testů se také vyplatí myslet na to, co přesně testujete. Pokud testujete funkci, která počítá cenu s DPH, netestujte zároveň i databázové spojení. To už je integrační test. Jednotkové testy mají být rychlé, izolované a bez vedlejších efektů. Pokud potřebujete testovat závislost na vnějším systému, použijte mock. Ale mockování má také své úskalí – pokud zamockujete příliš mnoho, test přestane testovat skutečnou logiku a začne testovat jen to, jak jste mock nastavili. Zamockujte jen to, co je nezbytně nutné, a zbytek nechte běžet reálně.

Nakonec se zamyslete nad tím, co se stane, když databáze přestane být dostupná. Aplikace by měla umět elegantně zpracovat výpadek – zobrazit uživateli srozumitelnou hlášku, uložit rozpracovaná data do dočasného úložiště a po obnovení spojení se synchronizovat. Mít záložní server je sice užitečné, ale pokud aplikace neumí přepnout na něj automaticky, je to jen další komplikace. Naplánujte si scénáře selhání a otestujte je dříve, než k nim dojde v produkčním prostředí.

Když zákazník požádá o odhad času, většina z nás automaticky vsadí na optimismus. V duchu si řekneme, že to stihneme dřív, a sdělíme termín, který nás pak dostane pod tlak. Výsledek? Zpoždění, omluvy a zákazník, který vám přestane věřit. Přitom stačí změnit způsob, jakým o čase mluvíte, a komunikace se stane nástrojem důvěry místo zdrojem stresu.

Častou chybou je také snažit se odhadnout čas bez dostatečných informací. Než cokoli slíbíte, zeptejte se na detaily zadání. Čím víc toho víte o rozsahu práce, tím přesnější odhad můžete dát. Pokud informace chybí, řekněte to na rovinu: „Teprve po analýze zadání vám dám konkrétnější termín." Zákazník ocení, že nejednáte naslepo. Když se ale zadání během práce změní, nebojte se odhad aktualizovat. Mlčet až do termínu a pak omlouvat zpoždění je to nejhorší, co můžete udělat. Včasná komunikace o novém odhadu je známkou profesionality.

Když už máte první službu v CI, zaměřte se na měření. Klíčové metriky nejsou počet nasazení za den, ale doba od nápadu po produkci a frekvence selhání. Zapisujte si čísla do tabulky, ale neanalyzujte je každý den — stačí týdenní revize. Pokud vidíte, že jsou nasazení častější, ale výpadky se nemění, děláte to dobře. Když se ale výpadky začnou množit, přibrzděte a přidejte víc testů, ne další automatizace.

Jak sestavit efektivní kroky a vyhnout se častým chybám Pište kroky tak, aby byly co nejkratší a nejpřehlednější. Jeden krok by měl dělat jednu věc – checkout, instalace závislostí, testy, build, nasazení. Typickou chybou je kombinovat více příkazů do jednoho kroku, což ztěžuje ladění a případné opakování. Místo toho použijte samostatné kroky s jasným názvem, třeba „npm install" a „npm test". Pokud některý krok selže, GitHub Actions vám ukáže přesně, který to byl, a vy nemusíte procházet celý log.

Typické chyby, které kazí dojem z aplikace Mezi nejčastější prohřešky patří ignorování stavu načítání. Když uživatel klikne na tlačítko a nic se neděje, má pocit, že se aplikace zasekla. Vždy poskytněte zpětnou vazbu – ať už jde o spinner, změnu barvy tlačítka nebo text „Ukládám…". Stejně důležité je ošetřit chybové stavy: místo obecného „Došlo k chybě" napište konkrétně, co se nepovedlo a jak to uživatel může opravit. Například „Zkontrolujte připojení k internetu" nebo „Zadané heslo je příliš krátké". Uživatel pak nemusí hádat a může problém rychle vyřešit.