Kwaliteitsborging en transparantie door CICD bij een overheidsbedrijf

Deze overheidsinstelling maakt gebruik van meerdere cloud applicaties. Deze applicaties communiceren met elkaar via honderden Tibco services en een Tibco Enterprise Service Bus. Doordat er in de afgelopen jaren meerdere applicaties zijn bijgekomen is het aantal services explosief gegroeid. Het CICD framework is echter niet meegegroeid en gekozen tools werden niet ten volste benut.

Meerdere uitdagingen door achterblijvende ontwikkeling CICD Framework

Commits niet inzichtelijk door stijging services

Door de achterblijvende ontwikkeling van het CICD framework zijn er meerdere uitdagingen ontstaan. Software artifacts werden tot op heden allemaal opgeslagen in een artifact repository en kregen altijd versienummer 1.0 (en werden dus overschreven indien al aanwezig). Door de flinke stijging van het aantal verschillende services (en artifacts) bleek het moeilijker te achterhalen in welke commit een bepaalde functionaliteit was geïntroduceerd.

Rollbacks naar oudere versies niet efficiënt

Dit vermoeilijkte ook het uitvoeren van een rollback. Alleen de meest recente versie stond in de artifact repository. Oudere versies moesten opnieuw worden gebouwd op basis van hun commit. Het nieuwe CICD framework moest beschikken over een transparant versiebeheer dat het deployen en terugdraaien van deployments een fluitje van een cent moet maken.

Kosten van ‘Closed Source’ CICD oplossingen hoog

De kosten van de gebruikte commerciële CICD tools werden als erg hoog ervaren. Eén van eisen aan de oplossing was dan ook om zoveel mogelijk gebruik te maken van open source oplossingen.

Geen transparante documentatie

Een andere oorzaak van het uitblijven van verdere CICD ontwikkeling is dat het proces niet transparant was. Slechts een kleine groep mensen was op de hoogte van hoe de vork in de steel stak, maar veel te druk met kerntaken zoals het ontwikkelen van nieuwe Tibco services. Het op te leveren proces moest transparant en eenvoudig uit te breiden zijn inclusief heldere documentatie.

De oplossing: Open Source en flexibiliteit

Open Source software

Vanwege de flexibiliteit en aanpasbaarheid is in de implementatie gekozen voor Jenkins als build server, Nexus als artifact Repository en Gitlab CE als source code management. Jenkins is open source, Nexus en Gitlab hebben een open source versie. Installatie van de software is versimpeld door de applicaties in containers te draaien en middels docker-compose op te starten.

Versionering en releaseproces

De eerste stap naar het toepassen van versionering is over het proces praten. Hoe ziet het ontwikkelproces eruit en welke omgevingen worden er gebruikt? Welke veiligheidseisen zijn er? Door wekelijkse demo’s en het verzamelen van feedback, hebben we een eerste voorstel uitgewerkt. Een groot verschil met de originele situatie is de introductie van niet één, maar twee artifact repositories. Een snapshot repository en een release repository. Snapshots zijn artifacts in ontwikkeling, draaiende in DEV- en TEST-omgevingen. Releases zijn artifacts die op basis bepaalde kwaliteitseisen gepromoveerd zijn naar de release repository. Op basis van de laatste testresultaten kan worden besloten om het artifact naar Productie over te zetten.

Snapshots krijgen een versienummer dat bestaat uit een Jenkins buildnummer en een commit hash uit Git (e.g. b4-1d5fe532). Elke commit op master vuurt middels een webhook een Jenkins build af die het artifact bouwt en in de Snapshot repository plaatst met bijbehorend versienummer. Elk Snapshot is op dit moment te herleiden naar een commit, en daardoor is eenvoudig te zien welke functionaliteit is toegevoegd. Snapshots kunnen alleen naar DEV en TEST omgevingen worden overgezet. Een artifact moet gereleased worden om op UAT en PROD te landen. Met een release krijgt het artifact een versienummer (x.y.z).

Transparant en flexibel framework

Binnen Jenkins maken we veelvuldig gebruik van shared libraries. Alle service-onafhankelijke logica leeft in één repository en is daardoor makkelijk uit te breiden en te onderhouden. Alle pipelines kunnen deze libraries toepassen.

Binnen de shared libraries maken we gebruik van Groovy objecten. Voorbeelden zijn een Nexus klasse die verwijst naar een Nexus installatie en een NexusComponent subklasse die verwijst naar een specifiek artifact. Dit maakt interacties met Nexus in een pipeline eenvoudig. Het up- of downloaden van een artifact kan dan worden gedaan door deze te instantiëren en dan de methode aan te roepen:

def n = new Nexus(this, globalVars.nexusUrl)
def nc = new NexusComponent(n, “myRepository”, "myGroupId", "myArtifactId")

n.download(nc)
n.upload(nc)

Op deze manier is het eenvoudig om bepaalde acties toe te voegen en toch af te schermen voor de gebruiker. Het uitvoeren van bijvoorbeeld een SHA1 check op de artifacts wordt bij elke download gedaan, maar de gebruiker merkt dit alleen als er geen match is. In het geval van een match is het gedownloade artifact identiek aan het artifact dat zich in de repository bevindt en kan je er zeker van zijn dat er geen code is toegevoegd.

Op dezelfde manier is het eenvoudig om een Tibco service te starten op een omgeving:

Def tibcodeploy = new Tibcodeploy(this, "myEnvironment", "appName")

tibcodeploy.uploadApp("myApplicationFile")
tibcodeploy.deployApp("myApplicationName")

Conclusie: een traceerbaar en transparant software-ontwikkelingsproces

Door het implementeren van een tweede artifact repository, het toepassen van open source en duidelijke versionering is de traceerbaarheid van software en transparantie van het proces verbeterd. Rollbacks kunnen met een druk op de knop worden uitgevoerd en duren minuten in plaats van uren.