Continuous integration met Microsoft Azure

Door: Jeroen Niesen | 30-12-2016

Continuous integration (CI) is een vakterm binnen software ontwikkeling. Het is een methode die ervoor zorgt dat software een kortere time-to-market heeft en kwalitatief beter in elkaar zit. Bedrijven kunnen middels deze methode sneller reageren op de vraag uit de markt.

CI staat op dit moment bij veel bedrijven hoog op de agenda. Met de komst van Agile ontwikkelmethoden als Scrum is het voor ontwikkelteams mogelijk geworden om snel te reageren op wijzigingen uit de markt en verzoeken vanuit de business. Dit leidt ertoe dat de periode tussen software releases kleiner wordt en software vaker in gebruik genomen moet worden. Dit zien we ook bij Microsoft. Visual Studio Team Services (VSTS) wordt periodiek bijgewerkt. Ook in Azure is men in staat om op korte termijn wijzigingen door te voeren.

CI is een proces dat onderverdeeld kan worden in vijf stappen. Wij willen u inzicht geven in de werking van CI en hoe dit ondersteund kan worden met Microsoft oplossingen binnen uw organisatie.

Continuous integration: het proces
CI is een proces dat onderverdeeld kan worden in vijf stappen:

  • Requirement Analysis – Het verzamelen van requirements voor de te bouwen features;
  • Developement – Het omzetten van requirements naar programmeercode;
  • Build – Het compileren van de software en het uitvoeren van unittests;
  • Testing – Het uitvoeren van functionele, acceptatie, regressie en integratie tests;
  • Deploy to Production – Het plaatsen van de applicatie in productie en het monitoren hiervan.


Continous integration het proces
Diagram 1. Continuous Integration: het proces 

> Requirements Analysis
De eerste stap in het CI-proces is het verzamelen en administreren van requirements. Het is belangrijk om deze requirements te administreren in een systeem dat uitgelezen kan worden via een API of CLI. Als requirements slim geformuleerd worden (bijv. in Gherkin Language) kunnen deze requirements later gebruikt worden als basis om te testen. Het testframework is via de CLI/API in staat om het requirement op te vragen, en dit te gebruiken als testscript. Door de koppeling tussen het testframework en de requirementsadministratie, kan er getest worden of de gebouwde software werkt zoals beschreven staat in het requirement.
 
Vastleggen van requirement in Visual Studio Team Services
Figuur 1. Het vastleggen van een requirement in VSTS

Microsoft VSTS is een systeem waarin het mogelijk is om requirements op te slaan. Het systeem ondersteund het gehele Scrum proces (incl. een digitaal scrumbord). De eerdergenoemde requirements vormen de backlog voor het ontwikkelteam. Door de API/CLI is het mogelijk om de backlog vanuit een ander systeem/framework te raadplegen. Tevens is het mogelijk om workitems (record waarin het requirement/werk etc. in wordt opgeslagen) naar eigen wens aan te passen.

> Development & Builds
De tweede stap in het proces is het omzetten van het requirements naar software. In deze stap wordt er geprogrammeerd, en de programmeercode ingecheckt in een version control system. Nadat de code is ingecheckt kan deze gebruikt worden door het build automation system. Het build automation system voert veelal de volgende taken uit:

  • Het toekennen van een versienummer aan de software;
  • Het compileren van de programmeercode;
  • Het uitvoeren van unittests.

VSTS is in staat om changesets (ingecheckte code in het version control system) en builds te koppelen aan een requirement. Testresultaten van unittests, die draaien tijdens het buildproces, kunnen ook worden gekoppeld aan requirements en changesets.
 
De uitvoer van het buildproces in Visual Studio Team Services
Figuur 2: De uitvoer van het buildproces in VSTS

Het buildproces wordt uitgevoerd op een buildagent. In VSTS kan dit een hosted buildagent zijn in de cloud, of een agent die lokaal op een VM draait. De activiteiten in het buildproces zijn PowerShell of Javascript (node.js) gestuurd. Hierdoor kan VSTS ook ingezet worden om apps voor Android, Linux en Mac te compileren. Het is ook mogelijk om zelf taken te schrijven die in het build-proces uitgevoerd kunnen worden. 

> Testing & Release Management
In de derde stap worden de artifacts die afkomstig zijn uit de build gedistribueerd naar de testomgevingen. Deze testomgevingen hoeven niet noodzakelijk on-premise te staan. De cloud is een uitermate geschikt platform om testomgevingen op te draaien. Een testomgeving is vaak maar een korte tijd nodig. In de cloud kan voor korte duur een virtuele machine of website worden gehost. Er wordt dan enkel betaald voor de periode dat de cloud-dienst is gebruikt.
Vaak wordt er gebruik gemaakt van meerdere testomgevingen. Iedere omgeving heeft zijn taak. Een methodiek die vaak wordt gebruikt voor testomgevingen is OTAP. In de situatie van CI hebben de OTAP-stages de volgende taken:

  • O – Uitvoer van integratie en acceptatie tests. Deze tests draaien automatisch na iedere release build;  
  • T – Omgeving waarop handmatig getest kan worden;  
  • A – Omgeving voor de acceptatie omgeving;
  • P – Omgeving waarop de productieversie van de applicatie staat.

De distributie van een release kan geautomatiseerd worden door gebruik te maken van een release management systeem. In VSTS zit een systeem dat hiertoe in staat is. Dit systeem zorgt naast de distributie ook voor de configuratie en installatie van de applicatie op de testomgeving. Het release management systeem stelt verder de tester of kwaliteitsdeskundige in staat om de release af te keuren of te promoveren naar de volgende omgeving. Wanneer een release wordt gepromoveerd naar een volgende omgeving, zal hier automatisch de distributie en deployment voor uitgevoerd worden. 

Een release definitie in Visual Studio Team Services.
Figuur 3: Een release definitie in VSTS

Release Management in VSTS maakt net als het build automation system gebruik van PowerShell gestuurde taken om software te distribueren en installeren. Indien gewenst is het mogelijk om hier zelf taken aan toe te voegen.
Na de distributie kan er getest worden. Het is belangrijk hiervoor een testframework te kiezen waarbij de testscripts uit een extern systeem gehaald kunnen worden. Door de omschrijving van het requirement (in Gherkin Language) te gebruiken als testscript, kunnen we testen of het juiste gebouwd is (volgens het requirement). 

> Deploy to production
Als laatste stap in het release management proces wordt de release gedistribueerd naar de productieomgeving. Vanaf dit moment is het belangrijk om de applicatie te monitoren. Application Inisights vormt de koppeling tussen productie en development. Door de integratie met Visual Studio wordt het adresseren en oplossen van fouten erg makkelijk; bevindingen uit productie kunnen worden teruggeleid naar stukken code. Ook is het mogelijk om de applicatie te monitoren middels SCOM, en alerts die voortkomen uit deze monitoring door te zetten naar VSTS/TFS. Op deze manier geeft de applicatie die in productie staat weer input (requirements) voor de volgende iteratie in het CI-proces.

Deploy to production Continuous integration
Figuur 4. Continuous integration: Deploy to production

Automatiseren van continuous integration
Vrijwel alle activiteiten binnen het CI-proces kunnen worden geautomatiseerd. Hoe meer er geautomatiseerd is, hoe hoger de kwaliteit van het CI-proces is. Door het proces te automatiseren doorloopt ontwikkelde software altijd hetzelfde traject. Hierdoor worden er geen stappen vergeten en/of overgeslagen.

Door gebruik te maken van VSTS zijn veel zaken snel geconfigureerd en geautomatiseerd. De meeste bedrijven zullen vrijwel geen aanpassingen/toevoegingen te hoeven doen aan VSTS om hiermee aan de slag te kunnen.

De meerwaarde van continuous integration in organisaties
CI kan een grote meerwaarde bieden in de bedrijfsvoering. Het CI-proces stelt organisaties in staat snel te reageren op wijzigingen in de markt en verzoeken uit de business. VSTS is uitermate geschikt om samen te werken met Azure. Veel cloud-diensten integreren naadloos in Visual Studio en het build automation system. Denk hierbij aan Azure App Services, Azure Databases en Application Insights.

Om CI goed te laten werken zal de IT-afdeling meer samen moeten werken met de ontwikkelafdeling. Verder is het ook van groot belang dat de IT-medewerker bekend is met PowerShell. Vrijwel alle systemen kunnen tegenwoordig worden aangestuurd via PowerShell. Dit is dan ook de reden dat VSTS ook veelvoudig gebruik maakt van PowerShell. Tegelijkertijd zal ook de ontwikkelafdeling meer te maken krijgen met de IT-afdeling. Software zal op enkele vlakken anders geprogrammeerd moeten worden om het CI proces te laten werken.

Microsoft Azure
Met de combinatie Microsoft Azure en VSTS kunt u dus een stap verder gaan dan alleen infrastructuur-as-a-service, maar kunt u Azure gebruiken als geautomatiseerd platform voor uw applicaties. Hoe kunt u binnen uw organisatie continuous integration invoeren? De consultants van inovativ adviseren u graag. CI specialist Jeroen Niesen heeft inmiddels ervaringen met meerdere trajecten bij grote en kleine organisaties, en komt graag langs om samen te ontdekken wat de mogelijkheden zijn.