Release Management

Wat is Release Management

Release Management is het proces van plannen, beheren, en uitvoeren van de software build, inclusief het testen en uitrollen (deployen) van de software release. De release wordt typisch uitgerold over verschillende omgevingen (ook wel zuilen genoemd). Deze omgeving start met een development omgeving, gaat dan naar een testomgeving, een Accept of QA (Quality Assurance) omgeving en dan pas naar een productie omgeving, waar de software beschikbaar is voor de eindgebruiker. Vaak is de test en Accept/QA omgeving dezelfde omgeving, dus in verdere paragrafen spreken we alleen over DEV, QA, en Productie (vaak afgekort als PROD of PRD).

In Version Control hebben we besproken hoe een release in git voorbereid kan worden. In het versiecontrolesysteem zal een versie klaar staan die het build proces succesvol heeft doorstaan en klaar is om gebruikt te worden. De term die vaak gebruikt wordt voor een versie die nog niet in productie staat is Release Candidate (RC). Wanneer gestart wordt met een nieuwe release, van bijvoorbeeld versie 2.0, dan worden er vaak eerst enkele release candidates uitgerold. Deze versies worden dan gemarkeerd met 2.0-rc1, 2.0-rc2, enz. Wanneer de build stabiel genoeg blijkt te zijn dan wordt de release gedaan van de finale versie.

Het uitrollen van de software op een omgeving wordt beschreven met de term deployment of kortweg deployen van een omgeving. De deployment procedure kan heel wat tijd in beslag nemen als deze niet geautomatiseerd is. Een van de eerste zaken dat daarom geautomatiseerd wordt bij een transitie naar een DevOps gedreven organisatie is het deployment proces.

Na de build

Nadat de build uitgevoerd is geweest kan de software deployment doorgaan. Het resultaat van het build proces is vaak een archief. Dit kan de vorm aannemen van een zip/tar/jar bestand, een installatiepakket voor linux (.deb, .rpm), of een installatiepakket voor andere besturingssystemen. Dit is het artifact, het bestand of de bestanden dat nodig zijn om de deployment te kunnen uitvoeren op de verschillende omgevingen.

Dit archief wordt best goed beheerd. Er bestaat software dat gespecialiseerd is in het managen van deze artifacts en hun dependencies:

  • JFrog Artifactory
  • Sonatype Nexus Repository
  • apt/yum repositories voor Linux artifacts

Wanneer deze artifacts en hun dependencies goed beheerd worden is het gemakkelijker om oude releases terug te vinden, maar ook om rollbacks te kunnen uitvoeren of om de dependencies bij te houden in het geval dat een externe dependency niet meer teruggevonden kunnen worden.

Deployment

Het deployen van een applicatie is in veel organisaties een handmatig en intensief werk. Door middel van automatisatie kan echter de deployment van een applicatie op DEV, QA en PROD tot vrijwel een routine opdracht teruggedrongen worden. Er is veel software op de markt die helpt om het deployment proces te automatiseren. Aan de ene kant dienen de fysieke of virtuele machines klaar te staan met het juiste OS (besturingssysteem), aan de andere kant heb je het deployment proces zelf dat de software en libraries moet installeren.

Het beheren van de software op de servers zelf kan gedaan worden met automatiseringssoftware. Enkele bekende tools zijn:

  • Puppet
  • Saltstack
  • Ansible
  • Chef

Deze tools zijn allemaal zeer verschillend, maar hebben hetzelfde doel: server (of in het algemeen machine) administratie automatiseren. Ze doen dat allemaal met de “infrastructure as code”-methode, waarbij het operations team definities in code schrijft over hoe het uiteindelijke systeem er moet uitzien. Door code te gebruiken in plaats van manueel commandos uit te voeren zijn onmiddellijk enkele voordelen zichtbaar:

  • Er is een audit log
  • Historiek van alle veranderingen
  • De regels kunnen periodiek opnieuw toegepast worden, om zo niet-goedgekeurde manuele wijzigingen tegen te gaan
  • Dezelfde code kan uitgevoerd worden op meerdere machines, of meerdere omgevingen

Infrastructure automation

Het stopt niet bij de automatisatie van de software zelf. Ook de installaties van de virtuele / fysieke machines kan geautomatiseerd worden. Tegenwoordig is virtualisatie overal in de organisatie doorgedrongen. Software wordt niet meer op een fysieke machine geïnstalleerd, maar op een virtuele machine (VM). Deze VM kan vaak automatisch geïnstalleerd worden, opnieuw door gebruik van definities in code. Het is niet meer nodig om manueel een OS te installeren, dit kan allemaal automatisch gebeuren. Enkele software tools die hiervoor gebruikt worden:

  • Terraform (voor infrastructure provisioning, werkt het best met public cloud providers)
  • Vagrant (voor development)
  • Packer (voor VMware of Cloud images)
  • Docker (voor containers - zie de Containers pagina)

Dit betekent dat het volledige release proces van machine en OS tot dependencies en software volledig geautomatiseerd kan worden. Dit is belangrijk om de transitie te kunnen maken naar een echte DevOps-driven organisatie. Wanneer deployments zeer snel uitgevoerd kunnen worden, dan kan de tijd tussen 2 deployments drastisch verlaagd worden. Bedrijven die Devops toepassen, kunnen gemakkelijk verschillende deployments per dag uitvoeren.

Platform as a Service

Een alternatief voor infrastructure automation is Platform as a Service (PaaS). Wanneer PaaS gebruikt wordt, dan wordt het onderhoud van de onderliggende infrastructuur zoveel mogelijk uit handen gegeven. Deze platforms bieden de meest populaire programmeertalen aan, maar verwachten ook wel van de developers om bepaalde wijzigingen aan te brengen aan hun applicatie code om deze op hun platform te laten werken. Voor applicaties die op de cloud draaien kan dit een goede oplossing zijn, om zo snel applicaties te kunnen uitbrengen. Voor on-premise oplossingen, moet eerst de PaaS-software opgezet worden, wat redelijk wat tijd en mankracht in beslag kan nemen. Het is vaak dan ook alleen maar een optie voor grotere organisaties om dit on-premise te doen. Enkele populaire PaaS systemen zijn:

  • Heroku (cloud)
  • AWS Elastic Beanstalk (cloud)
  • Google App Engine (cloud)
  • Microsoft Azure PaaS (cloud)
  • Dokku (single-node), Deis (multi-node) voor on-premise
  • Openshift (on-premise)
  • PaaS services for Azure Stack (on-premise)

Veel van deze oplossingen ondersteunen ook containers, gebruik makend van Docker. Lees hierover meer in de sectie over Containers.

Deployment Strategies

Zero downtime deployments

Er zijn verschillende strategieën die gevolgd kunnen worden om deployments uit te rollen. Gaat het om een webapplicatie, dan betekent een outage een mogelijk verlies in omzet. Daarom opteert men best voor zero downtime deployments: het uitvoeren van deployments zonder een seconde downtime. Dit is allemaal mogelijk zolang de applicatie hierop voorzien wordt. Alle PaaS oplossingen zijn bijvoorbeeld voorzien om zero downtime deployments uit te voeren, wat betekent dat dit een zeer populaire strategie om te volgen is. Hoe applicaties ontwikkeld moeten worden is beschreven in 12-Factor apps

Blue/Green deployments

Blue/Green deployments worden gebruikt om zero downtime deployments te bereiken. Bij blue/green deployments wordt de nieuwe release eerst naast de huidige applicatie uitgerold. De stabiele, oude, release kan dan de green deployment zijn, de nieuwe deployment de blue deployment. Pas wanneer de blue deployment (de nieuwe release) volledig uitgerold is en live testen doorstaat, dan pas wordt de blue deployment op actief gezet. Op deze manier kunnen de Green/Blue omgevingen snel wisselen, om zo een zero-downtime deployments te kunnen uitvoeren. Deze techniek wordt zeer vaak toegepast in web applicaties.

Canary deployment

Een build dat succesvol is betekent nog niet dat de applicatie bugvrij is. Om de impact van nieuwe releases te beperken kan gekozen worden voor een Canary deployment strategie. In deze strategie wordt de applicatie slechts uitgerold voor een beperkt publiek, bijvoorbeeld 5% of 10% van de gebruikers. Zo is het mogelijk om snel fouten vast te stellen die alleen maar voorvallen bij deze kleine groep van eindgebruikers. Dit betekent dat niet alle eindgebruikers de impact zullen voelen als er een nieuwe bug geïntroduceerd werd in de release. Dit geeft een veel betere ervaring naar de eindgebruiker toe.

A/B Testing

A/B testing kan gebruikt worden voor feature testing. In dit geval worden bepaalde features uitgetest om de gevolgen ervan te kunnen waarnemen. Een grotere populatie zal de nieuwe feature zien. Deze groep wordt dan van dichtbij geobserveerd om na te gaan welke impact de nieuwe feature heeft en of de feature het gewenste effect bereikt.

_images/contact-in4it.png