Verschillende partijen in de Nederlandse markt zijn zo’n 10 jaar geleden gestart met TIBCO als integratie platform. Een platform dat in die jaren een steeds groter en belangrijker deel van het IT landschap is gaan vormen. Gecombineerd met een agile aanpak en een kort cyclische release cyclus in de vorm van sprints van twee tot drie weken, heeft dit gezorgd voor steeds complexer wordende processen rondom releasemanagement, versiebeheer en (de overdracht richting) beheer.

Ondanks de groei in systeemintegratie componenten is het release-proces vaak voor het overgrote deel handmatig gebleven. Code wordt ingecheckt in een versiebeheer omgeving (zoals bijvoorbeeld SVN of GIT), maar vervolgens moeten de installpacks, release notes en configuratiebestanden per omgeving handmatig worden opgesteld ten behoeve van het delivery proces. Dit handmatige proces kost niet alleen veel tijd, maar is tevens erg foutgevoelig: het betekent voor de beheer teams van de klant dat alle aangeleverde installpacks gedetailleerd gecontroleerd moeten worden. Daarnaast gebruiken de beheer- en de ontwikkelteams vaak ook nog een eigen versiebeheer omgeving en daarmee is het delivery proces overmatig complex. Tot slot ontbreekt het (in veel gevallen) aan automatische unittesten om de kwaliteit van de code te valideren. Dit alles koste elke oplevering zoveel tijd, dat er vaak geen mogelijkheid meer is hier een structurele verbetering in aan te brengen. Deze vicieuze cirkel moet en kan worden doorbroken…

Hoe de implementatie van Continuous Integration de oplevering binnen het Agile proces aanzienlijk verbeterde

Oplossing

Vanuit een sterk besef tot innovatie, en de aanwezige noodzaak tot verbetering, heeft Rubix voor verschillende klanten een proof-of-concept uitgevoerd, waarmee inzichtelijk werd welke verbeteringen in het release-proces te behalen zouden zijn voor development en beheer. Het doel van die PoCs is in korte tijd aantonen dat het inzetten van Continuous Integration & Continuous Delivery (CI/CD) principes oplossingen bieden voor de voorliggende problematiek. Als resultaat van die PoCs heeft Rubix het zogenaamde JAAS-framework (Jenkins/Ant/Artifactory/Subversion) opgezet en als herhaalbaar concept toegepast. Dit JAAS-framework is modulair uit te breiden en biedt tevens ondersteuning aan het oude release-proces van de klant. Het doorloopt de volgende stappen (ook wel Build Pipeline genoemd in CI/CD termen):

  1. De developer meldt het component aan voor de Build Pipeline (tijdelijke stap). Hiermee wordt de versionering van het component op alle locaties, ook in de source code, geeffectueerd.
  2. Iedere code check-in (bijvoorbeeld gevalideerd met commit-hooks van de bijbehorende versiebeheer omgeving) op een component triggert de build (na tagging) en validatie van de EAR.
  3. Per omgeving worden voor de EAR de deployment XMLs gegenereerd, met de omgevings-specifieke globale variabelen, machine- en runtime-settings.
  4. De artifacts worden opgeslagen in Artifactory: de artifact repository waarin alle binaries en configuratiebestanden in worden opgeslagen.
  5. De EAR wordt gedeployd naar de remote O-omgeving.
  6. Automatische testen (smoke/unit/sanity testen) worden op de ontwikkelomgeving uitgevoerd.
  7. Rapportages worden aangemaakt (release notes, testresultaten).

Oude werkwijze

Build-artifacts kunnen ook nog worden ingecheckd in de bestaande versiebeheer omgeving om bijvoorbeeld de oude werkwijze nog te kunnen ondersteunen. Dit heeft als voordeel dat de nieuwe CI/CD oplossing het oude release-proces niet verstoort en gefaseerd ingevoerd kan worden, met een mogelijkheid tot fallback.

Deployments vanuit beheer

Een versiebeheer tool zoals Subversion wordt bijvoorbeeld door de Rubix macrodefinitie ant-library ondersteund en blijft daarmee de basis van version-control en de buildstreet. Build-artifacts, source code archieven (in ZIP formaat) en andere release-deliverables worden opgeslagen in Artifactory. Door middel van handmatige, dan wel automatische, promoties binnen Artifactory doorloopt een artifact een traject van snapshot, naar pre-release, naar pre-release-deployed, naar release-repository. Vanuit deze laatste repository kan het artifact vervolgens gepushed worden naar de beheerorganisatie. De promotie naar pre-release-deployed is de start van een tweede pipeline: de EAR-file wordt remote gedeployed naar de T-omgeving in het aangewezen deployment-window. Hierna kunnen de geautomatiseerde integratie-tests voor T worden gedraaid. Ten behoeve van rapportage-doeleinden kan bijvoorbeeld worden gekozen om Solr in te zetten als json-document-server. Alle informatie uit Subversion, het buildproces en Artifactory is beschikbaar en gelinked in Solr, met een export naar keuze in bijvoorbeeld HTML, plain-txt, JSON en XML.

Resultaat

Door het toepassen van CI/CD, worden niet alleen heel veel handmatige, foutgevoelige en tijdrovende stappen geëlimineerd, maar wordt tevens de aansluiting en samenwerking met de beheerorganisatie sterk verbeterd. Een simpele aanpassing die voorheen al snel 15 minuten duurde, met een doorlooptijd van uren, kan nu in enkele minuten worden uitgerold. Dit is de tijd die na de commit in versiebeheer omgeving nodig is om het geheel getest op de T-omgeving te krijgen. Het is zelfs mogelijk zijn om binnen enkele minuten software geautomatiseerd op de productie-omgeving te implementeren.

Omdat de build en deployment van de artifacts geautomatiseerd gebeurt, is de kans op conflicten tussen teams veel kleiner en hoeft men niet meer continu rond te vragen wie er eventueel nog meer aan hetzelfde component aan het werken is. Deployments zitten elkaar hierdoor niet meer in de weg, kunnen worden gecombineerd en zijn efficiënter, wat de beschikbaarheid van de omgevingen verhoogt. Uiteindelijk scheelt dit naar schatting al snel twee dagen per ontwikkelaar per sprint (van 15 werkdagen), tijd die ontwikkelaars nu kunnen besteden het opleveren van extra functionaliteit. Inmiddels is bij verschillende klanten deze werkwijze ook werkelijk in gebruik genomen inclusief de tijdens de PoCs gerealiseerde framework, bijbehorende scripts en tooling.

Toekomst

Om Continuous Integration & Continuous Delivery verder in de organisatie te implementeren kunnen ook andere componenten toegevoegd worden binnen deze oplossing. Omdat over het algemeen niet alle requirements bij de start van de implementatie van CI/CD bekend zijn, is het framework zodanig opgezet dat het toekomstige ontwikkelingen in het release-proces niet zal blokkeren. Hierdoor zijn er nog verschillende uitbreidingen mogelijk. Zo kan gedacht worden aan een optie voor testers, waarmee ze kunnen aangeven dat een bepaalde versie akkoord bevonden is om vervolgens een volgende versie te activeren op hun omgeving. Ook andere software dan adapters gerealiseerd met TIBCO BusinessWorks kunnen in dit concept worden meegenomen, zo kan bijvoorbeeld gedacht worden aan TIBCO iProcess, deze technieken worden regelmatig gecombineerd in een oplossing. Tevens opent het deuren naar een verdere toepassing van dependency management, zodat de relatie tussen verschillende aanpassingen ten behoeve van eenzelfde change beheerd en gecontroleerd live gebracht kunnen worden. 

Houd jij je kennis graag up to date?

Mis niets meer van onze kennisdocumenten, events, blogs en cases: ontvang als eerste het laatste nieuws in je inbox!

Fijn dat we je op de hoogte mogen houden!