Release automation met Octopus Deploy

Binnen Mirabeau zijn we continu op zoek naar manieren om ons werk efficiënter, gemakkelijker en minder foutgevoelig te maken. Zo ook voor het uitrollen van releases. Ruim een half jaar geleden (medio 2015) zijn we over gestapt van Nolio (CA Lisa) naar Octopus Deploy voor de uitrol van software voor het NVM platform.

Waarom Octopus Deploy?

De belangrijkste reden om voor Octopus Deploy te kiezen is het gemak. De tool is eenvoudig te installeren en in te richten. Octopus werkt met zogenaamde stappen, bouwblokken waarmee je allerhande werkzaamheden kunt automatiseren. De stappen zijn op basis van PowerShell geschreven en met enige kennis van PowerShell kun je zelf eenvoudig stappen aanpassen of aanmaken. Er is een community library waar standaard stappen te downloaden zijn en waar je zelf stappen aan toe kunt voegen. Het is aan te raden om de community library te bezoeken voordat je zelf een nieuwe stap gaat maken om te voorkomen dat je iets gaat maken wat een ander al heeft gedaan.

Mogelijkheden van Octopus Deploy

Octopus is hoofdzakelijk voor het uitrollen van releases. Het biedt een overzicht van de uitgerolde releases per omgeving. Je kunt eenvoudig de release geschiedenis per applicatie per omgeving inzien. En omdat bijna alles te “PowerShellen” is kun je Octopus Deploy breed inzetten en eenvoudig koppelen aan andere applicaties. Voorbeeld release overzicht:

Octopus afbeelding 1

Tegenwoordig is de scheiding tussen DEV en OPS steeds dunner. Hier moeten werkwijzen op aangepast worden. Door de inzet van Octopus Deploy dwingen we de bekende OTAP workfow af. Hierdoor kunnen ontwikkelaars bijvoorbeeld de release testen in hun test omgeving en verder uitrollen in de straat wanneer alle testcriteria goed zijn doorlopen. Een ander voordeel is dat je aan het begin van een project al na moet gaan denken over wijze waarop een applicatie de gehele OTAP straat doorloopt, dit ontwerp is cruciaal om in een later stadium snel en geautomatiseerd nieuwe features live te brengen.

Wanneer alle applicaties en configuraties in een release automation proces geborgd zijn, is het beheer veel overzichtelijker. Door met centrale repositories te werken voorkom je dat data verspreid wordt opgeslagen of gemuteerd. Een centrale informatiebron voor alle code en scripts.

Hoe we bij NVM Octopus Deploy inzetten

Binnen het netwerk van de NVM wordt Octopus Deploy ingezet van de ontwikkel en test omgeving bij DEV tot de acceptatie, certificerings en productie omgeving. Door deze inzet hebben we de verschillende omgevingen gelijk getrokken en kan development beter aansluiten op de acceptatie en productie omgeving. Per applicatie hebben we een release proces wat we over de gehele OTAP uitrollen. Per omgeving hebben we specifieke bestanden, zoals configuratie bestanden. Deze files worden centraal in GIT bijgehouden. TeamCity haalt de configuratie bestanden op en zet ze in de package bij de code. Alle configuratie bestanden voor alle omgevingen worden iedere keer uitgeleverd. Alleen de bestanden die voor de betreffende omgeving benodigd zijn worden hernoemd naar de juiste filenaam en de bestanden voor de overige omgevingen worden verwijderd. De code wordt vanuit TeamCity gebuild en als package klaar gezet in Octopus Deploy.

Bij de NVM hebben we te maken met 3e partijen die ook software voor de NVM ontwikkelen. Deze 3e partijen leveren packages aan die rechtstreeks in Octopus Deploy worden gezet. Door deze werkwijze af te dwingen zijn ook deze releases “gestandaardiseerd” en kunnen daardoor snel uitgerold worden.

Onderstaand proces geeft een globaal overzicht van de implementatie.

Octopus afbeelding 2

De Octopus Deploy flow

De meeste applicaties zijn redelijk standaard van opzet. Vaak hebben ze een front-end, backend en een database gedeelte. Deze delen voeren we opvolgend uit. Om de release te voltooien voeren we een aantal afrondende taken uit. Om te verifiëren of de release succesvol is uitgevoerd kan er via MS Test diverse testen worden uitgevoerd. De resultaten van deze testen worden in een rapport gezet en beschikbaar gesteld. De laatste stap van de release is het markeren van een release in New Relic om zo de performance van de omgeving voor en na de release met elkaar te vergelijken. Er wordt ook een bericht gedaan naar een “releases” kanaal binnen Slack. Op deze manier is voor iedereen zichtbaar wanneer een release is uitgevoerd. Hier onder een voorbeeld van een proces: 

Octopus afbeelding 3

Meer weten?

Binnen Mirabeau is een Octopus Deploy vakgroep die kan helpen bij het inrichten van Octopus Deploy. Denk hierbij aan het inrichten van omgevingen en releaseprocessen. Mocht je hier meer over willen weten dan kun je uiteraard contact met me opnemen.