Softwareudvikling i 2020 er et miljø, der ændrer sig hurtigt. Det bliver mere og mere klart for hver dag, at hvis vores organisationer ønsker at overleve denne periode med politisk og økonomisk usikkerhed, skal de være i stand til at bevæge sig med hurtighed og tilpasningsevne. Men hvordan kontrollerer man sikkerhed ved hastighed? Hvis dit mål er at bevæge dig fra en softwareleveringscyklus, der er bygget op med masser af rækværk og sjældne udrulninger, til en mere moderne metodologi, der understøtter lydhørhed via hyppige udgivelser, så du kan levere værdi til dine kunder så hurtigt og sikkert som muligt, så er det meget vigtigt, hvem du sætter til at stå for beslutningerne om ændringsstyring.

Traditionelt i mange organisationer træffes disse beslutninger centralt af en ændringsleder, der afholder periodiske møder i et rådgivende rådgivende råd for ændringer (CAB). Selve CAB’et er en samling repræsentanter fra forskellige funktioner inden for og uden for virksomhedens IT, som har til opgave at gennemgå foreslåede ændringer og bistå ændringslederen med vurdering, prioritering og planlægning af ændringer. Det er en gruppe, der ikke er direkte involveret i udformningen eller implementeringen af den foreslåede ændring, hvilket er grunden til, at den proces, de udfører, er kendt som en “ekstern” gennemgang.

Men hvem skal have ansvaret? For bedst muligt at understøtte både hastighed og sikkerhed SAMT forretningseffekt ønsker du, at dine udviklingsteams og dine kunder skal styre din beslutningstagning. Ud fra et teknisk perspektiv har dine udviklere en bedre idé om, hvad der er i en udgivelse, om der er indbyrdes afhængigheder, og om det er blevet testet, end et hvilket som helst rådgivende ændringsudvalg. Set fra et forretningsperspektiv er det på tide, at vi indser, at kunden er den endelige dommer over, hvad der vil fungere og ikke vil fungere, ikke en eller anden senior manager og slet ikke dit rådgivende udvalg for ændringer.

Et Change Advisory Board er måske langsommere, men i det mindste er det mere sikkert, ikke sandt?

Det Change Advisory Board (og meget af det, du finder i ITIL), kan virke som fornuftige måder at reducere risikoen og tilføje stringens på, især i langsomt bevægende, komplekse miljøer. Hvis du kun har en chance hver 30. eller 90. dag for at ændre produktionen, ser det ud til at være en god måde at styre risikoen på, hvis du holder tingene ude af udgivelser med kvalitetsgates og ledelsesgodkendelser. Ingen vil diskutere, at det er en langsommere proces (som kan tilføje uger eller måneder til den tid, der går mellem det tidspunkt, hvor en udvikler skriver kode, og det går i luften), men det er mere sikkert, ikke?

Egentlig, nej. Det er det ikke.

En flerårig undersøgelse på tværs af en lang række forskellige brancher og miljøer viste, at det at have en CAB- eller lignende “ekstern godkendelsesproces” klarede sig dårligere end slet ikke at have nogen godkendelsesproces. Her er, hvad hovedforfatteren Dr. Nicole Fosgren havde at sige om resultaterne:

Vi fandt, at eksterne godkendelser var negativt korreleret med lead time, implementeringshyppighed og restore time, og at de ikke havde nogen korrelation med change fail rate. Kort sagt, godkendelse fra et eksternt organ (såsom en leder eller CAB) virker simpelthen ikke til at øge stabiliteten af produktionssystemer, målt ved tiden til at genoprette service og ændringsfejlraten. Men det gør bestemt tingene langsommere. Det er faktisk værre end slet ikke at have nogen godkendelsesproces for ændringer overhovedet.

Hvad er bedre end ingen ændringsstyring overhovedet?

Dr. Fosgren og hendes team foreslår faktisk ikke, at man ikke har nogen godkendelsesproces, men i betragtning af hvor dårligt CAB’er fungerer i den virkelige verden, bør vi genoverveje, hvilken slags proces der rent faktisk vil holde dig sikker.

Her er et andet citat fra Accelerate-undersøgelsen:

Vores anbefaling baseret på disse resultater er at bruge en letvægts ændringsgodkendelsesproces baseret på peer review, såsom parprogrammering eller intrateam-kodegennemgang, kombineret med en deployment pipeline til at opdage og afvise dårlige ændringer. Denne proces kan bruges til alle slags ændringer, herunder kode-, infrastruktur- og databaseændringer.

Peer-kodeanmeldelser kombineret med hvad nu?

Da jeg læste denne anbefaling i marts 2018, havde jeg ikke noget problem med at visualisere den første halvdel: peer-kodeanmeldelser og ugentlige teamdemoer var allerede normen hos BlazeMeter. Den anden halvdel? Ikke så meget! Vi var en “moderne” cloud-native SaaS-app, men jeg havde aldrig hørt om “en deployment pipeline detekterer og afviser dårlige ændringer”.

For at styre risikoen under udgivelser dengang brugte vi en kombination af blå/grønne implementeringer og canary-udgivelser. Platformen gjorde “pushing”, men ikke “detecting” eller “rejecting” – det var op til vores bedste og klogeste SRE’s, som ville kontrollere sundheden af snesevis af ting manuelt, før vi ramped op til 100% af brugerne. Når vi læste “detect and reject bad changes”, fik vi kun et billede af en sort boks på et whiteboard med påskriften “magic happens here”. Flashbacks til filmstudier på universitetet, hvor jeg lærte, hvad “deus ex machina” betød.

Detect and Reject: Eksempler findes derude, hvis du kigger

Meget kan ændre sig på to år. Siden jeg kom til Split som CD Evangelist, har jeg set Lukas Vermeer beskrive, hvordan Booking.com’s deployment pipeline kan opdage og tilbageføre en dårlig ændring i løbet af et enkelt sekund. Jeg har lyttet til Sonali Sheel fra Walmart Labs forklare, hvordan de bruger deres Expo-platform til at stoppe en udrulning midtvejs, før den gør skade på deres nøgletal, noget de kalder Test to Launch.

The Split Feature Delivery Platform blev skabt af folk med lignende visioner om moderne ændringsstyring baseret på levede erfaringer hos LinkedIn, Salesforce.com og Yahoo. Stifterne fik råd fra folk, der havde tacklet kompleksiteten, hastigheden og omfanget af lignende systemer hos Amazon og Microsoft.

Da jeg hørte om Split og opdagede de eksempler, som de var i gang med at kommercialisere, hoppede jeg på chancen for at slutte mig til dem. At opbygge en sådan platform internt var noget, som kun få giganter havde tid og ressourcer til at tage fat på. Hvis den samme form for finkornet eksponering og automatiseret påvirkningsdetektion var tilgængelig som SaaS, så kunne effektdrevet softwarelevering låses op for alle hold, ikke kun for enhjørninge-startups.

Det er fantastisk, men det vil ikke fungere her

En sjov ting skete igen og igen, da jeg rejste til teknologikonferencer og holdt foredrag om de tidlige pionerer, der havde bygget disse platforme in house. Publikum reagerede først med forbløffelse og derefter med resignation. “Det er ret sejt, men vi er ikke Booking.com, LinkedIn eller Facebook. Det kan vi ikke gøre i vores miljø.”

I mine bestræbelser på at være “leverandør-neutral” ved at undgå detaljerne i Splits implementering havde jeg praktisk talt gentegnet det uskarpe billede af en sort boks mærket “magi sker her”.

Hvis det ikke var så svært?

Hvis du aldrig har set en platform, der giver finkornet kontrol med eksponering og en streng automatiseret mekanisme til at opdage og afvise dårlige ændringer i dit miljø, kan du ikke bebrejdes for at tro, at det er science fiction.

Det viser sig, at der kun er fire hovedproblemer, der skal løses her:

1. Afkobl deploy fra release, så kode kan skubbes hele vejen til produktion, men forhindres i at blive udført, indtil den er klar. Dette letter ægte kontinuerlig integration, små batchstørrelser, inkrementel funktionsudvikling og forgrening ved abstraktion, som alle er afgørende for at gennemføre kontinuerlig levering, hvor flow er normen.
2. Udsæt den nye kode selektivt, start med små interne målgrupper og arbejd dig udad. Dette letter test i produktion, dogfooding, early access-programmer og batching af ændringer for kunder, der ikke ønsker ændringer.
3. Indhent system- og brugeradfærdsdata og afstem dem med eksponeringsdata, der angiver, hvem der er inde og ude af hver brugerkohorte. Målet er at gøre tildelingsprocessen (at afstemme “Hvem fik hvad?” med “Så skete dette”) automatisk og kontinuerlig.
4. Sammenlign mønstrene af målinger mellem dem, der er inkluderet og ekskluderet fra hver kohorte, for at identificere (og eventuelt advare om) væsentlige forskelle. Du har måske set dette mønster før i forbindelse med “A/B-testning”, som typisk sporer virkningen af ændringer på en konverteringsmetrik, men her taler vi om en bred sporing af virkningen af alt ingeniørarbejde og en konstant vagtsom overvågning af virkningerne på alle organisatorisk værdsatte metrikker, uanset om virkningen på disse metrikker er forventet eller ej.

Progressive Delivery: Et let etableret fundament

Decoupling deploy from release and selectively exposing new code are becoming known as progressive delivery, a term coined by RedMonk analyst James Governor. Flere kommercielle featureflag-leverandører tilbyder disse funktioner uden videre, og der er ved at opstå enighed om, at featureflag er kommet med på listen over udviklerværktøjer, som det giver mere mening at købe end at bygge og vedligeholde internt.

Feature flags er et vigtigt fundament for at opnå flow, men i sig selv fremskynder de ikke opdagelsen af påvirkninger. De fleste implementeringer af featureflag gør det lettere at flowe, men gør intet for at indikere, om alt er godt, eller om du opnår meningsfulde resultater.

Head’s Up: Data Scientists Don’t Scale

Indkredsning af system- og brugeradfærd og automatisk tilpasning af den til de udsatte kohorter er sjælden blandt alle undtagen de mest sofistikerede in-house-systemer. De fleste teams, der forsøger sig med denne praksis, udfører en masse manuelt og ad hoc-datavidenskabeligt arbejde. Da de er begrænset af menneskelige ressourcer snarere end af computerkapacitet, er de tvunget til at vælge og vrage, hvornår og hvor de skal være opmærksomme.

Kognitiv belastning er ikke din ven, når du sigter mod flow, så Splits design kræver ikke engang, at teams skal vælge, hvilke begivenheder der skal knyttes til hver udrulning af funktionsflag; alle indlagte begivenheder, når de først er bundet til organisatoriske målinger, tilskrives løbende til de til- og frakoblede kohorter for hver udrulning, uden nogen indgriben. Split letter også arbejdet med at identificere og indlæse hændelsesdata gennem integrationer med Segment, Sentry, mParticle og Google Analytics.

Semper Fi for Continuous Delivery Pipelines

Sammenligning af mønstre af metrikker mellem dem, der er inkluderet og ikke inkluderet i hver kohorte, på en stringent måde for automatisk at bestemme signifikante forskelle er endnu mere sjælden i naturen end tilskrivning. Dette er præcis det problem, som Splits Monitor- og Eksperimentationsmoduler løser. Monitor fokuserer på at identificere og advare om påvirkninger af målinger, mens en udrulning er i gang (også kendt som “begrænsning af hændelsernes eksplosionsradius”), mens Experimentation, ligesom A/B-testning, søger at tilvejebringe en kontinuerlig kilde til uvildige data, der ikke er begrænset af en analytikers tilgængelighed, for at angive, om hver funktion opnåede en ønsket virkning eller ej.

Bedre sammen: Peer Review, Progressive Delivery og Automatiseret Sense-Making

Hvorfor stræber vi efter flow? Det handler ikke om output. Det handler om resultater. Vi stræber efter flow, så vi kan gentage feedbackløbet af idé -> implementering -> observation med mindre friktion på kortere tid. Uanset om man kalder det “effektdrevet udvikling” eller “kundedrevet udvikling”, går denne tilgang til at bevæge sig hurtigere med større (og hurtigere) bevidsthed om resultater langt videre end den “implementeringsrørledning til at opdage og afvise dårlige ændringer”, som DORA-holdet anbefalede, at vi kombinerer med peer review-praksis. Ja, vi kan automatisk opdage og afvise dårlige ændringer, men endnu vigtigere er det, at vi kan opbygge en gentagelig proces til at triangulere mod meningsfulde forretningsresultater.

Lær mere om at opnå ændringsstyring og flow sammen i Continuous Delivery

• Se en fire minutters video om definitionen af Continuous Delivery for at se, hvorfor en lille batchstørrelse er afgørende for at opnå et ensartet flow.
• Saml tips fra flere teams, der dagligt sender til produktion, i O’Reilly e-bog, Continuous Delivery in the Wild
• Se en dybdegående video med Craig Sebenik (LinkedIn, Crunchbase, Matterport) om fordelene ved at gå over til trunk-baseret udvikling.

Søger du efter mere godt indhold om at opnå meningsfulde resultater med feature delivery i stor skala? Bogmærk Split-bloggen, tjek os ud på YouTube, eller følg os på Twitter @splitsoftware.