Continuous Delivery

De websites die we bij Insyde bouwen worden steeds groter, complexer en door steeds meer bezoekers gebruikt. Downtime door bugs of bijvoorbeeld het online zetten van nieuwe functionaliteit wordt daarmee ook steeds meer kritiek. Reden voor ons om vol in te gaan zetten op Continuous Delivery.

Continuous delivery (CD) is wat ons betreft de heilige graal van software development. We willen er graag voor zorgen dat de ideeën van onze klanten zo snel mogelijk worden omgezet in een stabiele online oplossing. En dan niet alleen bij het opleveren van de eerste versie, maar ook bij het toevoegen van nieuwe functionaliteit. Het idee is, dat de software die je ontwikkelt op elk moment stabiel genoeg is om online te zetten.

Dit bereik je door korte cyclussen voor het ontwikkelen te gebruiken (meerdere korte sprints). Vervolgens moet zoveel mogelijk van het proces van testen en online zetten geautomatiseerd worden. De continuous delivery termen hiervoor zijn: automated testing, continuous integration en automated deployment.

Continuous delivery

Automated testing

Er zijn verschillende manieren om automatische testen te schrijven voor de programmeercode die je maakt. Er wordt hierbij meestal onderscheid gemaakt tussen zogenaamde unit testen en functionele testen.

Unit testen:

Als unit test schrijft de programmeur een aantal regels code die één bepaalde functie van een object uit het project aanroept met vastgestelde parameters. Vervolgens wordt gekeken of het resultaat van de functie overeenkomt met wat in de test als verwachte waarde wordt opgegeven. Als de waardes gelijk zijn, slaagt de test. Zo niet, dan faalt de test en moet de code aangepast worden. Je test zo dus kleine afzonderlijke stukjes code.

Functionele testen:

Bij een functionele test schrijft de programmeur een scenario dat bestaat uit verschillende stappen, waarmee een geheel stuk functionaliteit getest wordt. Er wordt een virtuele browser gestart waarin de applicatie geladen wordt. Vervolgens kan de programmeur in code commando’s geven om naar een bepaalde pagina te gaan en bijvoorbeeld een contactformulier in te vullen. Daarnaast kun je als programmeur bijvoorbeeld laten verifiëren of er bepaalde elementen op de pagina voorkomen (bijvoorbeeld een bedankttekst na het invullen van een formulier, of een foutmelding als een ongeldige waarde is ingevuld) of dat er een e-mail is verstuurd na het invullen. Op deze manier kun je dus een volledige module van het project testen.

Test driven development:

Als een groot deel van de functies en modules op deze manier getest kunnen worden, kun je als programmeur met een gerust hart nieuwe functionaliteit toevoegen of bestaande functionaliteit wijzigen. Als je vervolgens de testen draait, zie je vanzelf of er iets stuk is gegaan.

Om ervoor te zorgen dat een groot deel van de code automatisch getest kan worden, werken we bij Insyde volgens het test-driven development proces. Hierbij maakt de programmeur eerst een test voor de functionaliteit die hij moet maken. Uiteraard faalt deze test in eerste instantie, omdat er nog geen code is geschreven voor de functionaliteit. Vervolgens schrijft de programmeur de minimale code die nodig is om de test te laten slagen. Als de test slaagt, voert de programmeur een refactor slag uit, waarbij de code opgeschoond wordt tot onze hoge standaard. Het spreekt voor zich dat na de refactor de test ook nog moet slagen.

Wij gebruiken Codeception voor het definiëren en uitvoeren van beide soorten tests.

Continuous integration (CI)

Bij Insyde werken we vaak met meerdere programmeurs aan een complex project. Iedereen werkt op zijn eigen computer en wijzigt daar code. Het gevaar bestaat dan, dat mensen per ongeluk elkaars code stukmaken of dat mensen hetzelfde stuk code aan het wijzigen zijn. Om dat te voorkomen worden er in het continuous integration proces twee belangrijke onderdelen verplicht gesteld: versiebeheer en automatic builds.

Versiebeheer:

Bij Insyde gebruiken we Subversion. Per project is er een centrale versie (de trunk). Als iemand aan een project gaat werken, vraagt hij aan Subversion een kopie van de trunk die op zijn eigen machine wordt geplaatst (uitchecken). Op het moment dat de programmeur klaar is, stuurt hij het bestand terug naar Subversion (inchecken). Die kijkt dan of het bestand in de tussentijd nog door andere mensen is gewijzigd. Zo ja, dan probeert hij automatisch de wijzigingen te combineren (merge). Als dat niet lukt, geeft hij een conflict weer en moeten de programmeurs samen even kijken hoe de wijzigingen gecombineerd moeten worden. Op deze manier is er altijd één leidende versie van een bestand. Elke wijziging van elk bestand wordt in een aparte versie bijgehouden. Er is dus altijd terug te vinden welke wijzigingen door wie zijn gedaan.

Automatic builds:

Het maken van een build van de code betekent dat alle nieuwe code uit versiebeheer wordt gehaald. Daarnaast worden automatisch de database-aanpassingen en andere aanpassingen doorgevoerd die gedaan moeten worden om de code te laten draaien. Vervolgens worden alle automatische testen uitgevoerd. Als alles werkt, is de build geslaagd.

Continuous integration server met Jenkins:

Bij Insyde hebben we een aparte server ingericht als continuous integration server. Deze server draait zoveel mogelijk dezelfde software als de productie-omgeving waar uiteindelijk de projecten van onze klanten live komen te staan. Hierdoor kunnen we een zo realistisch mogelijk beeld krijgen van wat de code op de productie omgeving gaat doen. Daarnaast draait het programma Jenkins op deze server.

Als een programmeur code incheckt in Subversion, wordt er automatisch een bericht naar Jenkins gestuurd. Deze checkt vervolgens de code uit en draait automatisch alle testen die bij het project horen en kan kijken of de code aan de vastgestelde conventies voldoet. Als een build faalt (bijvoorbeeld doordat een van de testen faalt), wordt het team direct op de hoogte gesteld. Op een monitor is van alle projecten te zien wat de huidige status is (groen voor stabiel, rood voor fout).

We hebben nog een leuke plugin voor Jenkins draaien: de CI game. Hierbij krijgt een programmeur punten als hij goede code commit en (veel) strafpunten als hij de build doet falen. Insyders zijn behoorlijk competitief, dus een build laten falen is een no-go.

Automated deployment met Magellanes

Het online zetten van een nieuw project of nieuwe functionaliteit in een bestaand project bestaat uit veel kleine stapjes die doorlopen moeten worden (bestanden uploaden, database aanpassen, rechten aanpassen, etc). Een klein foutje of het overslaan van een stap kan ervoor zorgen dat de website of applicatie online niet meer bereikbaar is of niet goed werkt. Gelukkig is het een heel gestructureerd proces, wat betekent dat het goed geautomatiseerd kan worden.

Tijdens zijn stage voor Insyde heeft Joey onderzoek gedaan naar deployment tools. Uiteindelijk is de keuze gevallen op Magallanes.

Voor onze kwartaalupdates gebruiken we Magallanes inmiddels. Op de deploy server definiëren we in Magallanes, met PHP code, alle acties die gedaan moeten worden bij het online zetten: zorgen dat er een werkzaamhedenpagina wordt getoond, dat er een backup wordt gemaakt van de huidige versie, zorgen dat nieuwe en gewijzigde bestanden online gezet worden, zorgen dat de database wordt aangepast en zorgen dat er testen worden uitgevoerd. Als alles goed is gegaan, wordt de werkzaamhedenpagina weer uitgezet en is de vernieuwde site weer bereikbaar. Als er een stap faalt, wordt automatisch de backup teruggezet en gaan we uitzoeken wat er aan de hand is. Als dat opgelost is, wordt de procedure weer vanaf het begin doorlopen.

Geschreven door Job Kelderman

Hoofd ontwikkeling / eigenaar

Blijf up-to-date en ontvang updates in je mailbox

Lees ook deze interessante blogs

Kiezen van een webdesignbureau: waar moet je op letten?

Je wilt een nieuwe website en bent op zoek naar een goed webdesignbureau. In Nederland zijn er zeker honderd webdesignbureaus en een groot aantal ZZP’ers die websites maken. Allemaal pretenderen ze goed te zijn. Maar hoe scheid je het kaf van het koren en kies je een bureau die bij jouw organisatie past? Wij zetten 14 punten op een rij waar op je moet letten bij de keuze van een webdesignbureau.

Watervalmethode vs Scrum

Scrum is geliefd bij veel software-ontwikkelaars. Zo ook bij ons; wij houden echt van scrummen. Maar soms – heel soms – werken wij nog volgens de watervalmethode. Dit doen wij vooral bij projecten waarbij de projectleider aan de klantzijde geen beslissingsbevoegdheid heeft en elk stap aan een leidinggevende, het management of een stuurgroep moet worden verantwoord. Soms is de watervalmethode ook meer geschikt voor website waarop content centraal staat en al in een vroeg stadium...

Totaalpakket: grondig renoveren website, inclusief teksten en beelden

Het besluit is genomen: je wilt een nieuwe website voor je bedrijf. Dit besluit is meteen de startpunt van een reeks volgende beslissingen. Wat te doen met de content – foto’s en teksten – op de huidige site? Passen deze nog bij de nieuwe weg die je in wilt slaan? Of doen deze juist afbreuk aan de nieuwe website en de communicatieboodschap die je wilt uitdragen? En wat als nieuwe teksten nodig zijn: zelf schrijven of iemand anders? En zo ja, wie dan? Oftewel: keuzes,...

Wil je weten hoe wij werken?

We hebben al laten zien wat we hebben gemaakt. Wil je weten hoe we dat doen? Lees meer over onze werkwijze.