Continuous Delivery: een snelle, flexibele en toch betrouwbare manier van softwareontwikkeling

Organisaties staan door opkomende technologieën, die hen meer en nieuwe mogelijkheden bieden, voor nieuwe uitdagingen. Door de crisis zijn bedrijven steeds voorzichtiger met hun uitgaven en nemen ze minder risico’s. Daarbij vragen klanten steeds meer van (online) dienstverlening en hierdoor ontstaan er kansen die organisaties niet moeten laten liggen. Organisaties die zich willen onderscheiden moeten zich dan ook richten op de dienstverlening en de nieuwe technologieën optimaal benutten. Continuous Delivery kan organisaties hierbij helpen. Maar hoe werkt het en hoe kun je ook de business de voordelen van deze ontwikkelmethode laten zien?

Wat is Continuous Delivery
Continuous Delivery zorgt kortgezegd voor het aanpakken van de gehele levenscyclus van software – van analyse, ontwerp en cyclisch opleveren naar test, deployment en feedback – in één end-to-end-werkwijze. De verantwoordelijkheid voor de hele levenscyclus wordt ondergebracht in gezamenlijke teams en het onderscheid tussen ontwikkelen en beheer vervaagt hierbij. Alle fasen van de levenscyclus worden verregaand geautomatiseerd met bewezen, standaard tooling die in de markt beschikbaar is. De invoering van Continuous Delivery zal uiteindelijk leiden tot het verbeteren van de kwaliteit van IT en het reduceren van de kosten die gemoeid zijn met IT.

VECOZO
Een organisatie die op dit moment bezig is met de overstap naar Continuous Delivery is VECOZO. VECOZO biedt een portaal waarin ketenpartijen in de zorg snel, veilig en eenvoudig gegevens met elkaar kunnen uitwisselen. De organisatie biedt een twintigtal verschillende diensten en heeft vijf ontwikkelteams die volgens de SCRUM-methodiek bezig zijn met de ontwikkeling van applicaties. In deze ‘oude’ situatie werkt VECOZO met een hele korte ontwikkelcyclus (sprint) om snel en agile op te kunnen leveren. Een aparte applicatiebeheerafdeling is verantwoordelijk voor de uitrol van applicaties naar de productieomgeving. Dit gebeurt één keer per maand, op een vast moment. Op dat moment gaat het systeem uit de lucht en worden updates en wijzigingen voor alle diensten doorgevoerd.

Voor de organisatie is dit geen ideale situatie, men wil van de downtime af. Niet alleen omdat het hele systeem dan plat ligt, maar eens per maand is een grote groep medewerkers tot ’s nachts bezig met de updates. VECOZO wil dit anders en is naar oplossingen gaan kijken.

Inrichting ontwikkelproces
Via de langdurige samenwerking die VECOZO al vanaf de start met Info Support heeft, heeft Info Support Continuous Delivery voorgesteld. Om over te kunnen stappen moet het deployment-proces anders ingericht worden. Een belangrijke eis hierbij is dat de organisatie dezelfde kwaliteit en beschikbaarheid moet kunnen blijven leveren als voorheen. Het testproces moet daarvoor geautomatiseerd worden. Dit is gedaan door SpecFlow in te zetten. Binnen de nieuwe ontwikkelomgeving wordt gebruik gemaakt van Continuous Deployment. Alle wijzigingen worden daarin geautomatiseerd uitgerold en de bijbehorende testen worden uitgevoerd. Eerder was de uitrol van nieuwe applicaties en functionaliteit met name gericht op het downtime-moment waarin alles in één keer werd uitgerold. Nu is VECOZO bezig om binnen het huidige proces de automatisering zo in te richten dat het per dienst kan gebeuren en dus in verschillende fases. Het uiteindelijke hoofddoel voor VECOZO is het volledig terugbrengen van de downtime. Dit gebeurt nu in verschillende stappen waarmee de werkwijze van de volledige ontwikkelafdeling wordt omgevormd naar de Continuous Delivery-methode.

Overstappen op Continuous Delivery
Niet alleen VECOZO is bezig met een overstap naar Continuous Delivery, veel andere organisaties zitten in ditzelfde proces. Onderstaande best practices kunnen organisaties helpen bij de overstap naar Continuous Delivery:

1. Verandering aan applicatiearchitectuur
   Het implementeren van een deliverypijplijn kan met bijna elke bestaande applicatie. Om tijdens deployment volledige beschikbaarheid te kunnen bieden, is het noodzakelijk ook te kijken naar de applicatiearchitectuur. Architectuurpatronen zoals Event-driven Architecture (EDA) en Command Query Responsibility Segregation (CQRS) kunnen helpen tijdens het ontwerp van applicaties om maximale beschikbaarheid (eenvoudiger) mogelijk te maken.

2. Communicatie met eindgebruikers
   In een oude situatie, zoals in het voorbeeld van VECOZO, worden wijzigingen uitgerold naar de testomgeving en kan de eindgebruiker zien wat het resultaat is en of dit aansluit bij de behoefte. Bij de overstap naar Continuous Delivery verandert dit. Het ontwikkelproces gaat continu door en wijzigingen worden direct uitgerold in productie. Er wordt dan in die fase pas bijgestuurd en/ of aangepast. Eventueel kan er wel gebruik worden gemaakt van zogenaamde ‘feature toggles’ om nieuwe functionaliteit nog tijdelijk niet zichtbaar te maken. Bij Continuous Delivery is wachten op de testomgeving dus niet nodig waardoor processen veel sneller zijn, bijsturen eenvoudiger is, en men niet afhankelijkheid is van planningen van de eindgebruikers. Dit betekent wel dat er anders met de eindgebruikers gecommuniceerd moet worden. Je kunt niet meer maandelijks een overzicht sturen met geüpdatete functionaliteit, er zijn namelijk continu veranderingen. Er moet nog bepaald worden hoe dit binnen het ketenproces van VECOZO inricht wordt, maar het is belangrijk deze communicatie niet uit het oog te verliezen.

3. Voordelen voor de business
   Voor IT is het eenvoudig om de toegevoegde waarde van Continuous Delivery aan de business te tonen. De organisatie wordt namelijk een stuk flexibeler als het gaat om aanpassingen in applicaties. Er is een veel snellere time-to-market. Wanneer je, zoals in de oude situatie bij VECOZO, werkt met een maandelijkse uitrol kan het soms bijna twee maanden duren voordat functionaliteit wordt doorgevoerd. Nu gebeurt dit direct en daardoor is de toegevoegde waarde snel aan te tonen.

Erik Steinebach, consultant bij Info Support en lead developer bij VECOZO

Share this