GitLab CI, Behat, Docker en nog meer!

Druplicon Behat

GitLab CI, visuele regressietests, Behat tests, automatische security updates, Docker en nog meer!

GitLab is een populaire open source variant op GitHub en BitBucket. In nieuwere versies is GitLab uitgebreid met Continuous Integration. Dit opent een wijd spectrum aan mogelijkheden voor de automatisering van verschillende processen die bij web development horen. Deze mogelijkheden hebben wij meteen aangegrepen en we hebben ontdekt dat we er unieke oplossingen mee kunnen ontwikkelen op het gebied van geautomatiseerd testen en deployen van nieuwe code.
In dit artikel lichten wij hier een paar van deze processen uit, die wij voor een opdrachtgever aan het ontwikkelen zijn en ons inziens een aanzienlijke vooruitgang in de workflows opleveren. Samengevat zijn dit:

  • Automatische deployments
  • Automatisch controle op code standaarden via de GitLab CI
  • Behat testen in de GitLab CI
  • Automatische visuele regressietesten met Wraith via de GitLab CI
  • Automatisch genereren van merge requests voor Drupal security updates
  • Tests in Docker

Automatische deployments

Voor de deployments naar de verschillende test-, acceptatie- en productieomgevingen (de 'OTAP', zie: Wiki OTAP maakten wij initieel gebruik van Beanstalk, maar vanwege de afhankelijkheid van externe diensten en het feit dat het een betaalde dienst is, zijn wij overgestapt naar Jenkins die ook op een eigen server draait. Ondanks het feit dat beide diensten goed functioneren zijn waren wij meteen enthousiast toen wij de mogelijkheid ontdekten om Continuous Integration in te zetten in GitLab. Wij stelden onszelf ten doel een Continuous Integration oplossing in te richten die ervoor zorgt dat alles wat wij opleveren voldoet aan de geldende standaarden en de kans op regressie minimaliseert. Dit in combinatie met een gedegen Git strategie zorgt ervoor dat veel taken zijn geautomatiseerd en daarmee de kans op menselijke fouten in veel procesfasen uitsluit.

Hoe werkt het?

Het team werkt met een Git strategie die grotendeels gebaseerd is op het Git model dat beschreven is op deze pagina: nvie.com/posts/a-successful-git-branching-model. Deze strategie heeft in de developerswereld een breed draagvlak en wordt door veel serieuze ontwikkelingsbedrijven toegepast. Met kleine wijzigingen in de strategie hebben wij dit model geïntegreerd met de deployments, waarbij de deployments door verschillende gebeurtenissen in Git in werking worden gezet. Hieronder volgt een aantal van deze gebeurtenissen en de reacties in het deploymentproces:

Aanmaken van een release branch. Wanneer alle gewenste nieuwe functionaliteiten of wijzigingen zijn ontwikkeld op de develop branch, wordt een release branch gemaakt. Zodra deze met een push in de GitLab repository terechtkomt, wordt een deployment in werking gezet die de code in de release branch uitrolt naar de testomgeving.
Nieuwe commit in release branch. Na het testen van de nieuwe release kunnen nieuwe commits worden toegevoegd om fouten te verhelpen of zaken te veranderen. Ook deze commits stellen een nieuwe deployment naar de testomgeving vanaf de release branch in werking.
Nieuwe commit op de master branch. Omdat de acceptatieomgeving altijd een exacte replica moet zijn van de productieomgeving wordt doorgaans alleen uitgerold naar de acceptatieomgeving vanaf de master branch. Hiervoor wordt soms een uitzondering gemaakt als urgente wijzigingen getest moeten worden op hun impact op de productiesite.

In GitLab kunnen deze gebeurtenissen en de daardoor in werking gestelde deployments eenvoudig worden ingesteld in haar ingebouwde Continuous Integration. Hoe dat ingericht kan worden, wordt door GitLabs eigen documentatie goed beschreven: about.gitlab.com/gitlab-ci.

Tests op code standaarden, visuele regressietests en Behat tests

Behalve het uitrollen van nieuwe code kan GitLab nog meer taken uitvoeren en daardoor wordt het opeens een stuk interessanter. Zo kan GitLab een controle over de code instellen (zoals Drupal coding standards) en kunnen de databases en bestanden gesynchroniseerd worden tussen de verschillende OTAP-omgevingen. Dit laatste komt weer ten goede aan de automatische tests, die eveneens door GitLab worden uitgevoerd. Op het moment gebruiken wij hiervoor de visuele regressietest-tool Wraith en de behaviour driven test-tool Behat. GitLab kan zodanig ingesteld worden dat als er een visueel verschil ontstaat, de deployment afbreekt en schermafbeeldingen gemaakt worden die na de automatische test vergeleken kunnen worden. Ditzelfde geldt voor behaviour driven tests. In dit geval kunnen ook acties van gebruikers op de website worden gesimuleerd en getest worden of deze de vooraf ingestelde resultaten teweegbrengen. Een paar voorbeelden van verschillende stappen in het GitLab Continuous Integration systeem:

  • Controle op coding standaarden op elke commit
  • Kopiëren van de database van de productieomgeving naar de acceptatieomgeving bij een commit op de master branch
  • Kopiëren van de database van de productieomgeving naar de testomgeving bij een commit op een release branch
  • Kopiëren van mediabestanden en documenten van de productieomgeving naar de acceptatieomgeving bij een commit op de master branch
  • Kopiëren van mediabestanden en documenten van de productieomgeving naar de testomgeving bij een commit op een release branch
  • Automatisch uitvoeren van database updates
  • Automatisch uitvoeren van regressietests na een deployment naar de acceptatieomgeving. Hiermee kan vastgesteld worden of een nieuwe release geen visuele regressie ten opzichte van de productieomgeving teweegbrengt.

Automatische merge requests voor Drupal veiligheidsupdates

Wij ontwikkelen doorgaans in Drupal en aanverwante systemen en daar hoort het ook het uitrollen van veiligheidsupdates bij. Deze komen in de regel altijd op woensdagavond uit. Voor een opdrachtgever hebben we nu een stap in het GitLab Continuous Integration proces gebouwd waarmee elke dag gecontroleerd wordt of er nieuwe veiligheidsupdates zijn die voor één van de sites in ons beheer van belang zijn. Als dit het geval is, maakt GitLab hier vanzelf een merge request voor die de volgende dag meteen gecontroleerd kan worden. Wordt deze geaccepteerd, dan handelt GitLab ook de volgende stappen af.

Docker in de GitLab CI

GitLab kan ook Docker instances bouwen waarmee tests op verschillende virtuele omgevingen kunnen worden uitgevoerd. Een Docker instance is een virtuele serveromgeving waarin verschillende versies van serversoftware kunnen worden geïnstalleerd, waardoor het gedrag van websites en applicaties op verschillende omgevingen kan worden getest. In onze Continuous Integration wordt Docker gebruikt om de Behat tests uit te voeren en de veiligheidsupdates te testen, voordat ze überhaupt toegepast worden op de bestaande omgevingen. Het is alsof een nieuwe kopie van de website gelanceerd wordt met de nieuwe wijzigingen, die vervolgens getest wordt om te kijken of alles nog goed blijft functioneren. En dit alles volledig automatisch.
GitLab CI levert voor ons tools die ons dagelijks werk veel efficiënter maakt en de klant de garantie bieden dat zijn/haar product stabiel blijft en voldoet aan de kwaliteitseisen. De toekomst belooft alleen nog maar meer innovatieve en spannende oplossingen!

Meer nieuws