Vývoj softwaru v roce 2020 je rychle se měnící prostředí. Každým dnem je jasnější, že pokud chtějí naše organizace přežít toto období politické a ekonomické nejistoty, musí být schopny rychlého a přizpůsobivého pohybu. Jak ale řídit bezpečnost při rychlosti? Pokud je vaším cílem přejít od cyklu dodávek softwaru, který byl vytvořen s množstvím ochranných zábran a zřídkavým nasazováním, k modernější metodice, která podporuje rychlou odezvu prostřednictvím častých vydání, aby hodnota proudila k vašim zákazníkům co nejrychleji a nejbezpečněji, pak velmi záleží na tom, koho pověříte rozhodováním o řízení změn.

Tradičně v mnoha organizacích tato rozhodnutí přijímá centrálně manažer změn, který pořádá pravidelné schůzky poradního sboru pro změny (CAB). Samotný CAB je soubor zástupců z různých funkcí uvnitř i vně podnikového IT, pověřených přezkoumáváním navrhovaných změn a pomocí manažerovi změn při jejich posuzování, určování priorit a plánování. Z podstaty věci se jedná o skupinu, která se přímo nepodílí na návrhu nebo realizaci navrhované změny, a proto se proces, který provádí, nazývá „externí“ přezkum.

Ale kdo by měl být odpovědný? Abyste co nejlépe podpořili jak rychlost a bezpečnost, TAK obchodní dopad, chcete, aby rozhodování řídily vaše vývojové týmy a vaši zákazníci. Z technického hlediska mají vaši vývojáři lepší představu o tom, co je ve verzi, zda existují vzájemné závislosti a zda to bylo otestováno, než jakýkoli poradní sbor pro změny. Z obchodního hlediska je načase si uvědomit, že konečným arbitrem toho, co bude a nebude fungovat, je zákazník, ne nějaký vyšší manažer a už vůbec ne váš poradní sbor pro změny.

Poradní sbor pro změny je sice pomalejší, ale alespoň bezpečnější, ne?“

Poradní sbor pro změny (a mnohé z toho, co najdete v ITIL), se může zdát jako rozumný způsob, jak snížit riziko a zvýšit přísnost, zejména v pomalu se vyvíjejících a složitých prostředích. Pokud máte pouze jednu šanci každých 30 nebo 90 dní změnit produkci, vypadá udržování věcí mimo verze s branami kvality a schvalováním vedením jako dobrý způsob řízení rizika. Nikdo nebude diskutovat o tom, že je to pomalejší proces (který může prodloužit dobu mezi napsáním kódu vývojářem a jeho uvedením do ostrého provozu o týdny nebo měsíce), ale je to bezpečnější, ne?

Vlastně ne. Není.

Několikaletá studie napříč nejrůznějšími odvětvími a prostředími zjistila, že mít CAB nebo podobný „externí schvalovací“ proces dopadlo hůře než nemít žádný schvalovací proces. Zde je vyjádření hlavní autorky Dr. Nicole Fosgren k výsledkům:

Zjistili jsme, že externí schvalování negativně korelovalo s dobou přípravy, četností nasazení a dobou obnovy a nemělo žádnou korelaci s mírou neúspěšnosti změn. Stručně řečeno, schválení externím orgánem (například manažerem nebo CAB) jednoduše nefunguje pro zvýšení stability produkčních systémů, měřeno dobou do obnovení provozu a mírou selhání změn. Rozhodně však věci zpomaluje. Ve skutečnosti je to horší než nemít proces schvalování změn vůbec.

Co je lepší než vůbec žádné řízení změn?“

Doktorka Fosgrenová a její tým ve skutečnosti nenavrhují, abyste neměli žádný schvalovací proces, ale vzhledem k tomu, jak špatně fungují CAB v reálném světě, bychom se měli znovu zamyslet nad tím, jaký proces vám skutečně zajistí bezpečnost.

Tady je další citace ze studie Accelerate:

Naším doporučením na základě těchto výsledků je používat odlehčený proces schvalování změn založený na vzájemném hodnocení, například párovém programování nebo intrateamovém hodnocení kódu, v kombinaci s deployment pipeline pro odhalování a odmítání špatných změn. Tento proces lze použít pro všechny druhy změn, včetně změn kódu, infrastruktury a databáze.

Peer Code Reviews v kombinaci s What Now?“

Když jsem si toto doporučení v březnu 2018 přečetl, neměl jsem problém si představit první polovinu: peer code reviews a týdenní týmové ukázky už byly ve společnosti BlazeMeter normou. Druhá polovina? To už tolik ne! Byli jsme „moderní“ cloud-native SaaS aplikace, ale nikdy jsem neslyšel o tom, že „deployment pipeline detekuje a odmítá špatné změny“.

Pro řízení rizik při tehdejších verzích jsme používali kombinaci modrých/zelených nasazení a kanárkových verzí. Platforma dělala „tlačení“, ale ne „detekci“ nebo „odmítání“ – to bylo na našich nejlepších a nejchytřejších SRE, kteří ručně kontrolovali stav desítek věcí, než jsme zvýšili počet uživatelů na 100 %. Když jsem si přečetl „detekovat a odmítat špatné změny“, vyvolalo to jen obrázek černé krabičky na tabuli s nápisem „tady se dějí kouzla“. Vzpomínky na filmová studia na vysoké škole, kde jsem se učil, co znamená „deus ex machina“.

Detekovat a odmítnout: Příklady se najdou, když se podíváte

Za dva roky se toho může hodně změnit. Od chvíle, kdy jsem nastoupil do Splitu jako CD Evangelist, jsem sledoval Lukase Vermeera, jak popisuje, že nasazovací potrubí společnosti Booking.com dokáže odhalit a vrátit špatnou změnu během jediné sekundy. Poslouchal jsem Sonali Sheelovou ze společnosti Walmart Labs, která mi vysvětlovala, jak používají svou platformu Expo k zastavení zavádění v polovině, než dojde k poškození klíčových ukazatelů, čemuž říkají Test to Launch.

Platforma Split Feature Delivery Platform byla vytvořena lidmi s podobnou vizí moderního řízení změn na základě živých zkušeností ze společností LinkedIn, Salesforce.com a Yahoo. Zakladatelé dostali rady od lidí, kteří řešili složitost, rychlost a rozsah podobných systémů ve společnostech Amazon a Microsoft.

Když jsem se dozvěděl o společnosti Split a objevil příklady, které komerčně využívají, chopil jsem se příležitosti přidat se k nim. Vytvořit takovou platformu vlastními silami bylo něco, na co mělo čas a zdroje jen několik gigantů. Kdyby byl stejný druh jemné expozice a automatizované detekce dopadů dostupný jako SaaS, pak by se dodávání softwaru řízeného dopady mohlo odemknout pro každý tým, nejen pro startupy typu unicorn.

To je úžasné, ale tady to fungovat nebude

Když jsem cestoval po technologických konferencích a přednášel o prvních průkopnících, kteří tyto platformy vybudovali in house, stávala se mi stále dokola zvláštní věc. Publikum reagovalo nejprve s údivem a pak s rezignací. „To je docela fajn, ale my nejsme Booking.com, LinkedIn ,nebo Facebook. Tohle v našem prostředí nemůžeme dělat.“

Ve snaze být „vendor-neutral“ tím, že jsem se vyhýbal specifikům implementace Splitu, jsem prakticky překreslil onen mlhavý obrázek černé krabičky s nápisem „tady se dějí kouzla“.

Co kdyby to nebylo tak těžké?“

Pokud jste nikdy neviděli platformu, která poskytuje jemnou kontrolu expozice a přísný automatizovaný mechanismus pro detekci a odmítnutí špatných změn v prostředí, nemůžete se divit, že si myslíte, že je to sci-fi.

Ukazuje se, že je zde třeba vyřešit pouze čtyři hlavní problémy:

1. Oddělit nasazení od vydání, takže kód lze posunout až do produkce, ale zabránit jeho spuštění, dokud není připraven. To usnadňuje skutečnou kontinuální integraci, malé velikosti dávek, inkrementální vývoj funkcí a větvení pomocí abstrakce, což jsou všechno kritické faktory pro realizaci kontinuálního dodávání, kde je normou tok.
2. Selektivně vystavujte nový kód, přičemž začněte s malým interním publikem a postupujte směrem ven. To usnadňuje testování ve výrobě, dogfooding, programy předběžného přístupu a dávkování změn pro zákazníky, kteří jsou změnám nakloněni.
3. Přijímejte data o chování systému a uživatelů a slaďte je s daty o vystavení, která ukazují, kdo je v každé kohortě uživatelů a kdo ne. Cílem je, aby proces atribuce (sladění „Kdo co dostal?“, s „Pak se stalo toto“) byl automatický a kontinuální.
4. Porovnejte vzorce metrik mezi zařazenými a vyřazenými z každé kohorty, abyste identifikovali (a případně upozornili na) významné rozdíly. Možná jste se s tímto vzorem již setkali v souvislosti s „A/B testováním“, které obvykle sleduje dopad změn na konverzní metriku, ale zde mluvíme o širokém sledování dopadu veškeré inženýrské práce a o neustálém sledování dopadů na všechny metriky oceňované organizací, ať už je dopad na tyto metriky očekávaný, nebo ne.

Progresivní dodávka: Snadno zavedený základ

Oddělování nasazení od vydání a selektivní vystavování nového kódu se stává známé jako progresivní dodávání, což je termín, který vymyslel analytik společnosti RedMonk James Governor. Několik komerčních dodavatelů feature flagů poskytuje tyto funkce již v základní výbavě a objevuje se shoda, že feature flagy se zařadily na seznam vývojářských nástrojů, které má větší smysl kupovat než vytvářet a udržovat vlastními silami.

Feature flags jsou nezbytným základem pro dosažení flow, ale samy o sobě nezrychlují detekci dopadů. Většina implementací příznaků funkcí usnadňuje tok, ale nijak nenaznačuje, zda je vše v pořádku a zda dosahujete smysluplných výsledků.

Hlavně: Datoví vědci se neškálují

Zjišťování chování systému a uživatelů a jeho automatické sladění s vystavenými kohortami je mezi všemi kromě nejsofistikovanějších interních systémů vzácné. Většina týmů, které se o tento postup pokoušejí, vykonává spoustu manuální a ad-hoc práce v oblasti datové vědy. Protože jsou omezeny spíše lidskými zdroji než výpočetní kapacitou, jsou nuceny si vybírat, kdy a kde věnovat pozornost.

Kognitivní zátěž není při snaze o flow vaším přítelem, takže návrh Splitu ani nevyžaduje, aby si týmy vybíraly, které události přiřadí k jednotlivým rolloutům příznaků funkcí; všechny přijaté události, jednou navázané na organizační metriky, jsou průběžně přiřazovány k zapnutým a vypnutým kohortám každého rolloutu, a to bez jakéhokoli zásahu. Split také usnadňuje práci s identifikací a přijímáním dat o událostech díky integracím se službami Segment, Sentry, mParticle a Google Analytics.

Semper Fi pro Continuous Delivery Pipelines

Porovnávání vzorců metrik mezi zařazenými a nezařazenými v každé kohortě důsledným způsobem za účelem automatického určení významných rozdílů je v přírodě ještě vzácnější než atribuce. Právě tento problém řeší moduly Monitor a Experimentation společnosti Split. Monitor se zaměřuje na identifikaci a upozorňování na dopady na metriky v průběhu zavádění (známé také jako „omezení poloměru výbuchu incidentů“), zatímco Experimentation, podobně jako A/B testování, se snaží poskytovat nepřetržitý zdroj nezkreslených dat, který není omezen dostupností analytika a který ukazuje, zda každá funkce dosáhla požadovaného dopadu, či nikoli.

Lepší společně:

Proč usilujeme o flow? Nejde o výstupy. Jde o výstupy. Usilujeme o flow, abychom mohli opakovat smyčku zpětné vazby nápad -> realizace -> pozorování s menším třením v kratším čase. Ať už tomu říkáte „vývoj řízený dopadem“ nebo „vývoj řízený zákazníkem“, tento přístup k rychlejšímu postupu s větším (a rychlejším) povědomím o výsledcích jde daleko za „zaváděcí potrubí pro odhalování a odmítání špatných změn“, které nám tým DORA doporučil spojit s postupy vzájemného hodnocení. Ano, můžeme automaticky detekovat a odmítat špatné změny, ale co je důležitější, můžeme vytvořit opakovatelný proces pro triangulaci směrem ke smysluplným obchodním výsledkům.

Zjistěte více o společném dosažení řízení změn a toku v kontinuálním dodávání

• Podívejte se na čtyřminutové video o definici kontinuálního dodávání a zjistěte, proč je malá velikost dávky rozhodující pro dosažení konzistentního toku.
• Poslechněte si tipy od několika týmů, které denně dodávají do produkce, v e-knize společnosti O’Reilly Continuous Delivery in the Wild
• Podívejte se na podrobné video s Craigem Sebenikem (LinkedIn, Crunchbase, Matterport) o výhodách přechodu na vývoj založený na trunku.

Hledáte další skvělý obsah o dosahování smysluplných výsledků při dodávání funkcí v měřítku? Přidejte si blog Split do záložek, podívejte se na nás na YouTube nebo nás sledujte na Twitteru @splitsoftware.