AlissaBoggs21: Created page with "Nejprve si zmapujte, jak u vás dnes probíhá nasazování kódu. Sedněte si s vývojáři i provozem a zjistěte, kde to skřípe. Překvapí vás, že většina problémů není technických, ale komunikačních. Zaveďte pravidelné schůzky, kde si obě strany řeknou, co potřebují. Důležité je, aby se vývojář nebál zeptat provozu na infrastrukturu a provoz zase rozuměl tomu, co kód dělá. Bez důvěry vám žádná technologie nepomůže.

Začn..."

2026-08-21T18:51:18Z

Created page with "Nejprve si zmapujte, jak u vás dnes probíhá nasazování kódu. Sedněte si s vývojáři i provozem a zjistěte, kde to skřípe. Překvapí vás, že většina problémů není technických, ale komunikačních. Zaveďte pravidelné schůzky, kde si obě strany řeknou, co potřebují. Důležité je, aby se vývojář nebál zeptat provozu na infrastrukturu a provoz zase rozuměl tomu, co kód dělá. Bez důvěry vám žádná technologie nepomůže. Začn..."

New page

Nejprve si zmapujte, jak u vás dnes probíhá nasazování kódu. Sedněte si s vývojáři i provozem a zjistěte, kde to skřípe. Překvapí vás, že většina problémů není technických, ale komunikačních. Zaveďte pravidelné schůzky, kde si obě strany řeknou, co potřebují. Důležité je, aby se vývojář nebál zeptat provozu na infrastrukturu a provoz zase rozuměl tomu, co kód dělá. Bez důvěry vám žádná technologie nepomůže. Začněte s jedním malým automatizačním krokem Jakmile máte jasný obrázek o procesu, vyberte si jednu jednoduchou věc, kterou automatizujete. Ideální je sestavení aplikace nebo spouštění testů. Můžete použít nástroj pro CI/CD, ale nezačínejte s plnou konfigurací pipeline až do produkce. Stačí, když se commit do repozitáře spustí sestavení a spadnou rychlé testy. Uvidíte, kolik času to ušetří a kde jsou slabiny. Jakmile to funguje, přidejte nasazení do testovacího prostředí. Pozor na to, abyste automatizaci nehnali do extrému – pokud je prostředí nespolehlivé, každý chybný automatický krok jen přidá chaos. Nakonec se zaměřte na testování. Redux se díky čistým funkcím testuje snadno: reducer otestujete bez renderování komponenty, action creatory porovnáte s očekávanými objekty. Pro integrační testy použijte renderWithRedux, který obalí komponentu storem. Nezapomínejte testovat i chybové stavy, nejen happy path. Tím odhalíte problémy dřív, než se dostanou do produkce. Při nasazování měřte, co se děje. Sledujte dobu nasazení, počet selhání a průměrnou dobu opravy. Tyto metriky jsou důležitější než rychlost samotného nasazení. Když čísla ukazují, že se něco zhoršuje, vraťte se a opravte to. Častý začátečnický omyl je honit se za co nejrychlejším nasazením a přitom ignorovat stabilitu. Dobré DevOps se pozná podle toho, že je nasazení nudné a bez překvapení. Kde začít: od automatizace po monitoring Prvním praktickým krokem je zavedení verzování kódu, pokud ho už nemáte. Všichni členové týmu musí pracovat s větvemi a pravidelně mergovat změny. Následně nastavte automatizované testy – spouštějte je při každém commitu, abyste chyby odhalili co nejdříve. Důležité je také sjednotit prostředí: použijte kontejnery, aby vývojář, tester i produkce běželi na stejném základu. Tím eliminujete klasický problém „u mě to funguje". DevOps není nástroj ani pozice, ale způsob myšlení a spolupráce. Spojuje vývoj (Development) a provoz (Operations) do jednoho procesu, kde se automatizace, měření a sdílení odpovědnosti stávají standardem. Pokud s DevOps začínáte, klíčové je nejprve pochopit, že cílem není „koupit DevOps", ale změnit kulturu týmu. Začněte malými krůčky: vyberte si jeden projekt, kde můžete automatizovat nasazení, a postupně přidávejte další prvky. Jak na první commit a co dělat při chybách První commit je zásadní okamžik. Než ho provedete, zkontrolujte příkazem, které soubory se mají přidat. Přidejte je a pak vytvořte commit s výstižnou zprávou, která popisuje, co děláte – třeba „Přidán základní layout a responzivní menu". Vyhněte se zprávám typu „oprava" nebo „update", protože po měsíci nebudete vědět, co se vlastně změnilo. Pokud jste udělali chybu v commitu, nepropadejte panice. Git nabízí nástroje pro opravu poslední zprávy, vrácení změn nebo úpravu historie. Důležité je, abyste se nebáli experimentovat na testovací větvi. Až budete mít stabilní základ, rozšiřte automatizaci na monitorování a sběr logů. Ale ani tady nehledejte nástroj, který umí všechno. Vezměte to, co už máte, a pořádně to propojte. Vytvořte jednoduchý dashboard, na který se tým dívá ráno a večer. Pokud vás něco napadne a chcete to vyzkoušet, udělejte to na malém nezávislém projektu. To je nejlepší způsob, jak se učit, protože případná chyba nepoškodí produkci. A hlavně – DevOps není cíl, ale neustálé zlepšování. Nebojte se experimentovat a měnit procesy podle toho, co tým skutečně potřebuje. Na závěr: DevOps je cesta, ne cíl. Počítejte s tím, že první nasazení bude trvat déle, než čekáte, a že narazíte na odpor. Ale pokud vytrváte, odměnou vám bude rychlejší reakce na změny, stabilnější provoz a méně nočních hlášek. Začněte dnes malým krokem – třeba tím, že zautomatizujete jeden ruční úkon, který vás nejvíc štve. Zbytek přijde postupně. Pro zpětnou vazbu používejte model „Situace – Dopad – Návrh". Každý bod musí obsahovat, kdy k situaci došlo, jaký měla dopad na tým a jaký konkrétní postup by situaci zlepšil. Například: „Když jsme v pondělí nasazovali novou verzi, musel jsem čekat na schválení od vedoucího, což zdrželo testování o hodinu. Navrhuji, aby schvalovací právo měl každý seniorní člen týmu." Tento formát nutí mluvit o faktech a řešeních, ne o emocích.

Jak proměnit retrospektivu v akční nástroj pro tým - Revision history