Development

Software-ontwikkeling
Programmeren

Binnen 90 dagen Continuous Delivery

Een aanpak die continuous delivery wel werkend krijgt, binnen 90 dagen.

© Shutterstock
14 april 2017

Een aanpak die continuous delivery wel werkend krijgt, binnen 90 dagen.

Continuous delivery is het automatiseren van alle handmatige acties rond testen, integratie en deployment van software. Vooral bij agile werken is het noodzakelijk. Maar men start vaak te laat of verzandt in discussies over tools. En dat is zonde, want er bestaat een aanpak die continuous delivery binnen negentig dagen werkend krijgt.

Agile werken gaat uit van iteratief ontwikkelen. De meeste organisaties werken tegenwoordig met iteraties van twee weken of minder.

Hierdoor wordt software steeds vaker live gezet. Dit vraagt om verregaande automatisering van unittesten, acceptatietesten, regressietesten, integratie- en deploymentprocessen. Al deze automatisering vat men in de praktijk samen onder de noemer: continuous delivery (CD). In de praktijk blijft CD nogal onderbelicht. Veel organisaties kijken er tegenop en zien het als een enorm project. En dat klopt ook wel. Het invoeren van CD en het wegwerken van alle achterstanden op geautomatiseerd testen, is geen sinecure. Maar uiteindelijk is er feitelijk geen keuze. De veelheid aan releases onder agile werken maken het onmogelijk om alles handmatig te doen. En niet testen is veel te risicovol.

Ondanks de enorme berg werk, heeft uitstellen geen zin

Vandaar ook dat de meeste organisaties die agile werken hebben opgepakt, als vervolgstap vol insteken op continuous delivery. Maar dan volgt de volgende hobbel: trajecten voor CD verzanden namelijk snel in langdradige beslissingsprocessen over tools en technologie. En iedere maand dat die keuze loopt en de beslissing wordt uitgesteld, schuift het implementeren van CD zelf ook weer op. Voor men het weet zijn er weer drie maanden verstreken met het doen van proof-of-concepts en het vergelijken van tools. En al dit uitstel is doodzonde. Het stelt de oplossing van het probleem namelijk alleen maar uit.

Alternatieven

Er zijn echter alternatieven om dit te voorkomen en zij hebben zich in de praktijk bewezen. De essentie is: dat CD implementeren complex is en dus ook op een agile manier het beste slaagt. De bestaande teams gaan stap voor stap de achterstand op CD voor hun eigen applicaties wegwerken. Hierdoor kunnen snel meters worden gemaakt en worden ook direct de resultaten in de teams zelf geplukt. En dat bespaart weer tijd om de volgende stap te zetten. Dat lijkt voor de hand te liggen, maar toch zien we in de praktijk dat de meeste agile organisaties de fout maken om continuous delivery via een grote waterval en big bang te willen implementeren. En het verleden heeft ons geleerd dat dat meestal mislukt. De belangrijkste les is daarom: CD implementeren slaagt het best via iteraties.

De aanpak die werkt, bevat drie fasen:

1. Assessment

In het assessment worden de huidige werkwijze en aanwezige skills in kaart gebracht. Minstens zo belangrijk is een technische assessment van de applicatie. Is CD wel de eerstvolgende stap? Of moet eerst de applicatie ontvlochten worden om haar testbaarder of eenvoudiger deploybaar te maken?

2. Blueprint implementeren

Een blueprint voor een continuous delivery-infrastructuur wordt gebruikt om de CD-pipeline voor de applicaties in te richten. Dat is de voorbereiding, zodat de teams zelf hun testen kunnen automatiseren en hun applicaties geautomatiseerd kunnen deployen.

3. Teams lanceren

Met behulp van training, coaching en ‘direct beginnen’ worden de teams uitgerust met alle kennis en vaardigheden om zelf stap voor stap alles te automatiseren.

Drie maanden

De praktijk laat zien dat het lukt om met behulp van deze aanpak doelgericht en binnen drie maanden alle teams op het niveau te krijgen waarbij zij zelf CD in hun iteraties meenemen. Zodoende wordt door henzelf stap voor stap gewerkt aan het inhalen van de achterstanden op geautomatiseerd testen, integreren en deployen. Als teams daar zelf verantwoordelijkheid pakken, ligt de focus vooral op: direct effect. Teams richten zich namelijk op het automatiseren van die stappen waar zij zelf meteen iets van merken: doordat het ze tijd bespaart, het saai werk bij hen wegneemt of doordat het hen helpt de kwaliteit snel te verhogen.

Spendeer geen eeuwigheid aan toolselecties

Kortom, aan continuous delivery is niet te ontkomen wanneer organisaties agile gaan werken. Ondanks de enorme berg werk, heeft uitstellen weinig zin. Eerder starten is veel effectiever. Het is verstandig een agile aanpak te hanteren waarmee stap voor stap wordt gewerkt aan het ‘wegautomatiseren’ van kleine stukken werk. De praktijk laat zien dat binnen negentig dagen teams in staat zijn hier zelfstandig aan te werken. ‘Gewoon doen’ is daarom een simpele maar wel de allerbeste aanbeveling.

Continuous delivery in de praktijk: zes tips

1. Selecteer tools snel en start gelijk

Goede tools zijn belangrijk maar uiteindelijk zijn het de teams die het verschil maken. Spendeer daarom geen eeuwigheid aan toolselecties. Toolselecties hebben de neiging erg te focussen op kosten of op feature-compleetheid om op alle mogelijke verrassingen voorbereid te zijn. Een grote valkuil is te blijven zoeken naar de ‘ideale’ tools. Als ze al bestaan en als ze dan uiteindelijk zijn gevonden, dan blijkt dat ze onderling weer niet goed integreren. De ideale wereld bestaat niet, dus streef die ook niet na. Gebruik een standaardset die veel in de markt toegepast wordt en ga daarmee aan de gang.

2. Vorm een beeld van het totale werk

Voer eerst een assessment uit om te voorkomen dat er verrassingen gedurende het traject optreden. Zonder intake-assessment lijkt alles op voorhand mogelijk en het goed te doen, maar tijdens de implementatie komen de spreekwoordelijke lijken uit de kast. Een goede assessment geeft inzicht of CD de volgende stap is of dat er wellicht eerst andere zaken aangepakt moeten worden: is de applicatie sowieso eigenlijk wel geschikt om met testautomatisering te beginnen? Of kan een grote monolithische applicatie beter eerst opgeknipt worden voor deze automatisch te deployen?

3. Kijk verder dan deployment automation

Veel organisaties maken daarnaast de fout om een erg beperkte kijk op CD te hebben. Ze zien CD puur en alleen als deployment automation en verder niets. Feitelijk willen ze bestaande handmatige installatiehandelingen van beheerders automatiseren, maar daar houdt het voor hen in eerste instantie mee op. Echter, het gaat uiteindelijk niet om het deployen alleen. Het gaat erom dat het hele systeem werkt en blijft werken. Daardoor is CD veel breder en horen integraties, automatisch testen, resilienceprocessen en configureren er ook bij.

4. Automatiseer een verbeterde werkwijze

Probeer niet letterlijk het huidige proces te automatiseren. Het huidige proces is vaak handmatig en bovendien ooit gemaakt voor een lang-cyclische manier van werken. Probeer de zaken effectiever en efficiënter op te pakken. CD helpt daarbij doordat vereenvoudigingen ook makkelijker en sneller te automatiseren zijn. Zodoende blijkt dat een gestructureerde uitrol van continuous delivery enorm helpt bij het versimpelen en versnellen van het huidige IT-landschap.

5. Zorg voor experts om de teams verder te helpen

Niets is zo frustrerend voor een team als weten wat het doel is, maar niet zien hoe er te moeten komen. Wanneer een team dagen vastzit op hetzelfde probleem, kost dit veel energie en kan dit de CD-implementatie zelfs in gevaar brengen. Het is essentieel dat op dat moment iemand beschikbaar is die het team direct verder kan helpen. Een dergelijke probleemsituatie kan dan juist energie en motivatie geven omdat het team ziet dat ook deze zaken opgelost kunnen worden. Daarvoor hebben ze wel toegang tot expertise nodig.

6. Losse stappen, elk met directe waarde

Probeer niet alle problemen tegelijk op te lossen. Ja, ‘automate everything’, maar alleen alles wat er al is. Veel organisaties gaan bij de implementatie van CD voor de ‘Full Monty’. Alles wat ze voorheen nog niet deden voordat een applicatie in productie werd geïnstalleerd, willen ze nu volledig geautomatiseerd uitvoeren. Denk bijvoorbeeld aan zaken als Infrastructure as Code, dynamische on-demand provisioning van omgevingen, automatisering van acceptatietesten die voorheen nog niet eens bestonden. Niet doen dus. Begin klein en bouw daar op voort. Hoe eet je een olifant? Inderdaad: hapje voor hapje.

Zie ook Development op AG Connect Intelligence
7
Reacties
jak 22 april 2017 13:14

@Atilla. Er is een uitstekende log van Rik Maes http://agconnect.nl/blog/het-amsterdams-negenvlak Vanuit het verleden (2014) vind ik ook van hem dat de kloof tussen de ICT specialist en vak specialist niet bestaat.
Met een Generic Enterprise Architecture kun je prima een generieke richting aangeven daarover zijn we het eens, je hebt het uitstekend verwoord.
De vragen of het Agile top-down of andere veranderingsproces methodiek moet zijn raakt een wezenlijk iets. Je noemde het GEA als draagvlak en gaat dan over naar de keus van een specifiek procesrol aanpak, waarom?

De GEA zelf is een top-down aanpak. Het beschrijft het te bereiken doel
De mag niet in details machtsblokken en micromanagement verzanden.
De engineering build design is een bottom-up gebeuren. Je zet stappen om iets te bereiken.
Het wonderlijke is dat je soms stappen moet doen die niet in lijn lijken met de GEA.
Als de directe weg geblokkeerd is kun je er linksom om rechtsom (staan haaks op elkaar) omheen werken. Een stap terug om eerst wat anders af te breken/mogelijk te maken om sneller naar het doel te komen is ook mogelijk. Dat soort keuzes zijn heel normaal als je je in de fysieke wereld verplaatst. In de cyberwereld een bron van conflicten.

In een Agile aanpak laat je volgens mij al die deelstappen van de bottom-up gewoon zien. Dan kan je in de top-down nog op tijd een en ander bijstellen. Dat de kronkelende stappen niet gewaardeerd worden leidt tot een gebrek in tijdige en juiste terugkoppeling.
In de klassieke delivery als big-bang oplevering heb je maar een één moment van terugkoppeling de oplevering als je dat tenminste haalt op afgesproken moment met invulling van alle afgesproken eisen.

Die big-bang oplevering heeft vaak de annotatie van waterval (één enkele hoge) gekregen. Een waterval in veel kleine stapjes met rustpunten is makkelijker te overwinnen, uiteindelijk een gezapige stroom. (continous).
Ik zie al die tegenstellingen niet wel de culturele uitdagingen.

Atilla Vigh 16 april 2017 16:58

@JAK,

Dank voor je zeer uitgebreide toelichting. Ik probeer te begrijpen wat je zegt.
Het 9-vlaksmodel van Meas zit bij mij heel dicht tegen Enterprise Architectuur aan (en dan bedoel ik dus niet TOGAF of DYA, maar eerder GEA). De vertaalslag van een bedrijfsvraagstuk (waar elke wijziging in welke organisatie dan ook ten grondslag aan ligt) wordt op zijn zachts gezegd nauwelijks in geen enkele methodiek beschreven. Het 9-vlaks model, maar ook 7S model van McKinskey (en horden anderen) beschrijven alleen de mogelijke wijzigingen in een vaak voorgedefinieerd speelveld. Er is geen processturing. Daar wordt dan bij navraag een beroep gedaan op de kwaliteiten van de architect of business consultant die er toevallig bij betrokken is. Uiteindelijk zou het zo moeten zijn dat de core architectuur principes van alle relevante domeinen van een willekeurige organisatie een directe relatie moeten hebben met de missie, visie en doelstellingen van die organisatie. Door het bedrijfsvraagstuk te confronteren met die architectuur principes ontstaan ruimten en beperkingen. Zonder heel diep in te gaan op de GEA-methodiek, volgen een of meer oplossingsalternatieven, waaruit de organisatie er een moet kiezen. Die ga je dan verder uitwerken.

Dan kom je ook bij het domein ICT (want naast ICT heb je ook Finance, HR, primaire bedrijfsprocessen, logistiek, etc...) De randvoorwaarden van het project voor ICT volgen uit de architectuurfase en de bestaande architectuurprincipes eerder opgedaan bij voorgaande antwoorden op bedrijfsvraagstukken. De keuze voor Agile of top-down (middels SDM of welke willekeurige andere methode) komen daar uit voort. Er zijn nu eenmaal organisaties die een Agile ontwikkelmethodiek (met containers en alle tools die daarbij komen kijken) nastreven. De daarbij behorende tools staan in vergelijking met de oude ontwikkelstraat nog in de kinderschoenen, maar je hebt ze wel nodig. In beide situaties moet je alle zaken doen die gedaan moeten worden. Beiden manieren van werken hebben voor- en nadelen. Dan rijst de vraag bij mij nu: wanneer gebruik je Agile en wanneer traditioneel Top-Down? Welke aspecten zijn daarbij van invloed?

jak 15 april 2017 14:29

@Atilla, Laten we dan eerst eens naar de gangbare problemen kijken. Een PM PL met Prince SDM ITIL en meer en de fasering in OTAP met functiescheiding conform ITIL waar de changes en advisory boards eens per 2 weken aan de orde zijn. Dan mag je ook het 9 vlaks model van R.Maes er bij nemen waarbij de organisatie in vele kampen opgesplitst wordt.
-
Met ITIL is er de conventie dat elke verandering een bedreiging voor de continuïteit is en zeer nauwletttend (micromanagement) gecontroleerd moet worden. Dat geld ook voor de meest eenvoudige acties die juist voor de continuïteit nodig zijn zoals het tijdig bijwerken van certificaten en autorisaties.
Je ziet her meteen een hoofprobleem, micromanagement op zaken die gewoon nodig zijn om uit te voeren.
Maak je mee dat er weken overheen gaan met tientallen hogere managers in allerlei overleggen voor iets van een activiteit van een paar minuten met indien goed doordacht en getest weinig risico/impact heeft.
Wat dit versterkt is het machtsspel van managers en architecten waardoor zaken al of niet door mogen gaan.
Dit is een cultuur probleem geen technisch iets.
-
In een klassieke waterval aanpak kun je uitstekend uit de voeten je hebt standaard de OTAP voor je code en voor je data. (let op dat zijn er al twee). Dat is een scheiding voor de businessrules bedrijfstoepassing.
De hardcore techneuten hebben hun eigen OTAP voor de tools OS en hardware. Je ziet te vaak dat die twee door elkaar gehaald worden. Zelfs de jongens van de tools zijn in onmin met die van het OS. Deze hardcore wordt te vaak leidend gemaakt waarbij de bedrijfstoepassing vergeten wordt.
De laatste met een OTAP is de nieuwe tak "big data" ofwel de omgeving waarbij de data de rol van code inneemt. Die OTAP past niet in de twee bovenstaande informatiestromen. De reden is dat het ontwikkelen altijd met productiegegevens MOET plaatsvinden. Iets wat bij die andere dimensies van OTAP niet voorkomt.
...
Containers modern? Vergeet dat maar. In de Hierboven genoemde OTAP kun je met parallel ontwikkelen (onderhouds, emergency, meerdere projecten) uitstekend gescheiden ontwikkelstraten hebben met daarbij parallel testen in vele smaken. Zet er wat security op tussen de gebieden en je hebt het prachtig gescheiden.
Dit deden we 25 jaar terug als inrichting om een en ander snel te kunnen laten verlopen.
Een emergency-fix, indien nodig binnen een uur met daarbij alles getest. Een complete systeemacceptatietest, binnen een weekend met de big bang overgang van machine OS en tools als migratietraject.
Een projectvernieuwing, het tempo wat de PL aankan (de mens). Verkeerde beslissingen, foute inschattingen resultaten foute inschattingen mogelijkheden acties/resultaat als belangrijkste issues.
--
Het onderscheid backend/frontend maakt niet veel verschil. Dan zoek je het verschil in wat de business direct zichtbaar ziet als resultaat en wat er gebeuren moet om iets naar de front-end te krijgen wat je nu wegzet als backend dus niet relevant. De servicebus de koppelvlakken zijn nu vaak de wezenlijkste zaken om iets voor elkaar te krijgen zonder gegevens (de data) kan je met een front-end niets. Zie de front-end maar als het mooie koetswerk en de back-end als de motor en andere techniek.

allerbeste aan… 15 april 2017 10:34

Oplossing zonder probleemanalyse. Guru inhuren omdat je het zelf niet kunt. Die begint met "90 dagen" roepen en eindigt met "hapje voor hapje" fluisteren. Gewoon doen... Niets nieuws onder de zon.

Atilla Vigh 15 april 2017 08:31

@JAK
Zoals ik het ervaar heeft continuous delivery een heel ander uitgangspunt als filosofie. Als je een omgeving hebt ingericht die NIET agile is en alle aspecten van een gedegen ontwikkelstraat aan boord hebt (dus testen, integratie en deployment en nog een belangrijke documentatie) zal je dat vermoedelijk ook reeds geautomatiseerd hebben. Het gaat er om dat de ontwikkelaars niet de hele dag bezig zijn de administratie, configuratie en instellingen van de verschillende aspecten. Bovendien kan je met tools zaken afdwingen (ff niet testen is geen optie!). De automatisering in een NIET agile omgeving is anders dan in een agile omgeving.
In een continuous development omgeving kunnen er zo maar 10 verschillende versies met micro verschillen uit staan en wel life. Dat komt omdat in dit soort ontwikkelomgevingen met containers wordt gewerkt en op een veel kleiner detailniveau wordt gewerkt. Dan heb je andere tools nodig.
Ik ben op dit moment (anno 2017) van mening dat je niet voor alle software ontwikkeling continuous development hoeft in te richten, al was het alleen maar, omdat heel veel traditionele software (en dat is nog steeds het overgrote deel dat in gebruik is) op traditionele wijze wordt aangepast. Ik gok zo (dat weet ik niet zeker, wie kan daar wel iets zinnigs over roepen?) dat de scheidslijn tussen front-end en back-end ligt wat betreft het type ontwikkelmethode.

jak 14 april 2017 16:44

Ik mis de probleemanalyse waarvoor CD nu een oplossing moet bieden.
Nu gaat het de kant op van schaf de tools aan doe mee met de rest maar vraag niet waarom. Die houding is een probleemveroorzaker op zich. Genoemd is iteratief ontwikkelen is dat de nieuwe term voor trial en error iets in elkaar timmeren?

Atilla Vigh 14 april 2017 12:55

Zoals ik het nu lees, moet je eigenlijk om continuous delivery in te richten in je organisatie, de zaak zelf ook continuous inrichten. Na die 90 dagen die het artikel suggereert ben je constant bezig om te optimaliseren en natuurlijk de nieuwste inzichten toe te passen. Zodoende heeft de ICT een tweede laag boven de daadwerkelijke ontwikkeling van toepassingen verzonnen, die zelf ook in ontwikkeling is. Een mooie ontwikkeling, maar ook een lastige qua trouble shooting.

Reactie toevoegen