Microsoft Release Management in de praktijk
Bedrijven streven ernaar om met een steeds grotere regelmaat nieuwe versies van hun product uit te brengen. Een extreem voorbeeld hiervan is Spotify, dat zeer frequent (tot wel 1 keer per minuut) een nieuwe release uitbrengt. Het belang om Release Management als proces binnen een organisatie beter in te richten en te ondersteunen met tooling wordt daardoor steeds groter.
Introductie Release Management
Release Management is het proces van het plannen, beheren, aansturen, installeren en testen van software in de verschillende stadia (bijvoorbeeld “test”, “acceptatie”, “productie”) binnen een ontwikkelstraat.
Om met grote regelmaat nieuwe releases uit te brengen is een goed geoliede machine nodig, waarin er nauwelijks tot geen handmatige stappen meer nodig zijn en kwaliteitscontroles in het hele proces verweven zijn. Denk daarbij bijvoorbeeld aan Unit Tests, Static Code Analysis, Quality Gates, Automatische Build en automatische UI tests. Als laatste stap komt dan ook het automatiseren van de installatie van de software en het bijbehorende (achterliggende) goedkeuringsproces. Dit is het moment waar Microsoft Release Management om de hoek komt kijken; een tool die integreert met Microsoft Team Foundation Server (TFS), die de installatie kan uitvoeren en die goedkeuringsprocessen ondersteunt.
Microsoft heeft deze tool in 2013 overgenomen van InCycle en heette destijds “InRelease”. Inmiddels heeft Microsoft 4 updates uitgeleverd op basis van de 2013 versie en is de 2015 versie (onderdeel van Microsoft TFS 2015) ook beschikbaar. Voor een selecte groep klanten/partners heeft Microsoft nu de “private preview” van de volgende versie van Release Management opengesteld. Deze versie is ook tijdens de conferentie “Build 2015” getoond. Er moet echter nog even gewacht worden op een definitieve eerste release van deze nieuwe versie. Ondertussen kan de huidige versie goed ingezet worden voor de hierboven beschreven processen.
Microsoft Release Management sluit aan op de automatische build van TFS. Dat betekent dat de uitvoer van de build gebruikt wordt als invoer voor het installatieproces. Daarnaast kan Release Management ook een overzicht van wijzigingen genereren, wanneer broncode wijzigingen gekoppeld zijn aan TFS Work Items (denk daarbij aan bijvoorbeeld Product Backlog Items, Tasks, Bugs etc).
Voorbereidingen
Om Microsoft Release Management in te zetten dient nagedacht te worden over een aantal zaken. Allereerst moet de software natuurlijk geïnstalleerd worden. Dat is redelijk eenvoudig, aangezien het om een applicatiedeel en een database deel gaat. Hoewel alles op één server geïnstalleerd kan worden is het aan te raden de installatie op te splitsen, waarbij database en applicatie op afzonderlijke servers geïnstalleerd worden.
Na installatie moet er een keuze gemaakt worden tussen de in te zetten technologie voor het installatieproces. Dat kan op twee manieren gerealiseerd worden in Microsoft Release Management; “Agent Based” of “vNext”. Bij Agent Based deployments wordt er een Agent geinstalleerd op alle servers waar de software op geïnstalleerd moet worden. Deze Agents vragen op regelmatige basis aan de server of er nog taken te doen zijn en wanneer dat zo is, pakken ze de taak/taken op (er is dus sprake van een “pull” model). De vNext deployments werken op basis van PowerShell DSC of Chef. DSC staat voor “Desired State Configuration”. In vNext deployments worden PowerShell DSC/Chef scripts gebruikt om een gewenste eindsituatie te beschrijven waaraan de servers moeten voldoen. Deze situatie wordt door de “Local Configuration Manager” op de server zelf vervolgens in stand gehouden (er is dus sprake van een “push” model). Overigens is het ook nog mogelijk om procedurele PowerShell scripts te gebruiken in vNext.
Kiezen voor een van deze twee oplossingen is afhankelijk van specifieke wensen en eisen. Het lijstje hieronder geeft vast een aanzet tot onderbouwing van de keuze:
Agent based:
• Agent moet geïnstalleerd worden op alle servers
• Installatieproces door middel van batchfiles, PowerShell scripts etc
• Configuratie instellingen van de applicatie worden beheerd in Release Management
• Installatiescripts worden beheerd in Release Management
vNext:
• Geen Agent installatie, wel benodigd:
• PowerShell 4.0 en
• Windows Management Framework 4.0 (standaard beschikbaar in Windows 8.1 en Server 2012 R2)
• Of: Azure Virtual Machine
• Installatie door middel van PowerShell DSC scripts of eventueel reguliere PowerShell scripts
• Configuratie instellingen van de applicatie en installatiescripts worden beheerd in TFS Source Control of dienen anderszins in de TFS Build Drop locatie terecht te komen
Daarnaast is het belangrijk te overwegen of de servers op eigen hardware gaan draaien of in de cloud (Azure bijvoorbeeld). Ook is het mogelijk om Release Management in te zetten als onderdeel van VSO (Visual Studio Online, TFS in de cloud) en zijn diverse combinaties mogelijk. Het gaat te ver om deze keuzes binnen dit artikel toe te lichten. Neem gerust contact met Delta-N op wanneer u hierover advies wil. Wij hebben zowel Cloud specialisten in dienst, als ALM specialisten met kennis van TFS en Release Management.
Wanneer voorgaande keuzes gemaakt zijn, kan gekeken worden naar inhoudelijke voorbereidingen. Om dit soort trajecten voorspoedig te laten verlopen is het belangrijk zowel de operations teams als de ontwikkelteams te betrekken. Zo kunnen er snel grote slagen gemaakt worden zonder dat men op elkaars input hoeft te wachten. Denk bij voorbereidingen aan de volgende zaken;
• Bepaling scope/opstellen backlog
• Per applicatie afspreken:
• Wat is de installatieprocedure
• Welke zaken worden configureerbaar per omgeving
• Welke rollen kunnen we benoemen (webserver, fileserver, databaseserver, windows services etc)
• Welke rechten zijn benodigd
• Eventuele netwerkvereisten zoals poorten open in firewalls e.d.
• Beschikbaar hebben van testomgevingen
Release management
Release Management kent een aantal soorten objecten die gezamenlijk een deployment pipeline vormen;
• Tool – Bevat 1 of meerdere (generieke) scripts of executables die onderdeel zijn van het installatieproces
• Action – Verwijst naar een tool en is daar een implementatie van (een Tool kan meerdere functies bevatten, een Action roept dan 1 van die functies aan)
• (vNext) Component – Vergelijkbaar met een Action, alleen is hier de koppeling naar de TFS Build Output mogelijk waardoor die als input voor de installatie gebruikt kan worden
• Server – Verwijzing naar een virtuele of fysieke server
• (vNext) Environment – Groep servers, bijvoorbeeld “Applicatie 1 – Acceptatieomgeving”
• Stage Type – stap in de pipeline, bijvoorbeeld Test, Acceptatie en Productie
• (vNext) Release Path – De volgorde van stages die doorlopen wordt met de bijbehorende Environments en approvals, bijvoorbeeld Dev > Test > Acceptatie > Productie
• (vNext) Release Template – de beschrijving/vastlegging van het installatieproces zelf, per Stage in het Release Path. Hieraan kan ook de TFS Build Definition gekoppeld worden
In het geval van de keuze voor een Agent-based oplossing dient men gebruik te maken van Tools in Release Management. De tools die standaard meegeleverd worden, werken alleen wanneer de servers zich altijd in dezelfde beginsituatie bevinden. Wanneer een website al bestaat en diezelfde website als onderdeel van de Release Template aangemaakt moet worden, zal de installatie falen. Conditionele uitvoering (if … then) of andere “flow control” is in de Release Template niet mogelijk, dit kan alleen in de scripts geïmplementeerd worden. Wel is er een rollback functionaliteit waarin bepaalde zaken teruggedraaid kunnen worden.
Veel bedrijven zullen er daarom voor kiezen om zelf scripts te gaan ontwikkelen. In deze scripts dient dan “Idempotency” ingebouwd te worden. Dat houdt in dat wanneer het script één keer gedraaid wordt hetzelfde eindresultaat bereikt wordt als wanneer het twee of meer keer gedraaid wordt (ongeacht de beginsituatie). Dit kan veel tijd kosten afhankelijk van de complexiteit. Daarom is het in bepaalde gevallen handiger om voor de vNext deployments te gaan, waar PowerShell DSC gebruikt kan worden. Idempotency is daar standaard. Echter; niet alle procedures zijn beschikbaar in PowerShell DSC. Bottomline: bekijk welke technieken het beste aansluiten bij uw situatie.
Naast het opzetten van een toolset dienen een aantal randvoorwaarden ingevuld te worden, waaronder:
• Inrichten gebruikers/rechten (standaard is het zo dat iedereen alles mag binnen Release Management)
• Aanmaken Stage Types (Administration tab > Manage Picklists)
• Koppeling met TFS maken (Administration tab > Manage TFS)
• De output van de TFS Build Definition(s) die gebruikt wordt/worden, dient zodanig te zijn dat het mogelijk is deze te gebruiken voor deployment. In sommige gevallen kan het dus nodig zijn extra procedures aan het build proces toe te voegen om dit in orde te maken
• Databaseupdates dienen ook Idempotent te zijn, zodat deze eventueel meerdere keren gedraaid kunnen worden zonder problemen
Wanneer deze voorbereidingen afgerond zijn kan met de daadwerkelijke implementatie aan de slag gegaan worden; vastleggen van Release Paths, Components en Release Templates. Als voorbereiding hierop leggen wij per applicatie minimaal de volgende zaken vast ter referentie:
• Installatieproces
• Overzicht Windows Services met gegevens zoals installatiepad, service user etc
• Overzicht Websites/Webapplications/Virtual directories/Application pools met benodigde configuratie
• Overzicht benodigde directorystructuur en permissies daarop
• Werkwijze databaseupdates
• Eventuele overige OS gerelateerde instellingen (denk bijvoorbeeld aan scheduled tasks, registry instellingen etc)
• Overzicht configuratieinstellingen (in bijvoorbeeld web.config, app.ini, etc) voor elke Stage (test, acceptatie, productie etc) in een Release Path
Deze lijst is uiteraard aan te vullen naar eigen inzicht, maar geeft al aan dat het automatiseren van een uitrol geen sinecure is.
Wanneer alle voorbereidingen gedaan zijn, kan begonnen worden met het implementeren en testen van de Release Template. Het is prettig om dit op een omgeving te kunnen doen die niet gedeeld wordt met bijvoorbeeld ontwikkelaars, testers of operationele activiteiten. Uit ervaring blijkt dat dit vaak leidt tot conflicten. Wanneer het installatieproces met Release Management functioneert en stabiel is (en gevalideerd is door zowel operations als ontwikkeling), kan het proces overgeheveld worden naar een template die daadwerkelijk gebruikt gaat worden voor de uitrol naar de verschillende omgevingen. Dit pleit ook voor een testomgeving, zowel voor Release Management zelf als voor de omgeving waar naartoe uitgerold wordt.
Wanneer blijkt dat bepaalde procedures moeilijk te automatiseren zijn, is er ook een mogelijkheid een “Manual Intervention” toe te voegen aan het installatieproces, waardoor het proces gestopt wordt en er een mogelijkheid is om handmatig zaken in te stellen. Uiteraard is het van belang dit tot een minimum te beperken.
Momenteel is het nog zo dat er niets via versiebeheer in Release Management opgeslagen wordt. Dus alle objecten in Release Management (zoals Release Templates, Components, Actions, Tools) worden overschreven zonder dat er een mogelijkheid is om terug te gaan naar een vorige versie. Daarom is het van belang dit zoveel mogelijk zelf in te richten (neem bijv. de scripts van de Tools op in TFS Source Control). Dit probleem is voornamelijk aanwezig bij Agent-based deployments en minder bij vNext deployments, aangezien daar de bron van zowel scripts als configuratie toch al TFS is.
Operatie
Wanneer een applicatie eenmaal meerdere keren succesvol naar productie gebracht is met Release Management is het tijd om het proces over te dragen aan operations. Dat betekent aardig wat kennisoverdracht, maar ook wat afspraken over wijzigingen. Wie voert deze uit, hoe worden wijzigingen vastgelegd en gecommuniceerd? Wat te doen wanneer het deploymentproces faalt? Allemaal zaken waar van tevoren over nagedacht moet worden.
Release Management – volgende versie
Sinds de overname van Release Management van InRelease in 2013, heeft Microsoft niet stil gezeten. Naast updates op de huidige versie van Release Management (Web Services, Windows Service, Deployment Agent, WPF Client) is zij begonnen met de ontwikkeling van een nieuwe versie, die eigenlijk los lijkt te staan van de huidige. Meer informatie is te vinden tussen de keynote video’s van de Microsoft Build conferentie van eerder dit jaar. Wij mogen er niets over publiceren, maar wanneer u klant bent, kunnen we wel samen met u kijken wat de mogelijkheden zijn.
Conclusie
Automatische deployment speelt een sleutelrol in DevOps processen en Continuous Delivery. Microsoft heeft een grote stap gemaakt door een tool hiervoor op te nemen binnen de ALM toolset. Wilt u aan de slag met automatische deployment, dan is Release Management een grote stap in de goede richting. Wij raden u wel aan, met het oog op de toekomst, de scripting met PowerShell op te pakken.
Mocht u met ons van gedachten willen wisselen over de inzet van Release Management, neem dan gerust contact met ons op via 085 - 487 52 00.