Mjukvaruutveckling 2020 är en miljö som förändras snabbt. Det blir allt tydligare för varje dag som går att våra organisationer måste kunna röra sig med snabbhet och anpassningsförmåga om de vill överleva denna period av politisk och ekonomisk osäkerhet. Men hur kontrollerar man säkerhet vid hög hastighet? Om ditt mål är att gå från en programvaruleveranscykel som byggdes med många skyddsräcken och sällsynta driftsättningar till en modernare metodik som stöder reaktionsförmåga via frekventa driftsättningar för att flödet av värde till dina kunder ska bli så snabbt och säkert som möjligt, då spelar det stor roll vem du låter ansvara för besluten om förändringshantering.

Traditionellt sett fattas dessa beslut i många organisationer centralt av en förändringsledare som håller regelbundna möten med rådgivande nämnden för förändringsfrågor (Change Advisory Board, CAB). CAB i sig är en samling representanter från olika funktioner inom och utanför företagets IT, som har till uppgift att granska föreslagna förändringar och hjälpa förändringsledaren med bedömning, prioritering och schemaläggning av förändringar. Det är en grupp som inte är direkt involverad i utformningen eller genomförandet av den föreslagna ändringen, vilket är anledningen till att den process som de genomför kallas för en ”extern” granskning.

Men vem ska vara ansvarig? För att på bästa sätt stödja både snabbhet och säkerhet SAMT affärseffekter vill du att dina utvecklingsteam och dina kunder ska styra ditt beslutsfattande. Ur ett tekniskt perspektiv har dina utvecklare en bättre uppfattning om vad som ingår i en utgåva, om det finns ömsesidiga beroenden och om det har testats, än någon rådgivande nämnd för ändringar. Ur ett affärsperspektiv är det dags att vi inser att det är kunden som avgör vad som kommer att fungera och vad som inte kommer att fungera, inte någon högre chef och absolut inte din rådgivande kommitté för förändringar.

En rådgivande nämnd för förändringar är kanske långsammare, men åtminstone säkrare, eller hur?

Den rådgivande nämnden för förändringar (och mycket av det som finns i ITIL) kan tyckas vara ett rimligt sätt att minska riskerna och lägga till stringens, särskilt i långsamma, komplexa miljöer. Om du bara har en chans var 30:e eller 90:e dag att ändra produktionen, ser det ut som ett bra sätt att hantera riskerna att hålla saker utanför releaser med kvalitetsgrindar och ledningsgodkännanden. Ingen skulle ifrågasätta att det är en långsammare process (som kan lägga till veckor eller månader till tiden mellan det att en utvecklare skriver kod och att den tas i drift), men det är säkrare, eller hur?

Faktiskt sett, nej. Det är det inte.

En flerårig studie över en mängd olika branscher och miljöer visade att det fungerade sämre att ha en CAB- eller liknande ”extern godkännandeprocess” än att inte ha någon godkännandeprocess alls. Här är vad huvudförfattaren Dr. Nicole Fosgren hade att säga om resultaten:

Vi fann att externa godkännanden var negativt korrelerade med ledtid, driftsättningsfrekvens och återställningstid, och att de inte hade någon korrelation med förändringsfrekvensen. Kort sagt, godkännande av ett externt organ (t.ex. en chef eller CAB) fungerar helt enkelt inte för att öka stabiliteten i produktionssystem, mätt med tiden för att återställa tjänsten och förändringsfelfrekvensen. Men det gör verkligen saker och ting långsammare. Det är faktiskt värre än att inte ha någon process för godkännande av ändringar alls.

Vad är bättre än ingen förändringshantering alls?

Dr Fosgren och hennes team föreslår faktiskt inte att man inte ska ha någon godkännandeprocess, men med tanke på hur dåligt CAB:s fungerar i verkligheten bör vi ompröva vilken typ av process som faktiskt håller dig säker.

Här är ett annat citat från Accelerate-studien:

Vår rekommendation baserad på dessa resultat är att använda en lättviktig process för godkännande av ändringar som bygger på kollegial granskning, t.ex. parprogrammering eller intrateam-kodgranskning, i kombination med en pipeline för utplacering för att upptäcka och avvisa dåliga ändringar. Denna process kan användas för alla typer av ändringar, inklusive kod-, infrastruktur- och databasändringar.

Peer Code Reviews Combined with What Now?

När jag läste den rekommendationen i mars 2018 hade jag inga problem att visualisera den första halvan: peer code reviews och veckovisa teamdemonstrationer var redan normen på BlazeMeter. Den andra halvan? Inte så mycket! Vi var en ”modern” moln-nativ SaaS-app, men jag hade aldrig hört talas om ”en deployment pipeline detect and reject bad changes”.

För att hantera risker under releaser på den tiden använde vi en kombination av blå/gröna driftsättningar och kanarieframställningar. Plattformen gjorde ”pushing” men inte ”detecting” eller ”rejecting” – det var upp till våra bästa och smartaste SRE:s, som kontrollerade hälsan hos dussintals saker manuellt innan vi ökade upp till 100 % av användarna. När vi läste ”detect and reject bad changes” fick vi bara upp en bild av en svart låda på en whiteboard med texten ”magic happens here” (magi händer här). Återblickar till filmstudier i college, där jag lärde mig vad ”deus ex machina” betydde.

Detektera och avvisa: Det finns exempel om man tittar

Mycket kan förändras på två år. Sedan jag började på Split som CD Evangelist har jag sett Lukas Vermeer beskriva hur Booking.coms pipeline för driftsättning kan upptäcka och återkalla en dålig ändring inom en enda sekund. Jag har lyssnat på Sonali Sheel från Walmart Labs som förklarar hur de använder sin Expo-plattform för att stoppa en lansering halvvägs innan den skadar deras nyckeltal, något som de kallar Test to Launch.

Split Feature Delivery Platform skapades av personer med liknande visioner om modern förändringshantering baserat på erfarenheter från LinkedIn, Salesforce.com och Yahoo. Grundarna fick råd av personer som hade hanterat komplexiteten, hastigheten och skalan hos liknande system på Amazon och Microsoft.

När jag hörde talas om Split och upptäckte de exempel som de kommersialiserade hoppade jag på chansen att ansluta mig till dem. Att bygga en sådan plattform internt var något som endast ett fåtal jättar hade tid och resurser att ta itu med. Om samma typ av finkornig exponering och automatiserad konsekvensdetektering fanns tillgänglig som SaaS, skulle konsekvensdriven programvaruleverans kunna låsas upp för alla team, inte bara för unicorn-startups.

Det är fantastiskt, men det kommer inte att fungera här

En rolig sak hände om och om igen när jag reste till teknikkonferenser, och höll föredrag om de tidiga pionjärerna som hade byggt upp dessa plattformar internt. Publiken reagerade först med förvåning och sedan med uppgivenhet. ”Det är ganska häftigt, men vi är inte Booking.com, LinkedIn eller Facebook. Vi kan inte göra det i vår miljö.”

I mina ansträngningar att vara ”leverantörsneutral” genom att undvika detaljerna i Splits implementering hade jag praktiskt taget ritat om den luddiga bilden av en svart låda märkt ”magi händer här”.

Tänk om det inte var så svårt?

Om du aldrig har sett en plattform som ger finkornig kontroll av exponering och en rigorös automatiserad mekanism för att upptäcka och avvisa dåliga förändringar i din miljö, kan du inte klandras för att du tror att det är science fiction.

Det visar sig att det bara finns fyra huvudproblem att lösa här:

1. Frånkoppla deploy från release, så att kod kan skjutas hela vägen till produktion men hindras från att exekveras tills den är klar. Detta underlättar sann kontinuerlig integration, små batchstorlekar, inkrementell funktionsutveckling och förgrening genom abstraktion, som alla är kritiska för att få till stånd kontinuerlig leverans där flödet är normen.
2. Exponera den nya koden på ett selektivt sätt, börja med små interna målgrupper och arbeta dig utåt. Detta underlättar testning i produktion, dogfooding, program för tidig åtkomst och batching av ändringar för kunder som inte vill ändra sig.
3. Införskaffa data om system- och användarbeteende och anpassa dem till exponeringsdata som visar vem som går in och ut ur varje användarkohort. Målet är att göra tilldelningsprocessen (att anpassa ”Vem fick vad?” till ”Då hände detta”) automatisk och kontinuerlig.
4. Jämför mönstren av mätvärden mellan de som ingår och de som utesluts från varje kohort för att identifiera (och eventuellt varna för) signifikanta skillnader. Du kanske har sett det här mönstret tidigare i samband med ”A/B-testning” som vanligtvis spårar effekten av förändringar på ett konverteringsmått, men här talar vi om att i stort sett spåra effekten av allt ingenjörsarbete och att ha en ständig vaksamhet för att se om det finns en effekt på alla organisatoriskt värdefulla mått, oavsett om den är förväntad eller inte.

Progressive Delivery: En lätt etablerad grund

Frånkoppling av driftsättning från utgivning och selektivt exponering av ny kod börjar kallas progressiv leverans, en term som myntades av RedMonk-analytikern James Governor. Flera kommersiella leverantörer av funktionsflaggor tillhandahåller dessa funktioner utan vidare, och det börjar bli konsensus om att funktionsflaggor har anslutit sig till listan över verktyg för utvecklare som är mer förnuftiga att köpa än att bygga och underhålla internt.

Feature flags är en viktig grund för att uppnå flöde, men i sig själva påskyndar de inte upptäckten av påverkan. De flesta implementeringar av funktionsflaggor gör det lättare att flöda, men gör ingenting för att indikera om allt är bra eller om du uppnår meningsfulla resultat.

Head’s Up: Data Scientists Don’t Scale

Att förstå system- och användarbeteende och att automatiskt anpassa det till de utsatta kohorterna är sällsynt bland alla utom de mest sofistikerade interna systemen. De flesta team som försöker sig på detta gör en hel del manuellt och ad hoc-datavetenskapligt arbete. Eftersom de begränsas av mänskliga resurser snarare än datorkapacitet tvingas de välja när och var de ska ägna uppmärksamhet.

Kognitiv belastning är inte din vän när du siktar på flöde, så Splits utformning kräver inte ens att teamen väljer vilka händelser som ska associeras med varje utbyggnad av funktionsflaggor; alla inlästa händelser, när de väl är knutna till organisatoriska mätvärden, tillskrivs kontinuerligt kohorterna on och off för varje utbyggnad, utan att någon åtgärd vidtas. Split underlättar också arbetet med att identifiera och ta in händelsedata genom integrationer med Segment, Sentry, mParticle och Google Analytics.

Semper Fi for Continuous Delivery Pipelines

Att jämföra mönster av mätvärden mellan de som ingår och de som inte ingår i varje kohort på ett rigoröst sätt för att automatiskt fastställa signifikanta skillnader är ännu mer sällsynt i det vilda än attribution. Detta är exakt det problem som Splits moduler Monitor och Experimentation löser. Monitor fokuserar på att identifiera och varna för påverkan på mätvärden när en lansering pågår (även känt som att ”begränsa incidenternas sprängningsradie”), medan Experimentation, liksom A/B-testning, syftar till att tillhandahålla en kontinuerlig källa av opartiska data, som inte begränsas av en analytikers tillgänglighet, för att ange om varje funktion uppnådde önskad påverkan eller inte.

Bättre tillsammans: Peer Review, Progressive Delivery and Automated Sense-Making

Varför strävar vi efter flöde? Det handlar inte om produktion. Det handlar om resultat. Vi strävar efter flöde så att vi kan iterera återkopplingsslingan idé -> genomförande -> observation med mindre friktion på kortare tid. Oavsett om man kallar det ”effektdriven utveckling” eller ”kunddriven utveckling” går detta tillvägagångssätt för att gå snabbare framåt med större (och snabbare) medvetenhet om resultaten långt utöver den ”pipeline för att upptäcka och förkasta dåliga ändringar” som DORA-teamet rekommenderade att vi skulle kombinera med metoder för expertgranskning. Ja, vi kan automatiskt upptäcka och avvisa dåliga ändringar, men ännu viktigare är att vi kan bygga en upprepningsbar process för triangulering mot meningsfulla affärsresultat.

Lär dig mer om att uppnå förändringshantering och flöde, tillsammans, i Continuous Delivery

• Klipp på en fyra minuter lång video om definitionen av Continuous Delivery för att se varför en liten satsstorlek är avgörande för att uppnå ett konsekvent flöde.
• Hämta tips från flera team som dagligen levererar till produktion i O’Reillys e-bok, Continuous Delivery in the Wild
• Se en djupgående video med Craig Sebenik (LinkedIn, Crunchbase, Matterport) om fördelarna med att gå över till stambaserad utveckling.

Söker du mer bra innehåll om hur du uppnår meningsfulla resultat med funktionsleverans i skala? Lägg Split-bloggen som bokmärke, kolla in oss på YouTube eller följ oss på Twitter @splitsoftware.