Geschreven door Joost Saanen op 25-2-2016
Een belangrijk aspect van de Agile methodiek is het snel kunnen leveren van bruikbare software in korte iteraties. Dit in tegenstelling tot de meer traditionele (waterval) ontwikkelmethoden waarbij er – voordat er überhaupt aan programmeren wordt begonnen – al veel voorwerk is gedaan zoals het bedenken van de architectuur/design en/of het maken van een planning. In dit soort projecten bestaat er het risico dat aan het einde van een traject een applicatie wordt opgeleverd die niet doet wat de klant of gebruiker verwacht. De Agile methodiek maakt het mogelijk om bij iedere iteratie een nieuwe release uit te brengen van de software die wordt gebouwd. De scope van een project is hier flexibel (= flexible scope) en het proces wordt zo ingeregeld dat er op vaste tijden een nieuwe release naar productie kan worden gebracht. Dit kan bijvoorbeeld op het eind van iedere sprint zijn, of zelfs meerdere keren per dag.
Om dit binnen een IT-organisatie voor elkaar te krijgen moet er wel het e.e.a. zijn ingeregeld. Zo moet de programmeercode van de software altijd in gezonde staat worden opgeslagen (verderop komen we hier nog op terug) en moeten developers de features waar ze aan werken zo opdelen, dat er op elk gewenst moment een release plaats kan vinden. Hier komt de werkwijze van “Continuous Integration” om de hoek kijken. De omgeving is hierbij zo ingericht dat alle geschreven programmeercode voortdurend (automatisch) wordt getest. Daarnaast kan er geen applicatie worden gereleased op een testomgeving wanneer er testen zijn die niet slagen. Continuous Integration is een voorwaarde om “Continuous Deployment” mogelijk te maken. Bij Continuous Deployment vindt het proces van automatisch deployen en releasing plaats.
Waarom Continuous Deployment?
Er zijn een aantal redenen waarom Continuous Deployment kan bijdragen aan de kwaliteit van maatwerksoftware:
- Het biedt de mogelijkheid om vaker een nieuwe release uit te brengen,
- Het creëren van de mogelijkheid om eerder feedback te krijgen. Zo kan er vervolgens, indien nodig, snel worden bijgestuurd.
- Het biedt een omgeving die het mogelijk maakt om experimentele functionaliteiten uit te proberen in een productie-omgeving,
- Het doorvoeren van bug-fixes kan sneller gedaan worden,
- Sneller reageren op onvoorziene problemen (calamiteiten),
- De kleinere Release Cycles zorgen voor minder risicovolle deployments,
- Het uitvoeren van deployments kost minder effort omdat het automatisch gebeurd.
Wat is er nodig om Continuous Deployment mogelijk te maken?
Voor het succesvol invoeren van “Continuous Deployment’ zijn er aantal criteria die je als IT-organisatie op orde moet hebben. We noemen de belangrijkste:
Infrastructuur
Er moet een infrastructuur zijn die het mogelijk maakt om de werkwijze van Continuous Deployment te volgen. De volgende onderdelen zijn hier belangrijk:
- Versiebeheer(systeem). Dit is een systeem waarbij de programmeercode met volledige historie wordt opgeslagen. We kunnen eigenlijk wel stellen dat een developer niet zonder een versiebeheersysteem kan. Zeker wanneer er gewerkt wordt aan grote projecten of teams is het gebruik van dergelijk systeem onmisbaar. Voorbeelden van versiebeheersystemen zijn Git en Mercurial.
- Continuous Integratie-servers (CI-servers). Hier worden alle automatische testen gedraaid. De CI-server dient gekoppeld te zijn met het versiebeheer systeem. Wanneer door de developer nieuwe code wordt ingediend in het versiebeheersysteem, zal de CI-server deze code ophalen en gaan testen. De CI-server kan ook zo worden ingeregeld dat deze de deployments uitvoert. Dit zijn automatische processen.
- Monitoring. In een eerdere blogpost schreven we al dat monitoren een belangrijk onderdeel is voor een supportafdeling als het gaat om het beheer van een applicatie. Ook in de context van Continuous Deployment is monitoring een essentieel onderdeel. Omdat de software aan verandering onderhevig is, is het belangrijk om in geval van problemen of calamiteiten zo snel mogelijk op de hoogte te worden gesteld.
Cultuur van samenwerken
Naast de infrastructuur, is de cultuur binnen een organisatie ook een belangrijk onderdeel voor succesvol Continuous Deployment.
- Vertrouwen. Er moet een hoog vertrouwen zijn in developers en tussen developers onderling,
- Codereview. Elke stukje geschreven programmeercode moet worden gereviewed door een collega-developer (en dus niet alleen door een QA of teamlead). Codereviews vermindert niet alleen de kans op bugs, maar zorgt ook voor een kennisoverdracht en is het een leerzame exercitie die een developer een level up kan brengen.
- Betrokkenheid. Betrek developers ook bij een productie-omgeving. Ook tijdens het development-proces is het belangrijk dat een developer gebruik maakt van productie-data zodat de functionaliteit ook wordt getest in een uiteindelijke situatie. Een goede samenwerking tussen developers en een supportteam is hierbij essentieel. De over de schutting gooien-mentaliteit zal hierdoor afnemen (mocht deze aanwezig zijn). In geval van calamiteit is het dan vaak ook geen probleem om hulp te vragen aan een developer.
Test everything!
Testen is cruciaal voor het mogelijk maken van Continuous Deployment. Idealiter zou iedere developer in staat moeten zijn op ieder moment elk stukje code van de applicatie te kunnen testen. We hebben in een vorige blogpost al eens geschreven waarom het schrijven van testen zo belangrijk is. We maken hier onderscheid in de volgende soorten testen:
- Unit tests. Dit is programmeercode om productiecode te testen. Deze tests worden geschreven door een developer tijdens het programmeren zelf. Deze testen kunnen automatisch worden uitgevoerd en gaan over specifieke onderdelen van de applicatie. Vaak worden hier uitzonderlijke situaties getest. Bijvoorbeeld wat gebeurt er wanneer een bepaalde tekst in een applicatie uitzonderlijk lang is. Denk hier hierbij aan een formulier waar een gebruiker een achternaam invult van 100 tekens.
- UI tests – of top-down tests. Hier dient onderscheid gemaakt te worden in handmatig en automatisch testen. Met UI tests wordt bedoelt het testen van de interface die de gebruikers ook te zien krijgen. Een balans tussen handmatig en automatisch testen is belangrijk. Als het bijvoorbeeld gaat over puur visuele onderdelen dan is soms handig om hier testscenario’s voor te maken, die handmatig getest kunnen worden.
Zijn er nog meer zaken waar je rekening mee houden bij Continuous Deployment?
Onderstaande zaken horen niet echt thuis in het rijtje hierboven, maar zijn zeker de moeite waard om te benoemen:
- Zero Downtime Deployments. Zorg dat je deployments zero-downtime zijn. In sommige gevallen kan het zijn dat er meerdere keren per dag wordt gedeployed. Je wilt dan niet iedere keer gebruikers confronteren met downtime of een applicatie die (tijdelijk) niet werkt.
- Feature flags en geleidelijk uitrollen van features. Denk hierbij aan de mogelijkheid om een feature aan- of uit te kunnen zetten in een productie-omgeving. Dit kan zijn voor een grote feature die nog niet helemaal is afgerond en pas deels in productie staat. Maar het kan ook gaan over een grote upgrade waarbij niet gewenst is dat alle gebruikers na een deployment deze meteen allemaal gaan gebruiken. Soms is het wenselijk dat een nieuwe feature uitsluitend wordt ‘open’ gezet, voor een groep (beta-test) gebruikers.
Heb je zelf ervaring met Continuous Deployment? Deel je ervaringen in de comments en discussieer mee!
Vragen?
Heb je vragen naar aanleiding van dit artikel? Neem gerust contact met ons op!
(of stuur een bericht)+31 495 430 798
Joost Saanenstuur bericht