Follow Us on Twitter

Continuous Delivery

Oktober 2013 - Nu de meeste bedrijven aan het werk zijn met Agile en Scrum is het nu tijd om de volgende stap te zetten, naar Continuous Delivery. Continuous Delivery staat voor snel, kwalitatief opleveren van software naar productie.

In dit Whitebook worden de beginselen van Continuous Delivery tegen het licht gehouden. Verder worden de eerste stappen gezet voor het klaar maken van je projecten voor Continuous Delivery.

Wat is Continuous Delivery?

Continuous Delivery wordt vaak vergeleken met een lopende band in een fabriek. Hierop worden continu producten geplaatst. Aan de lopende band staan controleurs om te controleren of deze producten voldoen aan de kwaliteitsnormen van de fabrikant. Zodra een controleur een afwijking constateert aan het product wordt deze van de band verwijderd. Continuous Delivery werkt op dezelfde manier als deze lopende band. De producten zijn de software packages en de controleurs zijn de geautomatiseerde testen. Zodra een package wordt afgekeurd wordt deze verwijderd.

Het sleutelwoord van Continuous Delivery is "Automatiseren". Dit houdt in: "Automatiseer waar het kan, bij deployments, testen, documentatie, release notes etc..". Echter, met automatiseren alleen red je het niet om snel in productie te gaan. Hiervoor moeten ook beheerders, testers en analisten vertrouwen hebben in het product dat opgeleverd wordt. Zij hebben immers de verantwoordelijkheid om de kwaliteit van het product te waarborgen.

Naast "Automatiseren" is "Vertrouwen" een sleutelwoord voor het gehele proces. Om het vertrouwen van alle betrokken partijen te winnen, is het belangrijk iedereen tijdens het ontwikkel-/testproces mee te laten denken en te informeren hoe het product ontwikkeld en getest wordt. Met behulp van rapportages (test, analyse) kan het vertrouwen versterkt worden.

Het streven van Continuous Delivery is dat elk stuk code dat ingecheckt wordt van voldoende kwaliteit is, zodat de package die daaruit voortkomt in productie kan worden gezet.

Met een hoge frequentie van opleveringen naar productie komen er een aantal vragen naar boven waarop in dit Whitebook antwoord gegeven zal worden.

  • Hoe weet ik nu met welke sources mijn build is gebouwd?
  • Hoe borg ik kwaliteit en betrouwbaarheid van de software?
  • Hoe ga ik alles goed uitrollen?
  • Wat staat er in productie?
  • Hoe ziet mijn oplevering eruit?
  • Wat ga ik doen als het fout gaat?

Continuous Delivery Proces

Stap 1 (initieel build job)

De lopende band begint bij Continuous Delivery bij de build server. Elke build op deze server is een potentiële release naar productie. Zo wordt bij de eerste build job een branche in het versie controle systeem (VCS) gemaakt en hiervan wordt het versienummer bepaald. Deze bestaat meestal uit drie cijfers, major.minor.build. Dit is voor de meeste applicaties voldoende. Echter voor complexere applicaties komt een vijf-cijferig versienummer beter tot zijn recht (hierover in een later hoofdstuk meer). In de tweede build worden de unittesten uitgevoerd. Bij het falen van de unittesten wordt de branche verwijderd. Bij het slagen van de unittesten worden de integratietesten uitgevoerd. Aan het einde van de build wordt de package opgeleverd aan een Artifact repository.

Stap 2 (code kwaliteit job)

In de code kwaliteit job wordt er gekeken naar de kwaliteit van de code die is opgeleverd. In deze job wordt de code automatisch geanalyseerd door een tool zoals Sonar, Jacoco, Cobertura etc. Deze tools hebben heel veel controleregels die losgelaten kunnen worden op de code. Door al de regels toe te passen op de code ontstaat er mogelijk meer ruis dan kwaliteit. Zorg dat in het begin een beperkte set aan regels wordt toegepast en breidt dit later uit om de kwaliteit van de software verder te verhogen. Gebruik de uitkomst van de analyse tool om de job te laten falen of door te gaan naar de volgende job.

Continuous Delivery Proces
Het Continuous Delivery proces

Stap 3 (test job)

Bij de test job wordt de package gedeployd op een testomgeving. Dit kan met behulp van een bestaande test omgeving of met behulp van Tooling als Cargo of Puppet. Cargo is een tool voor het opzetten van een JEE container. Binnen deze container kan je je applicatie deployen om vervolgens testen hierop uit te voeren. Puppet is een tool voor het automatisch inrichten en bijwerken van een omgeving. Het voordeel van Puppet boven Cargo is dat de scripts van Puppet hergebruikt kunnen worden tot aan de productieomgeving. Wanneer de testomgeving is opgebouwd met de nieuwe software wordt er verder gegaan met de volgende job.

Stap 4 (acceptatietest job)

De acceptatietesten worden in een aparte job gestopt. Dit heeft als reden dat de acceptatietesten op alle verschillende omgevingen gedraaid moeten worden. Dit houdt in dat alle acties die de acceptatietesten uitvoeren teruggedraaid moeten worden om geen vervuilde omgeving achter te laten. Het is gebruikelijk om deze testen uit te voeren vanaf een server die alle omgevingen kan benaderen.

Stap 5 (QA job)

De QA job wordt gebruikt om te kunnen deployen op de QA-omgeving. De QA-omgeving is gelijk aan de productieomgeving. Hierop voert het QA-team smoke testen uit en andere geautomatiseerde testen als load- en gebruikersacceptatietesten.

Stap 6 (acceptatietest op QA)

Ook na het deployen op de QA-omgeving wordt de acceptatietest uitgevoerd. Die wordt gedaan om de kwaliteit van de package te controleren op QA. Dit geeft het QA-team meer vertrouwen over de kwaliteit van de package die is opgeleverd waardoor het QA-team alleen gerichtere testen hoeft uit te voeren om de totale testtijd te verkorten.

Stap 7 (productie job)

De productie job binnen Continuous Delivery is meestal een handmatige actie. Na goedkeuring wordt de package geautomatiseerd op productie gedeployd. Elke package die op dit punt komt voldoet aan alle eisen die gesteld zijn aan het opleverproces. Vanuit de business kan op een gegeven moment besloten worden om een bepaalde build wel of niet in productie te nemen. Deze keuze kan te maken hebben met allerlei factoren. Dit is de reden om deze job handmatig uit te kunnen laten voeren.

En hoe nu verder?

Het proces zoals dat in het vorige hoofdstuk is beschreven ziet er allemaal veelbelovend en ideaal uit om snel tot kwalitatief goede sofware te komen. Maar waar start ik mee om Continuous Delivery succesvol in mijn huidige ontwikkelproces te integreren?

Allereerst begin je met het automatiseren van builds. Zorg dat deze met één druk op de knop gebouwd kunnen worden. De package die uit het bouwproces komt moet op elke omgeving gedeployd kunnen worden, eventueel met een deployment- of configuratieplan. Voor het automatiseren van de builds kan er gebruik worden gemaakt van tools als Maven, Ant of Gradle.

De volgende stap is het introduceren van unittests. Neem deze elke keer mee in de build scripts. Met de unittests wordt er gekeken of componenten nog naar verwachting werken. Deze testen hebben als eigenschap dat ze kort en krachtig zijn.

Na de unittesten komen de integratietesten. Dit zijn testen die over verschillende componenten heen gaan. Met behulp van deze testen worden database acties uitgevoerd tegen een embedded database zoals H2, HSQLDB of Derby databases. Ook worden hier testen uitgevoerd om de integratie met andere componenten te testen zoals API’s. De integratietesten kosten in de praktijk vaak meer tijd dan unittesten. Zorg ervoor dat deze testen los van de unittesten gedraaid kunnen worden binnen je build scripts.

Wanneer bovenstaande stappen zijn uitgevoerd op de te deployen package kan er met deze package gewerkt worden in een Continuous Delivery proces.

Continuous Delivery & Scrum

Continuous Delivery is geen vervanger maar een aanvulling op Scrum. Waar Scrum ophoudt bij het geven van een demo aan de "stakeholders", gaat Continuous Delivery verder met de opgeleverde package. Continuous Delivery zorgt ervoor dat de opgeleverde software voldoet aan een bepaalde kwaliteitsnorm, door dit geautomatiseerd door de omgevingen heen te testen. Scrum zorgt ervoor dat kleine stukjes functionaliteit (user stories), binnen een Sprint opgeleverd kunnen worden . Vervolgens wordt met behulp van Continuous Delivery het resultaat door de OTA-straat naar productie geloodsd.

Om Scrum nog effectiever te maken kan het ontwikkelproces Test Driven Development (TDD) gebruikt worden. Met dit ontwikkelproces begint de ontwikkelaar met het schrijven van testen voor de functionaliteit die gebouwd moet worden. In het begin falen deze testen, naarmate de ontwikkelaar de functionaliteit gebouwd heeft, zullen deze testen slagen. Na het slagen van de testen, worden de nieuwe sources ingecheckt binnen het VCS. Na het inchecken kan er direct begonnen worden met initieel bouwen van het Continuous Delivery proces.

Welke versiebeheersysteem (VCS) moet ik gebruiken?

Op het moment van schrijven zijn er een tweetal populaire VCS’en beschikbaar (Mercurial en GIT) en één die nog bij veel bedrijven wordt gebruikt (Subversion). Mijn voorkeur gaat naar GIT en Mercurial boven Subversion. Dit heeft te maken dat deze twee tools lokaal een repository bijhouden (gedistribueerd versiebeheer). Hiermee heeft de ontwikkelaar het voordeel dat de geschiedenis van de code wordt bijgehouden, zonder direct in te hoeven checken op de server. Hierdoor blijft de basis (trunk) op de server schoon, waardoor het proces van Continuous Delivery altijd gestart kan worden zonder complicaties met niet werkende code. Wanneer de ontwikkelaar klaar is met zijn aanpassing en die getest heeft, kan het als geheel naar de server worden gepusht, inclusief wijzigingshistorie. Hierna kan de ontwikkelaar de "initeel build job" starten om zijn nieuwe functionaliteit te laten testen door de gehele straat heen.

Continuous Delivery Tools
Continuous Delivery Tools

Versionering: het vijfcijferige nummer

Zoals al eerder beloofd in Stap 1 van Continuous Delivery Proces wordt er in dit hoofdstuk het vijf-cijferige versienummer verder toegelicht. De eerste twee cijfers zijn major cijfers. Het eerste major cijfer wordt bepaald door de Architectuurgroep. Wanneer er op het gebied van architectuur grote veranderingen plaatsvinden zal dit nummer opgehoogd worden. Het tweede major cijfer wordt gebruikt voor veranderingen op het gebied van interfaces. Het derde en vierde cijfer zijn minor cijfers. Het eerste minor cijfer wordt gebruikt voor kleine applicatiewijzigingen ter verbetering van de kwaliteit van de software. Het vierde minor cijfer wordt gebruikt voor hotfixes. Het laatste cijfer wordt gebruikt voor source referentie.

Conclusie

Om tot de conclusie te komen worden eerst de vragen beantwoordt zoals deze naar voren kwamen in: "Wat is Continuous Delivery?".

  • Hoe weet ik nu met welke sources mijn build is gebouwd?
    Op basis van het vijfde cijfer van het versienummer kan er eenvoudig herleid worden op basis van welke sources de build gebouwd is.
  • Hoe borg ik kwaliteit en betrouwbaarheid van de software?
    De kwaliteit en de betrouwbaarheid van software worden geborgd door het uitvoeren van geautomatiseerde testen door de gehele straat heen.
  • Hoe ga ik alles nu goed uitrollen?
    Het Continuous Delivery proces beschrijft heel duidelijk dat elke omgeving op dezelfde manier uitgerold moet worden. Dit houdt in dat het uitrollen van de nieuwe software net zo getest wordt als de software zelf.
  • Wat staat er nu in productie?
    Op basis van Stap 7 van het Continuous Delivery proces kan er eenvoudig worden herleid welke versie gedeployd is in productie.
  • Hoe ziet mijn oplevering eruit?
    De oplevering is voor elke omgeving op dezelfde manier in elkaar gezet met behulp van Ant, Maven of Gradle.
  • Wat ga ik doen als het fout gaat?
    Het Continuous Delivery proces zorgt ervoor dat packages die falen worden verwijderd voordat deze in productie gaan. Mocht het voorkomen dat er een bug gevonden wordt in productie kan deze snel door het proces worden gedeployd naar productie toe.

Continuous Delivery is een proces dat ingezet kan worden,of het nu een klein bedrijf is of een enterprise, met één of 500 ontwikkelaars. Continuous Delivery zorgt voor overzicht en een betere kwaliteit van de opleveringen van software door het automatiseren van alle technische aspecten in een oplevering, alsook het bevorderen van de samenwerking tussen verschillende belangengroepen (vertrouwen).

Referenties

Reacties

Nieuwe reactie inzenden

De inhoud van dit veld is privé en zal niet openbaar worden gemaakt.

Meer informatie over formaatmogelijkheden

CAPTCHA
Deze vraag is om te testen of u een persoon bent en om spam te voorkomen
Image CAPTCHA
Enter the characters shown in the image.