Softwareontwikkeling anno 2020 is een snel veranderende omgeving. Het wordt met de dag duidelijker dat als onze organisaties deze periode van politieke en economische onzekerheid willen overleven, ze in staat moeten zijn om snel en adaptief te bewegen. Maar hoe controleert u de veiligheid op snelheid? Als het je doel is om van een software delivery cyclus die is gebouwd met veel vangrails en infrequente deploys, naar een meer moderne methodologie die responsiviteit ondersteunt via frequente releases om waarde te leveren aan uw klanten zo snel en veilig mogelijk, dan wie je de leiding geeft over change management beslissingen maakt veel uit.

Traditioneel in veel organisaties, worden deze beslissingen centraal genomen door een change manager die periodiek change advisory board (CAB) vergaderingen houdt. De CAB zelf is een verzameling vertegenwoordigers van verschillende functies binnen en buiten de IT van het bedrijf, die zijn gecharterd met het beoordelen van voorgestelde wijzigingen en het assisteren van de change manager bij het beoordelen, prioriteren en plannen van wijzigingen. Het is de bedoeling dat deze groep niet direct betrokken is bij het ontwerpen of implementeren van de voorgestelde verandering, en daarom staat het proces dat zij uitvoeren bekend als een “externe” beoordeling.

Maar, wie moet de leiding hebben? Om zowel snelheid en veiligheid als business impact zo goed mogelijk te ondersteunen, wilt u dat uw ontwikkelteams en uw klanten uw besluitvorming aansturen. Vanuit een technisch perspectief hebben uw ontwikkelaars een beter idee van wat er in een release zit, of er onderlinge afhankelijkheden zijn, en of het getest is, dan welke change advisory board dan ook. Vanuit een zakelijk perspectief, is het tijd dat we ons realiseren dat de klant de uiteindelijke arbiter is van wat wel en niet werkt, niet een of andere senior manager, en zeker niet je adviesraad voor veranderingen.

Een Change Advisory Board is misschien trager, maar in ieder geval veiliger, toch?

De Change Advisory Board (en veel van wat u in ITIL vindt), lijkt misschien een redelijke manier om risico’s te verminderen en strengheid toe te voegen, vooral in traag bewegende, complexe omgevingen. Als u maar één kans per 30 of 90 dagen hebt om de productie te veranderen, lijkt het een goede manier om risico’s te beheersen om dingen buiten releases te houden met kwaliteitspoorten en goedkeuringen van het management. Niemand zal betwisten dat het een trager proces is (dat weken of maanden kan toevoegen aan de tijd tussen het schrijven van code door een ontwikkelaar en de livegang), maar het is veiliger, toch?

Eigenlijk niet, nee. Dat is het niet.

Een meerjarige studie over een breed scala van industrieën en omgevingen toonde aan dat het hebben van een CAB of een vergelijkbaar “extern goedkeuringsproces” slechter presteerde dan het hebben van helemaal geen goedkeuringsproces. Dit is wat hoofdauteur Dr. Nicole Fosgren over de resultaten te zeggen had:

We ontdekten dat externe goedkeuringen een negatieve correlatie vertoonden met doorlooptijd, uitrolfrequentie en hersteltijd, en geen correlatie vertoonden met het percentage mislukte wijzigingen. Kortom, goedkeuring door een externe instantie (zoals een manager of CAB) leidt niet tot een grotere stabiliteit van productiesystemen, gemeten aan de hand van de tijd die nodig is om de service te herstellen en het aantal mislukte wijzigingen. Het vertraagt de zaken echter zeker. Het is in feite erger dan helemaal geen goedkeuringsproces voor wijzigingen hebben.

Wat is er beter dan helemaal geen wijzigingsbeheer?

Dr. Fosgren en haar team stellen niet echt voor om geen goedkeuringsproces te hebben, maar gezien de slechte prestaties van CAB’s in de echte wereld, zouden we ons moeten afvragen welk soort proces u eigenlijk veilig zal houden.

Hier volgt nog een citaat uit het Accelerate-onderzoek:

Onze aanbeveling op basis van deze resultaten is om een lichtgewicht goedkeuringsproces voor wijzigingen te gebruiken dat is gebaseerd op peer review, zoals pair programming of intrateam code review, in combinatie met een implementatiepijplijn om slechte wijzigingen te detecteren en af te wijzen. Dit proces kan worden gebruikt voor alle soorten wijzigingen, waaronder code-, infrastructuur- en databasewijzigingen.

Peer Code Reviews Gecombineerd met What Now?

Toen ik die aanbeveling in maart van 2018 las, had ik geen moeite om de eerste helft te visualiseren: peer code reviews en wekelijkse teamdemo’s waren al de normen bij BlazeMeter. De tweede helft? Niet zo veel! We waren een “moderne” cloud-native SaaS-app, maar ik had nog nooit gehoord van “een deployment pipeline detecteert en verwerpt slechte wijzigingen.”

Om de risico’s tijdens releases toen te beheren, gebruikten we een combinatie van blue/green deployments en canary releases. Het platform deed het “pushen”, maar niet het “detecteren” of “afwijzen” – dat was aan onze beste en slimste SRE’s, die de gezondheid van tientallen dingen handmatig controleerden voordat we opliepen naar 100% van de gebruikers. Lezen van “detect and reject bad changes” bracht alleen een plaatje van een zwarte doos op een whiteboard met het label, “magic happens here.” Flashbacks naar film studies op de universiteit, waar ik leerde wat “deus ex machina” betekende.

Detect and Reject: Voorbeelden zijn er als je kijkt.

Er kan veel veranderen in twee jaar. Sinds ik bij Split ben begonnen als CD Evangelist, heb ik Lukas Vermeer zien beschrijven hoe Booking.com’s deployment pipeline een slechte verandering binnen een seconde kan detecteren en terugdraaien. Ik heb geluisterd naar Sonali Sheel van Walmart Labs die uitlegde hoe zij hun Expo platform gebruiken om een uitrol halverwege te stoppen voordat het schade toebrengt aan hun belangrijkste statistieken, iets wat zij Test to Launch noemen.

Het Split Feature Delivery Platform is gecreëerd door mensen met vergelijkbare visies op modern change management gebaseerd op doorleefde ervaringen bij LinkedIn, Salesforce.com en Yahoo. De oprichters kregen advies van mensen die de complexiteit, snelheid en schaal van soortgelijke systemen bij Amazon en Microsoft hadden aangepakt.

Toen ik over Split hoorde en de voorbeelden ontdekte die ze commercialiseerden, greep ik de kans met beide handen aan om mee te doen. Het bouwen van zo’n platform in eigen huis was iets waar maar een paar giganten de tijd en de middelen voor hadden. Als dezelfde soort fijnkorrelige blootstelling en geautomatiseerde impactdetectie beschikbaar zou zijn als SaaS, dan zou impactgedreven software delivery voor elk team ontsloten kunnen worden, niet alleen voor de unicorn startups.

Dat is verbazingwekkend, maar het zal hier niet werken

Er gebeurde steeds weer iets grappigs toen ik naar tech-conferenties reisde en lezingen gaf over de vroege pioniers die deze platforms in eigen huis hadden gebouwd. Het publiek reageerde eerst met verbazing en dan met berusting. “Dat is best cool, maar wij zijn Booking.com, LinkedIn of Facebook niet. We kunnen dat niet doen in onze omgeving.”

In mijn pogingen om “vendor-neutral” te zijn door de specifieke kenmerken van Split’s implementatie te vermijden, had ik dat vage beeld van een zwarte doos met de tekst “magic happens here” praktisch opnieuw getekend.

Wat als het niet zo moeilijk was?

Als je nog nooit een platform hebt gezien dat fijnkorrelige controle van blootstelling biedt en een rigoureus geautomatiseerd mechanisme voor het detecteren en afwijzen van slechte veranderingen in je omgeving, kan het je niet kwalijk worden genomen dat je denkt dat het science fiction is.

Het blijkt dat er slechts vier hoofdproblemen zijn om op te lossen:

1. Ontkoppel deploy van release, zodat code helemaal naar productie kan worden gepushed maar pas kan worden uitgevoerd als het klaar is. Dit vergemakkelijkt echte continue integratie, kleine batch-groottes, incrementele feature ontwikkeling, en vertakking door abstractie, die allemaal van cruciaal belang zijn voor het trekken van continue levering waar flow is de norm.
2. Selectief blootstellen van de nieuwe code, te beginnen met kleine interne doelgroepen en werken naar buiten. Dit vergemakkelijkt het testen in de productie, dogfooding, early access programma’s, en batching van wijzigingen voor verandering-mijdende klanten.
3. Ingest systeem en gedrag van gebruikers gegevens en lijn het met de blootstelling gegevens die aangeven wie er in en uit elke gebruiker cohort. Het doel is om het attributieproces (afstemming van “Wie kreeg wat?”, met “Toen gebeurde dit”) automatisch en continu.
4. Vergelijk de patronen van metrieken tussen degenen die zijn opgenomen en uitgesloten van elk cohort te identificeren (en optioneel waarschuwen voor) significante verschillen. U kunt dit patroon eerder hebben gezien in de context van “A/B testen” die typisch de impact van veranderingen op een conversie metriek volgt, maar hier hebben we het over het in het algemeen volgen van de impact van al het engineering werk en het hebben van een voortdurend waakzaam oog voor effecten op alle organisatorisch gewaardeerde metrieken, of de impact op die metrieken wordt verwacht of niet.

Progressive Delivery: An Easily Established Foundation

Het loskoppelen van deploy en release en het selectief blootstellen van nieuwe code worden bekend als progressive delivery, een term bedacht door RedMonk-analist James Governor. Meerdere commerciële leveranciers van feature flags bieden deze mogelijkheden out of the box en er is consensus aan het ontstaan dat feature flags zijn toegetreden tot de lijst van ontwikkelaarstools die het zinvoller maken om ze te kopen dan om ze zelf te bouwen en te onderhouden.

Feature flags zijn een essentieel fundament voor het bereiken van flow, maar op zichzelf versnellen ze niet de detectie van impact. De meeste implementaties van feature flags maken het eenvoudiger om te flowen, maar geven niet aan of alles goed gaat en of u zinvolle resultaten bereikt.

Head’s Up: Data Scientists Don’t Scale

Het in kaart brengen van systeem- en gebruikersgedrag en dit automatisch afstemmen op de blootgestelde cohorten is zeldzaam onder alle, behalve de meest geavanceerde, in-house systemen. De meeste teams die dit proberen, doen veel handmatig en ad-hoc datawetenschappelijk werk. Omdat ze worden beperkt door personele middelen in plaats van computercapaciteit, zijn ze gedwongen om te kiezen wanneer en waar ze aandacht besteden.

Cognitieve belasting is niet je vriend als je streeft naar flow, dus het ontwerp van Split vereist niet eens dat teams kiezen welke events ze associëren met elke feature flag rollout; alle ingested events, eenmaal gekoppeld aan organisatorische metrieken, worden continu toegewezen aan de aan en uit cohorten van elke rollout, zonder enige interventie. Split vereenvoudigt ook het werk van het identificeren en opnemen van event data door integraties met Segment, Sentry, mParticle, en Google Analytics.

Semper Fi for Continuous Delivery Pipelines

Het vergelijken van patronen van metrics tussen degenen die wel en niet zijn opgenomen in elk cohort op een rigoureuze manier om automatisch significante verschillen vast te stellen, is in het wild nog zeldzamer dan attributie. Dit is precies het probleem dat Split’s Monitor en Experimentatie modules oplossen. Monitor richt zich op het identificeren van en waarschuwen voor impacts op metrieken tijdens een uitrol (ook bekend als “het beperken van de straal van incidenten”), terwijl Experimentation, net als A/B-testen, probeert een continue bron van onbevooroordeelde gegevens te bieden, niet beperkt door de beschikbaarheid van een analist, om aan te geven of elke functie een gewenste impact heeft bereikt of niet.

Beter Samen: Peer Review, Progressive Delivery en Automated Sense-Making

Waarom streven we naar flow? Het gaat niet om output. Het gaat om de resultaten. We streven naar flow zodat we de feedbackloop van idee -> implementatie -> observatie kunnen itereren met minder frictie in minder tijd. Of je het nu “impact-gedreven ontwikkeling” of “klant-gedreven ontwikkeling” noemt, deze aanpak om sneller te gaan met een groter (en sneller) bewustzijn van de resultaten gaat veel verder dan de “ontplooiingspijplijn om slechte veranderingen op te sporen en af te wijzen” die het DORA-team ons aanraadde te combineren met peer review praktijken. Ja, we kunnen automatisch slechte wijzigingen detecteren en verwerpen, maar nog belangrijker is dat we een herhaalbaar proces kunnen bouwen voor triangulatie naar zinvolle bedrijfsresultaten.

Lees meer over het bereiken van Change Management en Flow, samen, in Continuous Delivery

• Bekijk een vier minuten durende video over de definitie van Continuous Delivery om te zien waarom een kleine batchgrootte van cruciaal belang is voor het bereiken van consistente flow.
• Vang tips op van meerdere teams die dagelijks naar productie verschepen in het e-book van O’Reilly, Continuous Delivery in the Wild
• Bekijk een diepgaande video met Craig Sebenik (LinkedIn, Crunchbase, Matterport) over de voordelen van het overstappen op trunk-gebaseerde ontwikkeling.

Op zoek naar meer geweldige content over het bereiken van zinvolle resultaten met feature delivery op schaal? Bookmark de Split blog, bekijk ons op YouTube, of volg ons op Twitter @splitsoftware.