The road to Continuous Integration / Deployment

Innovatie
12 december 2018
CI/CD biedt veel voordelen voor de klant en de ontwikkelaars. Een snellere time to market en vooral een efficiënter en minder foutgevoelig ontwikkelproces.

Continuous Integration (CI) / Continuous Deployment (CD) biedt veel voordelen voor de klant en voor ons als ontwikkelaars. Een snellere time to market maar vooral een efficiënter en minder foutgevoelig ontwikkelproces. 

Er zijn veel tools beschikbaar om dit proces te ondersteunen. In dit artikel leg ik onze strategie uit en motiveer ik onze toolkeuze.

Wat is het?

Continuous Integration (CI) is een methodologie waarbij ontwikkelaars op geregelde basis hun software aanpassingen met elkaar integreren. Het doel hiervan is integratieproblemen zo snel mogelijk aan het licht krijgen.

Een aantal belangrijke principes om tot CI te komen:

  • alle code in een versiebeheer tool
  • een automatisch build om de integratie omgeving bij te werken - deze build moet erg snel zijn zodat problemen snel vastgesteld en opgelost kunnen worden en de integratie omgeving moet een - naar beneden geschaalde - kopie van productie zijn
  • een build moet ook testen opstarten om de kijken of de geïntegreerde versie voldoet
  • elke commit moet leiden tot een build
  • iedereen kan het resultaat van een build zien
  • Continuous Delivery (CD of CDE) is een methodologie met als doel het sneller opleveren van software, op elk gewenst moment. Bij Continuous Deployment (CD) gebeurt dit volledig geautomatiseerd.

De benefits van CI/CD

Medio 2016 zijn we gestart met onze zoektocht naar een goede CI / CD strategie voor een Oracle database - Oracle APEX (webapplicaties) architectuur met een ondersteuning voor legacy systemen als Oracle Forms, Oracle Reports en Pro*C batch programma's.

Overstappen op CI / CD doe je natuurlijk niet omwille van de technische uitdaging (mmm ... helpt wel :-) ) maar vooral omwille van de benefits voor de klanten en AXI zelf. Een aantal benefits voor de klant:

  • Kortere time-to-market
  • Automatisch i.p.v. manueel dus minder fout-gevoelig
  • Lagere implementatiekost

Een aantal benefits voor AXI zelf:

  • Proces efficienter maken (proces innovatie)
  • Output kwalitatief beter maken
  • Minder "saaie" installatie taken
  • Beter overzicht: welke versie draait bij welk klant?

Benefits zoals kortere time-to-market passen ook perfect in de keuze die we samen met onze klanten maakten om over te stappen op een Agile / SCRUM manier van werken, met twee- of driewekelijkse sprints waarbij vaak DevOps (het samenvoegen van beheerstaken en ontwikkeling) wordt toegepast. Hierbij worden dagelijks de user stories (gebruiker X doet taak Y om tot Z te komen - met bijhorende context en acceptatie criteria) overlopen en wordt op het einde van een sprint een demo gegeven van de tijdens de sprint ontwikkelde deelproducten, gevolgd door een retrospective, een terugblik op de voorbije sprint (vnl. op het proces).

Na een lange zoektocht zijn we uitgekomen op volgende strategie:

Ontwikkeling van het datamodel (Oracle SQL), bussiness logica (Oracle PL/SQL) en de UI (Oracle APEX) gebeurt in onze eigen tools / Oracle APEX builder (web editor) en komt samen in Visual Studio Code. In deze editor wordt ook a.d.h.v. Liquibase changelog bestanden (XML) vastgelegd welke database scripts in welke volgorde uitgevoerd moeten worden. Dit alles wordt gecommit naar de versiebeheer tool Atlassian Bitbucket.

Deze ontwikkelcyclus gebeurt parallel per user story. Zodra de user story klaar is, wordt deze toegevoegd (via merge) aan de dev branch waarop de Jenkins build server de aanpassingen doorvoert op de CI (integratie) omgeving. Op deze omgevingen worden dan de units tests uitgevoerd, welke in de SonarQube QA tool gevisualiseerd worden, samen met een statische analyse van de code. Deze analyse kijkt naar code duplicaties, patronen die op fouten kunnen wijzen, code verbeteringen, etc. Op basis van deze rapportage kan je - indien nodig - nog verbeteringen aan de user story doorvoeren waarop de cyclus zich herhaalt.

Op het einde van de sprint wordt er bepaald welke user stories naar de SIT, UAT en tenslotte productie omgeving mogen gaan. Deze user stories worden via push requests (in Bitbucket) doorgezet naar de SIT branch waar deze via merge toegevoegd worden. Deze merges resulteren in een installatie op de SIT omgeving door de Jenkins build server.

Motiviatie toolkeuze

Jenkins

In dit verhaal is de centrale component, de linking pin, Jenkins build server. Waarom Jenkins? Hier zijn verschillende redenen voor: de zeer eenvoudig op te zetten, heel goede ondersteuning van parallelle ontwikkeling (Jenkins pipeline), maar vooral de enorme community achter dit open-source product en enorme user base, bekijk bijvoorbeeld deze link.

Liquibase

Deze tool is cruciaal voor een versiebeheer op database objecten. Met deze tool beheer je de volgorde van uitvoering van database scripts (per type - tabel, view, ...), of scripts bij wijziging opnieuw uitgevoerd moeten worden en welke scripts reeds uitgevoerd zijn op een omgeving. Voor deze tool hebben we gekozen enerzijds op aanraden van partner Jidoka, maar anderzijds ook op basis van tips van Oracle Apex experten in het boek Expert Oracle Application Express.

Bitbucket

Bitbucket wordt gebruikt als versiebeheer repository, waarbij onderliggend gebruik wordt gemaakt van de Git technologie. Hiervoor is gekozen omdat Bitbucket het toelaat om private repositories op te zetten, heel breed ingezet wordt in de markt, een intuitieve UI aanbiedt maar ook omdat deze al veelvuldig werd gebruikt binnen de organisatie. Daarnaast heeft Git het grote voordeel dat deze parallelle ontwikkeling toelaat waarbij alle ontwikkelaars in een agile / Scrum context - los van elkaar - aan hun eigen (of gedeelde) user stories kunnen werken. Zodra de ontwikkelaar klaar is met een stuk ontwikkeling kunnen zijn lokale aanpassingen doorgezet (gepushed) worden naar de centrale repository.

utPLSQL

utPLSQL is het test framework dat we gebruiken voor het testen van de business logica in Oracle PL/SQL. Onze keuze is hierop gevallen omdat dit framework conformeert aan industrie standaarden als JUnit en RSpec en daardoor heel eenvoudig te integreren is in de andere tools als Jenkins en SonarQube. Het framework laat toe om op een eenvoudige manier per test scenario te definiëren: a.) hoe de test dataset er moet uitzien, b.) welke test uitgevoerd moet worden en c.) wat het verwachte eindresultaat is.

Visual Studio Code

Als editor wordt gebruik gemaakt van Visual Studio Code, een multi-platform en open-source editor ontwikkeld door Microsoft, met ingebouwde Git-ondersteuning en een veelvoud aan extensies. Voor Oracle PL/SQL en APEX ontwikkeling maken we hierbij vooral gebruik van volgende extensies: Git Lens,Git File History, Language PL/SQL, Diff Tool en XML Tools. Voldoende redenen om deze als primaire editor te gebruiken wat ook onderschreven wordt door Oracle experts als Dimitri Gielis, Morten Braten e.a.

SonarQube

SonarQube wordt gebruikt als een QA rapportage tool, hiervoor hebben we gekozen na een onderzoek van een aantal verschillende tools. De Community Edition (CE) versie - welke gratis is - in combinatie met de open source PL/SQL plugin biedt al enorm veel mogelijkheden. Als je uitgebreidere analyses wilt doen van PL/SQL kan je overstappen op de commerciele versie van SonarQube.

Lessons learned

De belangrijkste les die wij in onze zoektocht geleerd hebben, is dat er een hele waaier aan tools beschikbaar is. Er is niet 1 tool die alle componenten goed afdekt. Vandaar onze keuze om voor ieder deelgebied een specialistisch product te kiezen. Bij het maken van een keuze zijn volgende stappen heel belangrijk:

  • Leg voor je zelf vast waar je naartoe wil, bijv. tweewekelijks software automatisch kunnen releasen.
  • Maak een inventarisatie van de huidige deployment stappen
  • Maak een inventarisatie van de mogelijke tools per deelgebied
  • Start klein - en werk fase per fase:
  • zet eerst je versiebeheer op poten
  • ga daarna nadenken over een branching strategie (git flow, environment branching, ...)
  • ga vervolgens op zoek naar een passende build tool
  • en richt branch na branch in, bijv. eerst ontwikkeling, dan je integratie omgeving, dan de testomgeving van de klant, de acceptatie omgeving van de klant en tenslotte de productie omgeving van de klant (i.g.v. environment branching).
  • Report this

Meer informatie? Contacteer Jan Smets
Senior Technical Team lead at AXI