Provedení vydání scrumu – od přípravy obsahu po nasazení

Alternativní přístup k vydávání v agilním prostředí

V kontextu agilního vývoje, a zejména metodologie Scrum, se často setkáváme s očekáváním, že vydání produktu následuje ihned po skončení sprintu, typicky po úspěšné demonstraci pro klienta. Tento automatismus však může být zavádějící, pokud vezmeme v úvahu různorodé aktivity, které předcházejí samotnému vydání, nebo se s ním prolínají.

Zvažme následující kroky, které se obvykle odehrávají před uvolněním produktu:

• Dokončení všech naplánovaných uživatelských příběhů v rámci sprintu. Často se stává, že některé příběhy jsou dokončovány až těsně před koncem sprintu, nebo dokonce po prezentaci dema.
• Realizace všech testů, abychom zajistili, že kód je připraven k nasazení do produkčního prostředí.
• Odstraňování nalezených chyb a jejich rychlé opravování před vydáním.
• Aktualizace kanálu pro nasazení a zajištění jeho spolehlivé funkčnosti.
• Spuštění kanálu ve všech relevantních prostředích, aby bylo zajištěno, že všechna prostředí jsou aktuální z hlediska kódu i dat.
• Příprava poznámek k vydání a komunikace s klientem ohledně dopadu změn.
• Synchronizace s ostatními Scrum týmy, pokud existují závislosti, aby nedošlo k chybějícímu obsahu, který by ohrozil funkčnost vydané verze.
• Navíc je potřeba se věnovat všem agilním ceremoniím, a to nejen těm, které se týkají aktuálního sprintu, ale i přípravám na sprinty budoucí (např. upřesňování uživatelských příběhů).

A to vše se má odehrát v časovém rámci dvoutýdenního sprintu. Samotné aktivity spojené s vydáváním vyžadují čas a zapojení lidských zdrojů. Často se však stává, že tyto činnosti zasahují i do prvního dne následujícího sprintu, a tak se cyklus opakuje. Není tedy automatické očekávání vydání po každém sprintu poněkud nereálné?

Zpracování obsahu pro vydání

Ideální stav by byl, kdyby všechny procesy v rámci sprintu byly plně automatizované, což by umožnilo pouhé „stisknutí spouště“ a instalaci nejnovější verze kódu do produkce na konci každého sprintu. Nicméně, realita je taková, že málokterý tým dosáhne takové úrovně zralosti, zvláště v korporátním prostředí. Naopak, procesy uvolňování často vyžadují značné časové investice a ovlivňují i následující sprint, a to jak z hlediska obsahu, tak i metrik. Vydávání se pak stává spíše stresujícím aktem, než přirozenou součástí procesu. Proto jsem hledal efektivnější scénář pro řešení těchto situací.

Řešení spočívá v tom, že se každý druhý sprint stane vydávacím sprintem. Zde je vysvětleno, co to znamená.

Samostatná větev pro kód budoucího vydání

Jedná se o využití oddělených větví v repozitáři GIT. Existuje více způsobů, jak k tomuto problému přistoupit, ale pro zjednodušení budu prezentovat jeden z nich, abych demonstroval jeho princip a dopad.

Pro minimalizaci dopadu na probíhající vývojové aktivity je klíčové oddělit obsah budoucího vydání do samostatné větve, kterou nazveme "Release Branch". Tím dosáhneme následujících výhod:

• Vývojový tým může nerušeně pokračovat v práci na nových funkcích a začleňovat je do hlavní větve.
• Eliminuje se riziko, že by obsah vydání byl ovlivněn neočekávanými úpravami kódu.
• Testování probíhá v izolovaném prostoru, kde se implementují pouze změny nezbytné k vyřešení případných problémů.
• Vzhledem k tomu, že do produkce se nasazuje pouze obsah z "Release Branch", máme jasný přehled a kontrolu nad tím, co je vydáváno. Eliminujeme riziko, že by neočekávaný commit do jiné větve narušil již otestovaný kód.

Tímto způsobem zajistíme, že obsah budoucího vydání bude v stabilním a připraveném stavu k uvolnění.

Pravidelné načasování vydání

Opustil jsem myšlenku vydávat po každém sprintu. Bylo jasné, že to dlouhodobě nemůže fungovat. Alespoň ne bez vedlejších negativních dopadů, jako jsou:

• ovlivňování obsahu následujícího sprintu,
• nemožnost stabilizace obsahu určeného k vydání,
• nestíhání všech požadovaných testovacích aktivit.

Cílem se tedy stalo realizovat vydávání na konci každého druhého sprintu. To přináší následující benefity:

• Vydání bude obsahovat funkcionality z posledních dvou dokončených sprintů. Vzhledem k tomu, že vydání probíhá v rámci aktuálního sprintu, jeho obsah není ještě součástí uvolňované verze.
• Na dokončení testovacích aktivit a oprav chyb je vyhrazen celý jeden sprint.
• Vlastník vydání má dostatek času na shromáždění všech potřebných informací (testovací případy, poznámky k vydání) bez ovlivňování zbytku vývojového týmu, který se tak může věnovat práci na nových funkcích.
• V případě nalezení chyby může vlastník vydání rychle spolupracovat s konkrétním vývojářem a následně se vrátit k aktuálnímu obsahu sprintu. Vždy by proto mělo být vyhrazeno určité procento času z kapacity týmu pro podporu těchto oprav.

Je zřejmé, že uživatelé nedostanou nejnovější obsah sprintu v nejnovější verzi. Nicméně časem se toto stane nepodstatným, protože s každým dalším vydáním, po každém druhém sprintu, získají vždy obsah za dva sprinty. Zdá se to jako dobrý kompromis mezi rychlým dodáním a udržováním tempa s aktivitami v agilním vývoji bez rušení.

Realizace nasazení

Po úspěšném dokončení testování, oprav chyb a připravenosti kanálu, je spuštění produkčního kanálu a dokončení vydání v produkci relativně jednoduchým procesem. Vzhledem k tomu, že se nasazuje ze samostatné větve, může to být v podstatě nepozorovaná aktivita, které si nikdo nemusí všimnout. Pokud tomu tak je, tak je to nejlepší možná implementace nasazení vydání.

Předpokladem pro takovýto proces je vytvoření robustního automatizovaného kanálu DevOps, který se používá nejen pro nasazení do produkčního prostředí, ale i do všech ostatních prostředí nižší úrovně (vývoj, sandbox, test, zajištění kvality, výkonové prostředí). Nasazení pro všechna tato prostředí by mělo být záležitostí jednoho kliknutí. Vydání by nemělo být zdrojem stresu ani noční můrou, ale naopak, pokud si ho nikdo nevšimne, je to nejlepší důkaz úspěšného vydání.

Sloučení uvolňovací větve zpět do vývojové větve

Vydávací větev ("Release Branch") nyní obsahuje opravy a úpravy, které neexistují v běžné vývojové větvi. Tyto změny je nutné začlenit zpět, aby byly k dispozici i pro budoucí vydání. Tato větev zároveň slouží jako záloha produkčního kódu. V případě akutní potřeby je možné z ní nasadit opravu do produkce. Je to přesná kopie aktuálního produkčního kódu bez nového obsahu.

Po spuštění nového testovacího období se může předchozí větev vydání smazat a nahradit novou, která vznikne jako kopie aktuální vývojové větve.

Zavedení pravidelných vydání

Máme funkční proces pro vydávání. Poslední věc je pravidelné dodržování tohoto procesu, v tomto případě po každém druhém sprintu.

Pravidelnost přináší zjednodušení a stabilitu, a to zejména proto, že:

• Mezi jednotlivými vydáními není velký objem nového obsahu. Přírůstky jsou menší a stabilnější.
• Menší objem nového obsahu znamená méně testovacích aktivit a testovacích případů. Méně komunikace a spolupráce se stakeholdery ohledně toho, co je třeba znovu ověřit. Shodnou se na tom, že od posledního vydání neuplynula tak dlouhá doba.
• Tým si na cyklus zvykne a stane se přirozenou součástí jeho fungování.
• V rámci testovacího cyklu se obnovují data ve vývojových a testovacích prostředích, což je v podstatě pravidelný krok, a nemělo by to být vnímáno jako extra činnost. Tento posun v perspektivě má velký vliv na atmosféru v týmu.

Závěr

Tímto uzavírám své předchozí příspěvky na téma životního cyklu agilního vývoje. Jde o přístup, který se osvědčil v reálné praxi.

Týmy často začínají s agilním přístupem a dělají chyby. Nicméně postupně se vyvíjejí a adaptují své procesy. Tato série článků by jim mohla pomoci urychlit tento proces. Tento přístup k vydávání není jediný správný a není bez problémů. Nicméně týmy by měly hledat způsoby, jak ho vylepšovat a opustit ty, které se neosvědčily. Tento, byť jednoduchý přístup ukázal, že změna je možná. Z chaotických a nepředvídatelných sprintů je možné dosáhnout stabilnějšího dodávání produktů s pravidelnými a plánovatelnými vydáními. K tomu není potřeba složitá metodologie, ale pouze jednoduchá pravidla a ochota se jich držet.