Continuous Integration & Continuous Delivery in de praktijk

blog

Een goedwerkende development workflow is één van de belangrijkste onderdelen voor een soepele en efficiënte samenwerking binnen een development team. En bovendien zorgt dit voor het beste en meest kwalitatieve resultaat voor de klant. Bij E-sites pakken we dit aan door de werkwijze Continuous Integration toe te passen. Hoe dat werkt in de praktijk? Jeroen en Jasper geven je een kijkje in de keuken bij E-sites in deze blog. Nieuwsgierig? Lees dan snel verder.

Wat is Continuous Integration (CI)?

Continuous Integration is een werkwijze waarbij aanpassingen aan de broncode van een project door verschillende developers periodiek worden samengevoegd tot één codebase; een verzameling broncode. De werkwijze zorgt ervoor dat er sneller en vaker aanpassingen aan een applicatie kunnen worden doorgevoerd, omdat er beter en op een agile manier wordt samengewerkt. Ook hier worden veranderingen in kleinere iteraties opgeleverd, in plaats van wachten op vaste release dagen. 

All-in-one oplossing GitLab bij E-sites

Om deze werkwijze te faciliteren is er een tool nodig die code opslaat. Er zijn veel verschillende tools en oplossingen beschikbaar. Zo is mogelijk om meerdere, opzichzelfstaande pakketten met elkaar te integreren of voor een all-in-one oplossing te kiezen. Uit de vele verschillende tools hebben we bij E-sites gekozen voor GitLab. GitLab is een all-in-one oplossing voor onder andere versiebeheer, deployment en geautomatiseerd testen en is de centrale spil in alles wat met de broncode van onze projecten te maken heeft. De tool gaat veilig om met code en heeft de mogelijkheid tot code review. Met een code review bekijk en keur je elkaars code (goed of af). In plaats van achteraf changes bekijken wanneer iets niet goed is gegaan, wordt de code gecontroleerd vóórdat deze in de applicatie komt. 

Efficiënt werken en kwaliteit waarborgen door GitLab

In versiebeheersysteem GitLab is het makkelijk om volgens het branching model te werken (zie afbeelding). Wanneer een nieuwe feature wordt ontwikkeld, maakt de developer een nieuwe branch (aftakking) van de develop-branch (de broncode van het project). Binnen deze branch maakt de developer aanpassingen aan de broncode, totdat de nieuwe feature is uitgewerkt. Vervolgens biedt de developer de branch ter controle aan bij andere developers uit ons team in de vorm van een merge request. Tijdens deze code review kijken onze collega’s onder andere naar:

  • kwaliteit en netheid van de code
  • mogelijke duplicaten in de code
  • heeft de code de juiste werking
  • aanwezigheid van (acceptatie)tests

Na de handmatige code review worden er nog diverse geautomatiseerde controles uitgevoerd. Denk hierbij aan bijvoorbeeld een controle op complexiteit, maximale regellengte, etc. Als één van deze tests faalt, dan is het niet mogelijk om de aanpassingen samen te voegen met de codebase van het project. Op deze manier weten we zeker dat de kwaliteit van de broncode altijd aan onze standaarden voldoet. Als de code review door onze teamleden is goedgekeurd en de automatische tests slagen, wordt de code samengevoegd met de codebase. 

Hoe werkt Continuous Delivery (CD)?

De aanpassingen zijn samengevoegd in de codebase, maar we zijn nog niet aan het einde van het proces. De code en dus de nieuwe features staan nog niet live. Voordat de code in de productieomgeving zit en daadwerkelijk zichtbaar wordt, doorlopen we de OTAP-straat. 

OTAP staat voor Ontwikkeling, Test, Acceptatie en Productie. Software doorloopt deze vier omgevingen tijdens het ontwikkelproces. Per omgeving bestaat er in ons versiebeheer een branch. Zodra de code samengevoegd wordt in één van deze branches, wordt er automatisch gepubliceerd naar de bijbehorende omgeving. Hieronder lichten we elke omgeving kort toe.

  1. 1

    Ontwikkelings-omgeving

    Developers ontwikkelen features in de ontwikkelomgeving. Deze omgeving draait alleen lokaal op de computers van de developers. Zodra een feature wordt goedgekeurd wordt deze samengevoegd met de codebase van het project en vervolgens automatisch gepubliceerd naar de testomgeving.

  2. 2

    Testomgeving

    De testomgeving is alleen voor door onze collega’s te benaderen. Hier komen alle aanpassingen samen die de developers hebben gedaan en kan het hele team (zowel developers als product owner) handmatige tests uitvoeren om te controleren of de opgeleverde features naar behoren functioneren. Ook wordt de aanwezige testsuite automatisch uitgevoerd. Tests geslaagd? De broncode wordt dan automatisch doorgezet naar de acceptatieomgeving.

  3. 3

    Acceptatie-omgeving

    De acceptatieomgeving is door onze klanten te benaderen en lijkt zoveel mogelijk op de productieomgeving, zodat de klant de nieuwe features kan testen en controleren. Geeft onze klant akkoord op de opgeleverde features? Dan wordt de code automatisch doorgezet naar de productieomgeving. 

  4. 4

    Productie-omgeving

    De productieomgeving is de laatste stap in het proces. Wanneer iedereen tevreden is, doet de developer het laatste verzoek om de aanpassingen van acceptatie naar productie te brengen. Oftewel deployen / live zetten van de aanpassingen. Zodra dat gedaan is, zijn de aanpassingen na een paar minuten zichtbaar!

Techniek in een vogelvlucht

De verschillende stadia die de broncode in een project doorloopt hebben we hierboven in een vogelvlucht beschreven. Binnen de Continuous Integration tool (GitLab) zijn dus zowel handmatige processen als code review geborgd. Daarnaast worden andere processen, zoals het uitvoeren van testsuites en deployment geautomatiseerd (zie een voorbeeld van output van een automatische test in de afbeelding hiernaast). Door al deze processen onder te brengen in één tool werken developers beter samen en is er veel grip op de uiteindelijke kwaliteit van de projecten die we opleveren.