De deployment van software is in DevOps gebaseerd op Continuous Delivery. Continuous Delivery maakt het mogelijk om allerlei soorten wijzigingen, inclusief nieuwe functies, configuratiewijzigingen, bugfixes en experimenten, veilig en snel op een duurzame manier in productie te nemen. Een Branching strategie en Base Truncs spelen hierin een belangrijke rol.

Deployment definitie

“Deployment” definiëren is geen zware opgave. We het is een term die we veel gebruiken bij software als alternatief voor het woord implementatie. Dat wil zeggen het installeren, instellen, testen en werkend krijgen van software. Software leveranciers speler hier vaak een speciale tools voor. Bijvoorbeeld de Microsoft deployment toolkit.

Het doel van Continuous Delivery

Het doel van Continuous Delivery is om de deployment van (grootschalige, complexe) software op aanvraag op een voorspelbare, routinematige manier uit te voeren.

We bereiken dit door ervoor te zorgen dat onze programmatuur altijd inzetbaar is, zelfs als duizenden ontwikkelaars continu wijzigingen doorvoeren. Daarbij elimineren we de integratie-, test- en verhardingsfasen die traditioneel volgden op “dev complete” volledig. Ook het vastlopen van het programma sluiten we volledig uit.

Waarom Continuous Delivery?

Als we software vaker willen deployen gaan we er vaak van uit dat we lagere niveaus van stabiliteit en betrouwbaarheid in onze systemen moeten accepteren. Uit onderzoek blijkt echter dat dit niet het geval is. Teams met hoge prestaties leveren namelijk consequent sneller en betrouwbaarder software op dan hun traditionele concurrenten. Dit geldt zelfs in sterk gereguleerde domeinen zoals financiële dienstverlening en overheid. Continuous Delivery biedt dus een ongelooflijk concurrentievoordeel voor organisaties die bereid zijn om te investeren in dit streven.

Continuous Delivery Deployment Best Practices

Deze Best Practices vormen de kern van Continuous Delivery en helpen ons met het behalen van verschillende belangrijke voordelen:

1. Vrijgeven met een laag risico

Het primaire doel van Continuous Delivery is om software deployment pijnloos te maken. Dat leidt tot events met een laag risico die we op elk moment en op aanvraag kunnen uitvoeren. Door patronen zoals blauw-groene deployments toe te passen, is het betrekkelijk simpel om deployments zonder downtime uit te voeren zonder dat de gebruikers er iets van merken.

2. Snellere time-to-market

Het is niet ongebruikelijk dat de integratie- en test/fix-fase van de traditionele deployment methoden weken of zelfs maanden in beslag neemt. Teams kunnen echter samenwerken om de build- en deployment-, omgevingsprovisioning- en regressietestprocessen te automatiseren. De ontwikkelaars nemen integratie- en regressietesten op in hun dagelijkse werk waardoor deze fasen volledig vervallen. Op deze manier vermijden we ook de grote hoeveelheden herwerk die de gefaseerde aanpak teisteren.

3. Hogere kwaliteit

Wanneer ontwikkelaars geautomatiseerde tools hebben die fouten binnen enkele minuten ontdekken, kunnen zij zich concentreren op testactiviteiten op een hoger niveau, zoals verkennende tests, bruikbaarheidstests en prestatie- en beveiligingstests. Door een deployment pijplijn op te bouwen, kunnen zij deze activiteiten tijdens het leveringsproces continu uitvoeren, zodat vanaf het begin kwaliteit in software wordt ingebouwd.

4. Lagere kosten

Succesvolle software zal in de loop van tijd evolueren. Door te investeren in build-, test-, deployment- en omgevingsautomatisering, verlagen we de kosten voor het maken en leveren van incrementele wijzigingen aan software aanzienlijk.  Veel van de vaste kosten die gepaard gaan met het releaseproces elimineren we namelijk.

5. Betere producten

Dankzij de Continuous Delivery Pipeline is het economisch haalbaar om in kleine batches te werken. Het grote voordeel is dat we tijdens de deployment voortdurend feedback krijgen van gebruikers op basis van werkende software. Technieken zoals A/B-testen stellen ons in staat om ideeën met gebruikers kunnen testen voordat we hele functies uitwerken. Dit betekent dat we functies die we bouwen die geen waarde voor ons bedrijf hebben, kunnen vermijden.

6. Gelukkigere medewerkers

Onderzoek heeft aangetoond dat Continuous Delivery releases minder pijnlijk maakt en de burn-out van het team vermindert. Bovendien kunnen deployment teams, wanneer we vaker releasen, actiever met gebruikers omgaan, leren welke ideeën werken en welke niet, en uit de eerste hand feedback krijgen over het werk dat ze hebben gedaan.

Branching Strategie voor Continuous Delivery Deployment

Deze technologie is een belangrijke factor voor  Continuous Delivery en Continuous Integration. Wanneer ontwikkelaars hun wijzigingen meerdere keren per dag in de trunk vastleggen, kunnen ze gemakkelijk voldoen aan de kernvereiste van Continuous Integration dat alle teamleden ten minste eenmaal per 24 uur aan de trunk bijdragen. Dit zorgt ervoor dat we de codebase altijd op afroep kunnen vrijgeven en op die manier Continuous Delivery te realiseren.

Het verschil tussen Trunk Based Development in een klein team en geschaalde Trunk Based Development is afhankelijk van de teamgrootte en de mate van commitment. Over het precieze punt waarop een ontwikkelteam niet langer ‘klein’ is en overgaat naar ‘geschaald’, valt te discussiëren. In beide gevallen voeren teams echter een volledige “pre-integratie” build uit (compileren, unit-tests, integratietests) op hun ontwikkelwerkstations voordat ze committen / pushen zodat anderen (of bots) het kunnen zien.

Trunk Based Deployment Best Practices

• Bij Trunk Based Development vs Gitflow heeft de eerste de voorkeur, ook boven andere vertakkingsmodellen met meerdere langlopende vertakkingen.
• We kunnen er voor kiezen om een “direct to trunk commit/push” te  doen of een “Pull-Request workflow”. Voorwaarde is echter wel dat die feature branches maar van korte duur zijn en het product zijn van één ontwikkelaar.
• Als je meer dan een paar ontwikkelaars aan het project werken, moeten we een buildserver implementeren om te kunnen controleren of hun commits de build niet hebben verbroken:
  – Nadat ze in de trunk zijn beland.
  – Wanneer ze klaar zijn om te worden samengevoegd, terug in de stam na een kortstondige zijtak.
• Ontwikkelteams kunnen eenvoudig in omvang groter of kleiner worden zonder de doorvoer of kwaliteit te beïnvloeden. Google kent Trunk Based Development en heeft 35000 ontwikkelaarsin één trunk werken. Deze kan uitbreiden of inkrimpen om aan de behoeften te voldoen.

• Afhankelijk van de beoogde release-cadans kunnen er release-takken zijn die just-in-time uit de Trunk worden gesneden. Dit doen we voor we een release ‘verharden’.Die takken verwijderen we dan tijdelijk tot na de deployment. Tevens kunnen er zijtakken ontbreken als het team de Trunk uitgeeft en een “fix forward” strategie toepast voor bugfixes.

Bekende Deployment systemen

Canary Deployment

Canary Deployment is een deployment-strategie die een applicatie of service incrementeel vrijgeeft aan een subset van gebruikers. Alle infrastructuur in een doelomgeving wordt in kleine fasen geüpdatet. Een kanarie-release is vanwege deze controle het minst risicogevoelig, vergeleken met alle andere implementatiestrategieën.

Kubernetes Deployment

Kubernetes, ook bekend als K8s, is een open-sourcesysteem voor het automatiseren van deployment, schaling en beheer van gecontaineriseerde applicaties.

Het groepeert containers waaruit een applicatie bestaat in logische eenheden voor eenvoudig beheer. Kubernetes bouwt voort op 15 jaar ervaring met het uitvoeren van productieworkloads bij Google, gecombineerd met de beste ideeën en practices van de community.

Geschiedenis Trunk Based Development

Trunk Based Development is geen nieuw branching model. Het woord ‘stam’ verwijst naar het concept van een groeiende boom, waarbij de dikste en langste overspanning de stam is, niet de takken die eruit voortkomen en een beperktere lengte hebben.

Trunk Based Development is een minder bekend vertakkingsmodel dat sinds het midden van de jaren negentig en tactisch gezien sinds de jaren tachtig bestaat. Grote ontwikkelingsorganisaties, zoals Google en Facebook voeren het als onderdeel van Trunk based development op grote schaal uit. Meer dan 30 jaar hebben de ontwikkeling van gerelateerde tools en technieken ervoor gezorgd dat Trunk-Based Development gangbaar is geworden. Het is een vertakkend model waar velen door de jaren heen aan hebben vastgehouden en nu vaak de basis vormt voor Continuous Delivery.

Discussieer mee op ITpedia LinkedIn of op Financial Executives LinkedIn.