Van Continuous Delivery naar Continuous Deployment

Een van onze vaste klanten is Prime Vision, het bedrijf dat o.a. voor Post NL de software maakt waarmee de post wordt gesorteerd. Geheel volgens de Agile principes, maakt het bedrijf software die na elke sprint in productie kan worden gezet. Nieuwe features, wijzigingen in de configuratie, bugs en/of problem fixing, binnen drie weken worden de wijzigingen gemaakt, getest en goedgekeurd. Klaar om zo naar productie te gaan.

Scripts en opleveringen: een haat-liefde relatie

Om de software veilig uit te kunnen rollen, hebben we het opleveringsproces grotendeels geautomatiseerd. Tot voor kort werkten we daarbij met uitgebreide installatiescript die vanaf afstand op de servers werden gedraaid. Met zo’n script worden alle stappen die moeten worden uitgevoerd bij elke nieuwe versie één voor één doorlopen. Helaas bleek die methode een aantal vervelende bijwerkingen te hebben. Het maken van een installatiescript is een saaie, vervelende klus. Het kost elke keer weer ontzettend veel tijd en moeite om een werkend script te maken dat doet wat het moet doen. Daarom is het bijna niet te doen om elke drie weken een nieuwe versie van de software in productie te zetten. Maar ook als dat lukt, is er geen garantie op een succesvolle uitrol.

Verschillen hou je toch

Hoewel de verschillende servers in principe allemaal op dezelfde manier zijn geconfigureerd, zijn er in de praktijk toch verschillen. De lokale beheerders brengen soms wijzigingen aan die centraal niet bekend zijn (bv proces wijkt af, machine is stuk ed). Het installatiescript overschrijft deze lokale wijzigingen. Dit leidt vaak tot bugs in productie die voor het ontwikkelteam moeilijk te tracen en op te lossen zijn. Niet alleen Prime Vision heeft met dit probleem te maken. Doordat veel applicaties nu in de cloud staan, moeten beheerders vaak veel meer servers onderhouden en is het overzicht vaak zoek. Vandaar dat er een oplossing is gekomen om dit probleem op te lossen.

Dat kan beter!

In plaats van een script waarmee je de applicatie helemaal opnieuw installeert, maak je een beschrijving van hoe het systeem eruit moet zien. Er zijn twee manieren om de installatie te doen: automatisch of handmatig. In het eerste geval overschrijft de tool de software automatisch als het een afwijking ziet. In het tweede geval controleert de software alleen wat de verschillen zijn ten opzichte van die beschrijving. De beheerder geeft vervolgens aan welke van de getoonde afwijkingen moeten worden overschreven met de juiste code.

De praktijk bij Prime Vision

Er zijn een aantal tools die op deze manier werken. De bekendste zijn Puppet, Saltstack en Ansible. Prime Vision koos uiteindelijk voor de laatste, omdat die het meest recht-toe-recht-aan is. Er zitten weinig toeters en bellen aan en is relatief eenvoudig te gebruiken. Tot nog toe zijn we erg tevreden met Ansible. De tool is pas een paar jaar op de markt en zeker nog voor verbetering vatbaar, maar toch hebben we er al veel voordeel van. We zijn veel minder tijd kwijt met het uitrollen van nieuwe versies naar productie en lopen ook minder risico. Je hebt veel meer controle over het proces. In het geval van bugs kun je meteen zien wat afwijkt van de gewenste situatie. Dit scheelt iedereen veel tijd!

De cirkel rond

De nieuwe werkwijze is meer dan een handige techniek. Het sluit helemaal aan bij het DevOps principe omdat het de verschillende disciplines in de softwareontwikkeling dichter bij elkaar brengt. Van software integration tot delivery en deployment. Alle processen lopen steeds meer in elkaar over. Daardoor kan het DevOps team nog meer kwaliteit leveren in minder tijd. Een prima ontwikkeling dus!

 

Blijf op de hoogte

Schrijf je in voor de nieuwsbrief en ontvang eens per maand een overzicht van de laatste artikelen.