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

Pokud jde o doručení scrumu, lidé obvykle očekávají provedení uvolnění po skončení sprintu. To znamená přímo po úspěšné demo prezentaci klientovi.

Ale vždycky jsem si říkal, jak tohle mohlo být tak automatické očekávání. Zvláště pokud zvážíte níže uvedené možné aktivity, které se musí stát před nebo vedle.

• Rozvíjejte a dokončete všechny příběhy v rámci sprintu. Některé mohou být dokončeny dříve, ale většinou jsou příběhy dokončeny těsně před koncem sprintu. Možná i po demo prezentaci, aby zde bylo otevřeno.
• Proveďte všechny naplánované testy obsahu sprintu, abyste se ujistili, že kód, který má být uvolněn, je připraven na produkci.
• Dohnat objevené chyby a opravit je včas před vydáním.
• Zajistěte, aby byl kanál nasazení aktualizován nejnovějším obsahem a aby bylo spuštění samotného kanálu spolehlivé.
• Spusťte kanál ve všech relevantních prostředích, abyste je uvedli do nejnovějšího stavu z hlediska kódu i dat.
• Připravte si poznámky k vydání a komunikujte s klientem o dopadu vydání ao tom, co přesně se poté změní.
• Pokud je to relevantní, proveďte synchronizaci s ostatními paralelními scrum týmy, abyste zajistili, že závislý obsah bude uvolněn současně. Nic by nemělo chybět, aby obsah vaší verze fungoval podle očekávání.
• K tomu všemu si projděte všechny ceremonie scrumu. Nejen související s aktuálním sprintem, ale také s cíli pro další sprint (např. relace upřesnění příběhů).

A teď si představte, že sprint má dva týdny.

Uvolňovací činnosti samy o sobě vyžadují čas a lidi, aby je dokončily. Ale nesmí to zabrat moc. Těsně po posledním dni sprintu přichází přímo den prvního sprintu a kruh začne znovu.

Vypadá stále očekávání uvolnění po každém sprintu tak automaticky?

Zpracování obsahu vydání

Pokud jsou všechny procesy v rámci sprintu automatizovány, existuje možnost pouze „zmáčknout spoušť“ a nainstalovat nejnovější verzi kódu do výroby na konci každého sprintu. Problém je, že tak dokonalý stav scrum týmu jsem ještě nezažil.

Pokud to tak skutečně je v některých malých soukromých firmách, tak jim to opravdu závidím. Ale realita v korporátním světě je taková, že scrum tým nedosáhne takové úrovně zralosti. Naopak, procesy uvolňování jsou obvykle spojeny s časově náročnými aktivitami, které zasahují do většiny následujícího sprintu, což ovlivňuje tento sprint z hlediska obsahu a všech metrik. Propuštění je jen stresující akt, kterým nikdo v týmu není šťastný.

Takže jsem byl po objevení dalšího nejlepšího scénáře pro řešení vydání.

Závěrem bylo udělat z každého druhého sprintu Release Sprint. Zde je to, co to znamená.

Samostatná verze kódu pro příští vydání

Jedná se o manipulaci s oddělenými větvemi v úložišti GIT. Existuje mnoho způsobů, jak přistupovat ke stejnému problému, a všechny mohou být úspěšné. Ale pro účely tohoto článku budu dělat věci jednoduše, abych demonstroval přístup a jeho dopad.

Aby byl dopad na probíhající vývojové aktivity co nejnižší, je důležité oddělit obsah pro příští vydání do samostatné větve. Říkejme tomu Release Branch. Tímto se vyřeší následující:

• Vývojový tým může bez přerušení pokračovat v aktivitách a začlenit se do nových příběhů hlavní pobočky.
• Neexistuje žádné riziko, že obsah vydání bude ovlivněn neočekávanými úpravami kódu ze strany scrum týmu.
• Testovací činnosti lze provádět v izolovaném prostoru. Zde budou zavedeny pouze změny nutné pro vyřešení testování.
• Vzhledem k tomu, že se v rámci release pipeline nasadí do produkce pouze obsah z Release Branch, máme jasný proces a plnou kontrolu nad obsahem, který má být vydán. Nemůže se stát, že by nějaký neočekávaný commit do větve Git prolomil již otestovaný kód.

Ponechte si tedy obsah dalšího vydání stranou a nechte jej uzavřít do stabilního stavu, připraveného k vydání.

Čas vydání tak, aby fungovaly opakovaně

Vzdal jsem se ambice udělat release po dokončení každého jednotlivého sprintu. Bylo naprosto jasné, že to nebude mít šanci fungovat. Alespoň ne s takovými vedlejšími účinky jako:

• ovlivnit obsah dalšího vývoje sprintu,
• neschopnost stabilizovat obsah uvolňování,
• stihnout všechny požadované testovací činnosti atd.

Cílem tedy bylo provést uvolnění na konci každého druhého sprintu. To by znamenalo následující:

• Vydání bude vždy obsahovat příběhy z posledních dvou již hotových sprintů. Vzhledem k tomu, že se vydání provádí v rámci aktuálního (aktivního sprintu), tento obsah sprintu ještě není součástí vydání.
• Na dokončení nezbytných testovacích činností a oprav chyb je celý jeden sprint.
• Vlastník vydání má dostatek času na shromáždění informací souvisejících s vydáním (testovací případy, poznámky k vydání atd.) pomocí sprintu bez vydání. Tímto způsobem mohou fungovat v podstatě samostatně a udržet zbytek vývojového týmu v práci na nových příbězích.
• V případě zjištění chyby se vlastník vydání může rychle spojit s konkrétním vývojářem, aby problém vyřešil a vrátil se k aktuálnímu obsahu sprintu. Vždy by tedy mělo existovat určité procento času přiděleného z kapacity týmu na podporu této opravy chyb. Kolik přesně lze zjistit v průběhu času.

Je jasné, že uživatelé v nejnovější verzi nedostanou nejnovější obsah sprintu. Ale časem to bude irelevantní. Stejně dostanou dva sprinty obsahu s každým dalším vydáním, po každém druhém sprintu.

Vypadá to jako dobrý kompromis mezi spokojeností s rychlým doručením a udržením kroku se scrumovými aktivitami bez výrazného rušení.

Proveďte uvolnění nasazení

Když jsou úspěšně dokončeny aktivity testování, opravy chyb a připravenosti kanálu, je to docela jednoduchý proces spustit produkční kanál a dokončit vydání do výroby.

Vzhledem k tomu, že je nasazen ze samostatné větve, může to být v podstatě nepozorovaná a neviditelná aktivita. Nikdo to nemusí vědět. Pokud tomu tak je, je to nejlepší možná implementace nasazení vydání.

Předpokladem pro to je vytvořit solidní automatizovaný kanál DevOps. Používá se nejen k nasazení do produkčního prostředí, ale také do všech ostatních prostředí nižší úrovně. To může zahrnovat vývoj, sandbox, test, zajištění kvality, výkonové prostředí atd. Nasazení všech řešení pro každé jednotlivé prostředí by mělo být jedním kliknutím.

Uvolnění by nemělo být bodem bolesti nebo stresem. Nebo noční můra, které se všichni bojí, a na ten den se celý týden připravují. Ne – místo toho, pokud si toho nikdo nevšimne, je to nejlepší známka úspěšného vydání.

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

Release Branch nyní obsahuje nějaký speciální obsah, který v běžné probíhající vývojové větvi neexistuje. Týká se všech oprav, které byly implementovány během testovacího období. Tento obsah je třeba začlenit zpět do vývojové větve, aby bylo zajištěno, že opravy tam zůstanou i po příštím vydání.

V tu chvíli slouží nejnovější Release Branch jako nouzový produkční kód připravený k opětovnému nasazení. Pokud je třeba krátce po produkčním nasazení vyřešit naléhavý problém s vysokou prioritou, může použít tuto větev. Je jednoduché vzít tento kód a implementovat opravu dovnitř. Toto je stále přesná kopie aktuálního produkčního kódu bez jakéhokoli nového nevydaného obsahu.

Nakonec, jakmile začne nové testovací období, předchozí větev vydání může být odstraněna a nahrazena novou. Nový je opět vytvořen jako kopie z aktuální vývojové větve.

Stanovte pravidelná vydání

A teď to máme 😀 – solidní proces pro blížící se vydání. Jediné, co chybí, je zavázat se k pravidelnému dodržování. V tomto případě po každém druhém sprintu.

Tím, že to budeme udržovat pravidelně, jsme vlastně připravili půdu pro to, aby bylo snazší toho dosáhnout, hlavně proto, že:

• Pokud je vydání po nepříliš dlouhé době, není tolik nového obsahu k instalaci do produkce. Přírůstek je malý a je považován za stabilní.
• Tolik nového obsahu nyní znamená ne příliš mnoho testovacích aktivit a vytváření testovacích případů. Méně komunikace, telefonátů a spolupráce se zúčastněnými stranami ohledně toho, co všechno je třeba znovu ověřit. Shodnou se také na tom, že od posledního vydání to není tak dlouho. Této akci se tedy přikládá menší význam.
• Tým si na tento cyklus zvykne; časem bude přirozenou součástí týmu.
• Jako vedlejší efekt se ve vývojových a testovacích prostředích často obnovují data. To je stejně potřeba pro každý nový testovací cyklus. Nebude to tedy jen další naplánovaná činnost. Spíše akci, která je již součástí zavedeného procesu. Tato změna perspektivy má velký vliv na atmosféru v týmu. To by jeden nevěřil.

Závěr

Tato kapitola uzavírá mé předchozí příspěvky na téma životního cyklu scrumu. Jde také o to, co se osvědčilo v reálném životě.

Týmy často začínají agilním způsobem a dělají mnoho věcí špatně. Pak se nakonec vyvinou a začnou dělat věci jinak. Tato série by mohla některým z nich pomoci provést tuto změnu rychleji.

Ani tento přístup k vydání není jediný funkční, ani není bezproblémový. Ty budou stále existovat a týmy se s nimi musí vypořádat. Pak vylepšete, co je možné, a zapomeňte na to, co nemá smysl.

Ale z toho, co vím, tento přístup, i když jednoduchý, dokázal, že změna je možná. Od chaotických, nepředvídatelných sprintů po stabilnější dodávky s pravidelnými verzemi, na které se lze spolehnout a plánovat je. A nevyžaduje speciální, vysoce komplikovanou metodiku – jen jednoduchá pravidla a ochotu dodržovat plán.