CI/CD uitgelegd aan SALES

Binnen de IT wordt het snel en voorspelbaar leveren van nieuwe functionaliteit ‘CI/CD’ (Continuous Integration / Continuous Delivery) genoemd. CI/CD is lastig uit te leggen aan wie niet thuis is in de wereld van de softwareontwikkeling en beheer. Ik kwam erachter dat dit moderne IT-leveringsproces in veel opzichten te vergelijken is met het beter bekende offerte- of bidproces. Zeker bij organisaties die hun klanten willen voorzien van consistente en kwalitatieve aanbiedingen die op tijd worden uitgebracht. Ik zal dit uitleggen aan de hand van de CI- en CD deelprocessen, eerst vanuit de software- en daarna vanuit de offertewereld. En aangezien het CI/CD-proces door automatisering zeer effectief is, wanneer goed ingericht, geef ik onderweg enkele ideeën voor het verbeteren van het bidproces.

Continuous Integration (CI) - Integreren

Het doel van CI-activiteiten is zo efficiënt mogelijk toewerken naar één consistente oplevering (release). Omdat meerdere medewerkers tegelijk werken aan deelopleveringen die als consistent geheel (integraal) worden getest en opgeleverd, wordt gesproken over Integratie. Continuous Integration bestaat uit vijf fasen, plan, code, build, test en release, die vergeleken kunnen worden met het plannen, schrijven, bevriezen, reviewen en bundelen in het bidproces.

Plan - Plannen

‘Plannen’ bij CI/CD gaat allang niet meer over het droppen van activiteiten en mijlpalen in een projectteam. Het gaat vooral over het prioriteren van gewenste functionele en niet-functionele eisen van de klant. Het team schat in hoe complex het werk is en welke expertise noodzakelijk is om binnen een vastgesteld tijdvak resultaat te leveren. Dit werk wordt verdeeld over teamleden en (deel)oplevermomenten (sprints) van maximaal twee weken.

De start van het bidproces is vergelijkbaar. De klant en de vraag van de klant worden geanalyseerd en het werk wordt verdeeld over de leden van het bidteam. De bidmanager plant vaste (deel)oplevermomenten die maximaal twee weken uit elkaar liggen. Plannen is een continu proces met een eigen feedbackloop om de voorspelbaarheid van het team te verbeteren.

Geef in een agile bidteam de commercieel verantwoordelijke de rol van productowner en de bidmanager de rol van scrummaster.

Code - Schrijven

In een ontwikkelteam werken meerdere ontwikkelaars parallel aan het realiseren van nieuwe functionaliteit. De code die zij schrijven wordt bijgehouden in een gemeenschappelijk versiebeheersysteem (Git). Op een vaste plek één versie van de waarheid bewaren, is een absolute voorwaarde voor integratie.

Ook in een bidteam werken meerdere medewerkers simultaan aan een aanbieding. Bijvoorbeeld een projectleider, architect, accountmanager, service- of contractmanager en bidmanager. Zij verzamelen en schrijven teksten die uiteindelijk tot een geïntegreerde aanbieding leidt.

Gebruik ook in een bidteam een versiebeheersysteem voor veel gebruikte tekstfragmenten, templates en standaard rekenmodellen. De praktijk leert dat veel tijd verloren gaat aan documentmanagement en het herschrijven van teksten. Maak van de bidmanager een ‘Git-manager’.

Build - Bevriezen

Bouwen (build) door programmeren (code) wordt steeds minder gedaan. Ontwikkelaars modelleren en gebruiken herbruikbare componenten zoals bestaande diensten (API’s), programmabibliotheken (code libraries) en programmeerraamwerken (programming frameworks). Daarnaast gaat het niet alleen over functionele code, maar steeds meer over configuratiebestanden en scripts. Het bouwproces bestaat uit het samenstellen van zelfgemaakte en bestaande onderdelen in een herbruikbare en testbare eenheid (unit).

Ook binnen het bidteam wordt gebruik gemaakt van herbruikbare componenten. Denk aan een document template, een prijscalculatiemodel, een standaard contract, een product- en dienstencatalogus, etc. Het ontwikkelen en registreren van standaard bouwstenen heeft grote voordelen bij het samenstellen van de uiteindelijke aanbieding. Ik heb deze fase ‘bevriezen’ genoemd, omdat de essentie van het bouwproces de oplevering van herbruikbare (dus geteste) bouwstenen is. Ieder professioneel bidteam heeft een bibliotheek (repository zouden hun software collega’s zeggen) met standaard bouwstenen.

Probeer de documenten die samen de aanbesteding vormen vast te leggen in één configuratiebestand. En geef mij alsjeblieft een telefoontje als je de equivalent van een package manager hebt gemaakt: een tool die op basis van het configuratiebestand je aanbieding samenstelt!

Test - Reviewen

Een ontwikkelaar moet zijn opgeleverde en ‘bevroren’ bouwsteen testen, voordat deze kan worden opgenomen in de uiteindelijke oplevering. Dit testen vindt niet alleen plaats aan het eind van het build proces (unit test), maar ook tijdens het schrijven van code (code review) en op vele andere momenten in het leveringsproces. Zo zijn er integratietesten, securitytesten, loadtesten, acceptatietesten, testen voor specifieke gebruikersgroepen, etc. Binnen CI/CD wordt geautomatiseerd getest met moderne tooling.

In het offerteproces bestaan vergelijkbare reviewmomenten, alhoewel niet geautomatiseerd. Het doel is om de kwaliteit van de onderdelen en het geheel te borgen en op die manier een kwalitatief goede aanbieding te realiseren.

Plan de reviewmomenten op voorhand in en laat de reviewer vooraf beschrijven wat hij wil terugzien in de tekst. Kijk na de review in hoeverre dat is gelukt. Het bepalen van deze ‘coverage’ is een belangrijke graadmeter voor de kwaliteit van het opgeleverde werk en kan het reviewproces zelf steeds verder automatiseren.

Release - Bundelen

Wat de ontwikkelaar op onderdelen doet, gebeurt ook over alle op te leveren onderdelen (artifacts) van het team heen. Het eindresultaat van het CI-proces is een release. Deze release wordt via de leveringsprocessen (CD) geautomatiseerd opgeleverd aan de eindgebruiker. Het releaseproces vormt de brug naar de meer operationele processen.

Het bundelen van de op te leveren producten binnen het offerteproces wordt meestal door de bidmanager gedaan. Net als bij software is het samenvoegen (merge) van de totale aanbieding geen eenvoudige taak. Vooral het bewaken van de consistentie (denk aan woordgebruik, maar bijvoorbeeld ook het afstemmen van aanpak op prijs en oplossing) is een uitdaging.

Binnen het CI/CD-proces wordt de samenstelling van de release en de manier waarop de onderdelen door de gehele keten (pipeline) gaan vastgelegd in configuratiebestanden en geautomatiseerd uitgevoerd. Voor het bidproces betekent dat een geautomatiseerde workflow. Probeer je bidproces door workflow software te laten ondersteunen. Behalve de snelheid van oplevering, zal dit de kwaliteit van de aanbieding zeker ten goede komen.

Continuous Delivery (CD) - Leveren

Bij CD-activiteiten draait alles om de levering van functionaliteit, product of dienst. Continuous Delivery bestaat uit vier fasen: release, deploy, operate en monitor, vergelijkbaar met het bundelen, verspreiden, onderhouden en meten in het bidproces.

Zoals je wellicht is opgevallen valt de fase Release/Bundelen zowel in CI als CD. De pijl van het CI-proces (zie figuur) eindigt in het midden van het releaseproces, omdat juist in deze fase Development en Operations intensief moeten samenwerken (DevOps). In een optimale situatie is er overigens geen knip, maar werken business, ontwikkelaars, beheerders, security/kwaliteit medewerkers en klanten vanaf het begin samen. Bij Solvinity noemen we de automatisering van de gehele leveringsketen “Integrated Delivery” en het samenwerken met meerdere partijen over bedrijfsmuren heen “Stretched DevOps“.

Deploy - Verspreiden

Het transporteren en installeren van de nieuwe functionaliteit start vaak op de laptop van de ontwikkelaars en eindigt via test- en acceptatieomgevingen in productie. De distributie van nieuwe functionaliteit heeft een enorme verandering ondergaan met de introductie van containers als transportvehikel. Het gebruik van containers, als efficiëntere vorm van virtualisatie, sluit ook naadloos aan bij het incrementeel werken binnen de softwareontwikkeling. De ontwikkeling van kleine functionele diensten (microservices) die met elkaar communiceren heeft grote voordelen op het vlak van schaalbaarheid, beschikbaarheid en overdraagbaarheid. Functionaliteit, verpakt in een container, kan in kleinere en meer gecontroleerde stappen aan specifieke gebruikersgroepen geleverd worden.

Als bidteam lever je uiteindelijk één set van bestanden aan. Daarvoor worden de documenten vaak eerst ge-pdf’t. Het voordeel van een PDF-document is dat deze op alle mogelijke apparaten te lezen is en je daarmee, net als bij containers, platformonafhankelijk bent. Door de oplevering te splitsen in verschillende PDF-bestanden kun je eenvoudig één PDF vervangen, zonder een compleet nieuwe oplevering uit te hoeven voeren. Tot slot zorgt een PDF ervoor dat je zeker weet dat derden de inhoud niet kunnen wijzigen. Een nieuwe versie betekent de oplevering van een nieuwe PDF.

Open de PDF om deze visueel te controleren. Vooral kop- en voetteksten vallen minder op in een editor.

Operate - Onderhouden

CI/CD gaat verder dan het bouwen, testen, integreren, vrijgeven en uitrollen van nieuwe functionaliteit. Zodra de software beschikbaar is gesteld, moet deze ook beschikbaar blijven, beveiligd zijn en een goede performance bieden. Het borgen van deze niet-functionele aspecten valt traditioneel binnen het vakgebied van de beheerders (Ops). Maar ook hierbij moet intensief worden samengewerkt tussen Dev en Ops. Vanaf het ontwerp van de functionaliteit moet al rekening worden gehouden met deze kwaliteitsaspecten. Daarom houdt het CI/CD-proces niet op bij de uitrol van software en kan er geen sprake zijn van spreekwoordelijke ‘Chinese muren’ tussen ontwikkeling en beheer.

Ook een bidteam is niet klaar, wanneer de aanbieding is verstuurd. Na een deal zullen er wijzigingsverzoeken komen die in lijn moeten blijven met de initiële aanbieding, eigen medewerkers willen begrijpen wat er is opgeleverd en op deelproducten door willen ontwikkelen, etc. In het huidige bidproces zie je, mede door de bonus incentive die gegeven wordt wanneer de deal gewonnen is, vaak te weinig aandacht voor feedback uit de beheerfase. De afstand tussen verkoop en operatie is dan te vergelijken met die tussen development en operations.

Succesvolle bidteams blijven een relatie onderhouden met de gebruikers en beheerders van de door hen uitgebrachte voorstellen. Dus ga ook tijdens de beheerfase eens na in hoeverre de oorspronkelijke aanbieding nog wordt gevolgd. Wat was goed, wat kan beter?

Monitor - Meten

Hoe succesvol een nieuwe release is, moet worden gemeten. Wordt de nieuwe functionaliteit wel gebruikt? Zijn de gebruikers tevreden en productiever? Zijn er nieuwe wensen en eisen ontstaan? Het meetresultaat van deze aspecten is de input voor nieuwe releases en de optimalisatie en innovatie van de dienstverlening. Daarmee is de cirkel rond en zijn wij terug bij het planproces.

Een bidteam wil weten waarom een deal is verloren of gewonnen. Het wil de aansluiting met de operatie en klanten houden om succesvolle aanbiedingen te kunnen schrijven. Het verzamelen en analyseren van gewonnen, maar vooral ook verloren, bid data kan enorm helpen bij het kwalificeren van toekomstige deals en daarmee veel tijd en geld besparen. Beide processen draaien uiteindelijk om het continu en efficiënt blijven leveren van de best passende oplossing aan de klant.

Heb je vragen over de invoering van CI/CD of wil je sparren over het verbeteren van het bidproces? Neem contact op met klaas.heek@solvinity.com.