0 comments
Continuous Delivery 
Deze bijdrage is geleverd door Wim van Gool en Rogier Schrama
Dag 4 en 5 van de SATURN conferentie. Een dag sessies en keynotes, gevolg door een dag tutorials.
DevOps ervaringen
Onder de onderwerpen ook weer de prominente usual suspects ‘DevOps en continuous delivery’, vooral in de vorm van ervaringsverhalen. De verzameling best practices die vorm geeft aan DevOps is nu een aantal jaren bekend onder het grotere publiek en langzamerhand beginnen organisaties te rapporteren over hun ervaringen. Wat werkt wel en wat niet en binnen welke context. Het lijkt erop dat de winst bij het gebruik van DevOps evenredig is aan de omvang van de software engineering werkzaamheden die door een organisatie worden uitgevoerd. De DevOps manier van werken vereist een significante verzameling tooling en ‘infrastructuur’ die in veel gevallen door eigen ontwikkelaars moet worden gebouwd en opgezet. Deze inspanning is gemakkelijker te verantwoorden wanneer het in verhouding staat tot de omvang van de software die erdoor geproduceerd wordt. Of als je als organisatie een schijnbaar oneindig budget hebt (Google, Netflix, etc.)
DevOps Aanpak Netflix
De eerste keynote van Netflix director of engineering Dianne Marsh, geeft inzicht in hoe Netflix een en ander aanpakt. Binnen Netflix is een complete software ontwikkel afdeling enkel bezig met het ontwikkelen va tools die de overige ontwikkelaars ondersteunen bij zaken als auto deployment en geautomatiseerd testen. Het ‘tools’ team is erop gericht om de tools zo gebruikersvriendelijk mogelijk te maken, zodat de benodigde kennis om ze te gebruiken zo klein mogelijk kan blijven. Deze tools worden gebruikt door de overige ontwikkelaars die verder een vrijwel totale autonomie hebben in welke functionaliteit ze opleveren, met welke technologie ze dat doen en wanneer ze opleveren. Voorwaarde is wel dat de ontwikkelteams ook na in productiename verantwoordelijk blijven voor het monitoren van hun software. Ook Netflix gebruikt overigens micro services, een concept dat sterk verbonden is met continuous delivery.
Om ontwikkelaars scherp te houden, onderhoudt het ‘tools’ team ook de ‘Simian Army’, bestaande uit de latency, chaos, janitor en conformity monkeys. Dit is een verzameling applicaties die productiesoftware lastig valt door services in productie bewust de nek om te draaien en latency te veroorzaken. Daarnaast wordt van services runtime getoetst of ze voldoen aan kwaliteitseisen en is er de janitor die achtergebleven rommel in productie opruimt.
De belangrijkste boodschappen zijn ook hier weer de betrokkenheid van Ops richting Dev en omgekeerd. Ops bouwt tooling die Dev ondersteunt, en Dev is verantwoordelijk voor de opgeleverde software tot en met productie, gebruik makend van deze tools. Door de schaalgrootte kan Netflix zich processen met deze grootte veroorloven, maar de principes zijn ook toepasbaar op projecten en organisaties met een kleinere omvang. Daarnaast is alle door Netflix gemaakte tooling in de vorm van open source beschikbaar, wat mogelijk een grote initiële investering voorkomt.
Introduceren van DevOps
De overige sessies met betrekking tot DevOps behandelden onder andere de uitdaging van het introduceren van DevOps in de organisatie. Het advies is om te beginnen met een DevOps maturity model, toegespitst op de organisatie en een roadmap om de daarin gedefinieerde mijlpalen ook daadwerkelijk te gebruiken. Belangrijk hierbij is dat de voortgang te meten is, om de organisatie te kunnen laten zien wat de resultaten zijn.
Tegengaan van Technical Debt
Een paneldiscussie over technical debt gaf interessante inzichten in het verschijnsel dat in veel gevallen als een moeilijk te kwantificeren ‘gevoel’ leeft bij leden van een software ontwikkelteam. Bestaat het eigenlijk wel? Hoe meet je het? Wat doe je eraan? Een lijstje met de highlights van de opgeworpen stellingen:
- Je kunt eigenlijk alleen de zaken rondom technical debt meten (niet de technical debt zelf), zoals bijvoorbeeld een toename van de tijd die nodig is om bepaalde wijzigingen door te voeren.
- Als het aanpakken van technical debt binnen de organisatie moeilijk te verkopen is, geef het dan een andere naam (suggestie: architectural awesomeness).
- Technical debt is subjectief en sterk afhankelijk van context.
- Methodes om technical debt te voorkomen, zijn: discipline, een ‘culture of caring’, pair programming en architectural hoisting (zie dag 2).
- Technical debt kan niet op een exacte wijze bepaald worden. Dit vereist altijd menselijke redenering.
Tutorial ‘Iteration Planning’
Zoals de naam al weggeeft richtte deze 4 uur durende tutorial zich hoofdzakelijk op het zo efficient en effectief mogelijk plannen van werk in iteraties. Hiermee wordt bedoeld dat je in je planning niet alleen realistisch moet zijn, maar dat je tevens zowel de korte als lange termijn doelstellingen van een project in de gaten moet houden en die zo goed mogelijk in balans moet zien te houden.
Om hier een goed idee van te krijgen werd een spelletje voorgesteld waarbij we als groep in vier teams van 3 a 4 personen per team werden ingedeeld. Hierbij moest ieder team een planning van 8 iteraties vullen met taken (user stories). Van tevoren kregen we een soort startvelocity mee (het geschatte aantal uren/punten dat het team in één iteratie zou kunnen halen), om dan na iedere sprint onze daadwerkelijke velocity te meten op basis van dobbelstenen (=geluksfactor), opgebouwde technical debt en gebouwde hulpmiddelen (zoals test frameworks). Op basis van deze werkelijk gemeten velocity mochten we vervolgens werk/items wegstrepen, wat punten opleverde.
De missie was tweeledig: enerzijds moesten er na een bepaalde sprint simpelweg bepaalde features gerealiseerd zijn (anders waren we ‘dood’), en anderzijds moesten we na iteratie 8 zoveel mogelijk (permanente) features hebben gebouwd. Het team dat iteratie 8 succesvol afrondde met de meeste features won uiteindelijk.
Tijdens en na dit spel werden een aantal dingen snel duidelijk die ook in het gemiddelde software project gelden:
- Baseer iedere iteratie-planning op de laatste daadwerkelijk gemeten snelheid. Plan iteraties nooit weken vantevoren allemaal al in. Daarmee wordt je planning realistischer, kun je makkelijker bijsturen en krijg je veel meer belangrijk werk gedaan, omdat er minder onverwacht overboord valt.
- Als je ervoor kiest om te investeren in hulpmiddelen die je helpen om de kwaliteit van de software of de snelheid van het team te verhogen (test frameworks, DevOps), doe dat dan zo vroeg mogelijk. Logisch, want dan is je return-on-investment het hoogst.
- Kies alleen voor de makkelijke, snelle oplossing wanneer je echt geen andere keus hebt vanwege korte termijn doelstellingen, maar beter is het om te zorgen dat je al de high priorities zo vroeg mogelijk afrond zodat je later in het project veel flexibiler bent in het plannen van items. De kans dat je dan gedwongen wordt om short-cuts te nemen (= werk dat je later weer weggooit) is dat het kleinst.
- Als je dan toch een keer voor de makkelijke/simpele oplossing kiest, noteer dat dan expliciet als Technical Debt en maak de ‘interest’ die je moet betalen om de zaak later om te bouwen expliciet, zodat ook de business en management ziet wat die keuzes eigenlijk kosten op de lange termijn.
- Bugs/defects zijn onvermijdelijk, maar zorg er altijd voor dat de hoeveelheid bugs onder een bepaald niveau blijft. Fixes uitstellen, hoe klein ook, heeft een negatieve impact op de productiviteit van een team. Volledige iteraties gedwongen wijden aan bug-fixing is een red flag.
- Verdeel je backlog in vier type items:
- Features (gewenste, zichtbare functionaliteit) – groen,
- Invisible Features (gewenste, onzichtbare functionaliteit) – geel,
- Defects (ongewenste zichTbare functionaliteit) – rood,
- Technical Debt (ongewenste, onzichtbare functionaliteit) – zwart
Meestal wordt bij planningssessies alleen gekeken naar de effort die nodig is om alle zichtbare functionaliteit te realiseren (zoals echte features en bugfixes). Daarmee wordt voorbij gegaan aan de (vaak broodnodige) tijd die wordt gestoken in de onzichtbare zaken zoals refactoring (invisible feature) en het verbeteren van de architectuur of upgraden van tools en frameworks (fixen van technical debt). Door ook deze zaken inzichtelijk te maken en mee te plannen worden planningen een stuk realistischer en voorspelbaarder.
Conclusie
Twee dagen zonder paradigma verschuivingen, maar wel met meer concrete informatie over methoden en ‘concerns’ die momenteel sterk leven binnen het domein van de software architectuur.