In de eerste 2 delen van deze blogserie (een introductie en Visual Studio Team Services) hebben we al gezien dat Continuous Delivery een belangrijk aspect is van DevOps. Continuous Delivery wordt dan ook vaak gezien als de eerste stap op weg naar DevOps. Om misverstanden te voorkomen… Continuous Delivery betekent niet dat iedere aanpassing in de source code ook direct en geautomatiseerd in productie terecht komt. Het gaat er bij Continuous Delivery om dat de software gedurende de levenscyclus altijd deploybaar is. Met andere woorden, het delivery proces dient op ieder willekeurig moment, eenvoudig en zonder grote risico’s uitgevoerd te kunnen worden!

Bepaalde onderdelen in dit blog zijn inmiddels enigzins verouderd. Via de button onderaan deze pagina kunt u een volledig geactualiseerde versie van de blogserie downloaden.

Continuous Delivery, stap voor stap

Continuous Delivery richten we niet in één dag in voor onze organisatie. Voordat we dat bereikt hebben, zullen we een aantal stappen moeten doorlopen. Sommige van deze stappen zijn al behoorlijk ingeburgerd binnen ontwikkelteams, andere komen nog wat minder frequent voor.

Automatische build

Eén van de eerste zaken die we op orde moeten brengen is het build proces. De geautomatiseerd build levert als output de packages, componenten en/of executables die uiteindelijk naar de verschillende omgevingen gedeployed zullen worden. Team Foundation Server biedt al lange tijd de mogelijkheid om een geautomatiseerde build in te richten en ieder zichzelf respecterend ontwikkelteam maakt hier ongetwijfeld gebruik van?!? Tegenwoordig kunnen we ook gebruik maken van de hosted build feature van Azure DevOps. In dit geval hebben we geen eigen resources meer nodig voor het inrichten van bijvoorbeeld een build server. Hierdoor wordt de geautomatiseerde build een absolute ‘no- brainer’!

Automatisch testen

De volgende stap is het inrichten van het geautomatiseerd testen. In eerste instantie leggen we de focus op eenvoudige unit tests die de correcte werking van (losse) componenten aantonen. Vervolgens kunnen we de geautomatiseerde test uitbreiden met bijvoorbeeld ingewikkeldere integratie scenario’s. Het maken van goede unit tests is niet altijd even eenvoudig en verreist enige oefening. Op bestaande projecten, waarvoor nog geen unit testen beschikbaar zijn, kan het starten met geautomatiseerd testen een tijdrovend werk zijn. In dat geval kan de ‘Smart Unit Test’ feature van Visual Studio 2015 preview uitkomt bieden! Hiermee kunnen we een complete set van unit testen genereren met een hoge code coverage.

Deployment omgeving

De automatische build en geautomatiseerd testen helpen ons bij het valideren en/of garanderen van de kwaliteit van de opleveringen die we doen. De volgende stap is de provisioning van de omgevingen waarop we een deployment kunnen uitvoeren.
In eerste instantie richten we ons hierbij op het standaardiseren van de infrastructuur en de configuratie van deze verschillende omgevingen. Juist hier kunnen we gebruik maken van de kracht van Microsoft Azure. Binnen een paar minuten hebben we aantal Virtual Machines beschikbaar waarop we onze software kunnen deployen. Met behulp van eigen templates en Powershell Desired State Configuration, is het vervolgens mogelijk om het aanmaken en configureren van deze omgevingen volledig te automatiseren.
Een andere mogelijkheid die we hebben om dit doel te bereiken is het Cloud Deployment Project. We hebben al eerder gezien dat dit ons een manier biedt om de omgeving en bijbehorende configuratie vast te leggen als source code. Onze infrastructuur en bijbehorende configuratie wordt daarmee beheersbaar. Het feit dat de configuratie wordt vastgelegd in een leesbaar JSON formaat biedt ons nog een ander voordeel. Development en Operations kunnen de output van het Cloud Deployment Project gebruiken om afstemming te bereiken over de benodigde infrastructuur en configuratie. Feedback tussen beide afdelingen!
Het is belangrijk dat we de provisioning van onze omgevingen zoveel als mogelijk automatiseren. We streven naar een voorspelbaar en herhaalbaar proces zodat we iedere oplevering op een ‘schone’ omgeving kunnen uitvoeren. Hierdoor minimaliseren we de kans dat er allerlei handmatige en niet gedocumenteerde acties worden uitgevoerd op een development en/of test omgeving ‘om de boel aan de praat te krijgen’. Uiteraard met het risico dat de oplevering vervolgens niet werkt in productie.

Release pipeline

Als laatste stap hebben we een mechanisme nodig dat de opgeleverde software (output van een build) op een gecontroleerde wijze door de verschillende omgevingen ‘duwt’. Team Foundation Server biedt hier al enige tijd het product Release Management voor. Sinds eige tijd is Release Management, als onderdeel van VSTS, ook als dienst beschikbaar. Er is dus geen installatie en/of configuratie meer nodig om gebruik te maken van Release Management Online (RMO)!

Met behulp van Release Management kunnen we exact specificeren welk pad een oplevering vanuit de Development omgeving naar Productie omgeving moet doorlopen. We kunnen daarbij ook aangeven welke (handmatige) goedkeuringen er noodzakelijk zijn voordat een oplevering doorgezet kan worden naar een volgende omgeving. Daarnaast hebben we volledig inzicht in alle stappen die uitgevoerd zijn tijdens de deployment, wie er goedkeuring heeft gegeven en welke bugs zijn er opgelost in de release.
Kortgezegd, we kunnen dus een geavanceerde release pipeline opzetten!

Het eerder genoemde Cloud Deployment Project kan als input dienen voor het configureren van de omgevingen die binnen Release Management Online gebruikt worden. RMO kan op dit moment alleen nog gebruik maken van Azure Virtual Machines als deployment omgeving en is nog niet in staat een deploy te doen naar bijvoorbeeld Azure Websites. Wellicht dat dit nog gaat veranderen?!?

Continuous Deployment met Azure Websites en VSTS

We weten nu dat we met behulp van Powershell, Desired State Configuration, Cloud Deployment Projecten en Azure Virtual Machines in staat zijn om geautomatiseerd een deployment omgeving op te zetten, die we vervolgens kunnen gebruiken binnen een geavanceerde release pipeline. Maar wat als we gebruik maken van een Azure SaaS product zoals Azure Websites? In dat geval hebben we geen (eigen) virtual machines waar we onze deployment omgevingen op moeten configureren. Kunnen we dan geen Continuous Delivery doen…? Gelukkig biedt Azure Websites i.c.m. VSTS ook een aantal interessante mogelijkheden!

Deployment Slots

Azure Websites biedt ons een out of the box, volledig beheerde omgeving voor het hosten van bijvoorbeeld onze ASP.NET MVC website. Eén van de mooie features van Azure Websites is dat we hier zogenaamde Deployment Slots kunnen definiëren. Een Deployment Slot kunnen we omschrijven als een ‘kopie’ van onze website in een eigen Azure Website omgeving. We kunnen voor onze website bijvoorbeeld een ‘development’ en een ‘acceptatie’ slot definiëren. Dit betekent dat er naast de productie versie van onze website nog twee extra omgevingen beschikbaar zijn die we elke via een eigen URL kunnen benaderen.

Als we vervolgens onze source code in VSTS beheren, dan kunnen we in de Azure Portal een koppeling leggen tussen een Deployment Slot en onze Visual Studio Solution in source control. In het plaatje hieronder zien we dat er voor de website ‘DevopsDemoWebsite’ twee extra Deployment Slots gedefinieerd zijn. Het development slot is gekoppeld aan source control. Op het moment dat we deze koppeling maken, wordt er automatisch een build definition aangemaakt in onze Visual Studio omgeving. Deze zorgt er voor dat vanaf dat moment iedere build output in het development slot van onze website terecht komt. De Azure Portal toont voor ieder van de Deployment Slots een overzicht van alle builds die daar terecht zijn gekomen. De laatste build wordt automatisch de actieve deployment maar met één druk op de knop kunnen we binnen het Deployment Slot terug schakelen naar een eerdere build.

Deployment Slot Swap

Met behulp van de Swap functionaliteit in de Azure Portal, kunnen we een bepaalde oplevering naar een ander Deployment Slot doorzetten. Op deze manier kunnen we bijvoorbeeld heel eenvoudig een oplevering uit het development Deployment Slot doorzetten naar het acceptatie Deployment Slot. Met behulp van deze functionaliteit kunnen we dus ook voor Azure Websites een eigen release pipeline opzetten. In vergelijking met RMO biedt het minder mogelijkheden voor geavanceerde workflows binnen de release pipeline. Vaak hebben we dat, in eerste instantie, ook helemaal niet nodig en biedt bovenstaande een voldoende krachtig middel om op een verantwoorde manier om te gaan met onze releases!

Azure Websites Production Testing

Eén van de belangrijke pijlers van DevOps is het snel reageren op feedback vanuit Development, IT Pro of gebruikers. Deze feedback kunnen we echter niet altijd krijgen uit een ontwikkel of test omgeving.

Stel, we hebben een wijziging doorgevoerd die de performance van de website moet verbeteren. Met behulp van de hierboven genoemde Deployment Slots kunnen we deze wijziging testen in de ontwikkel en/of test omgeving. Als het goed is, geeft dit een realistisch beeld van de effectiviteit van de aanpassing. Echter, is het in zo’n geval niet waardevol als we de wijziging ook kunnen testen in een productie omgeving? Een ander voorbeeld…We hebben een aanzienlijke user interface aanpassing doorgevoerd in onze applicatie. Voordat we deze wijziging in productie doorvoeren, willen we meten of de wijziging het gewenste effect heeft op eindgebruikers. Hoe doen we dit?

Voor beide scenario’s bied Azure Websites ‘Production Testing’ uitkomst! Met deze feature zijn we instaat om een gedeelte van het verkeer op onze productie website af te laten handelen door bijvoorbeeld de versie die in het acceptatie slot draait. Dit betekent dat een deel van de gebruikers, zonder dat zij het weten, gebruik maken van de nieuwe versie van de software. Zoals we in het figuur hieronder zien, kunnen we zelf bepalen welk percentage van het verkeer op de productie website door een ander deployment slot afgehandeld dient te worden. Op basis van feedback en monitoring informatie (zie volgende blog), krijgen we met behulp van ‘production testing’ een nog beter beeld van de kwaliteit en effectiviteit van een bepaalde aanpassing en kunnen we een beargumenteerde keuze maken om een swap actie wel of niet uit te voeren!

Samenvatting

Natuurlijk omvat Continuous Delivery veel meer dan de hierboven beschreven onderwerpen. In deze blog hebben we gezien dat de combinatie van Visual Studio Team Services, Release Management (Online) en Microsoft Azure krachtige mogelijkheden biedt voor Continuous Delivery. Het biedt een mooie start en het is zeker de moeite waard om daar eens mee te experimenteren…!

Een volgende stap op weg naar DevOps is Continuous Learning. In de volgende post kijken we hoe Application Insights hierbij kan helpen!

Wordt vervolgd…

Edward Bakker is een Microsoft Azure MVP en werkt als solutions architect bij Delta-N. Hij focust zich op oplossingen gebaseerd op het Microsoft Azure platform.