CI / CD-pijpleidingen en tooling

TMAP perf

In DevOps moet een CI / CD-pijplijn worden geïmplementeerd. CI / CD is de afkorting van Continuous Integration / Continuous Deployment (soms wordt in plaats daarvan Continuous Delivery gebruikt). CI / CD wordt gezien als de ruggengraat om DevOps mogelijk te maken. Het overbrugt, misschien dicht zelfs de kloof tussen ontwikkeling en productie door het bouwen, packagen, testen, inrichten  van infrastructuur en deployment van applicaties te automatiseren. Naast CI / CD zijn er natuurlijk nog andere aspecten (pijlers) die de kloof tussen Dev en Ops overbruggen.

afbeelding 6.png

Voorbeeld CI / CD-pijplijn

Een CI / CD-pijplijn is vaak maatwerk. We gaan hier uit van een vereenvoudigd model van de verschillende fasen binnen een CI / CD-pijplijn gebruikt.

Onze voorbeeld-CI / CD-pijplijn bestaat uit het CI-gedeelte (de build-pijplijn) en het CD-gedeelte (de releasepijplijn), die de volgende fasen bevatten:

CI-pijplijn

Source stage: In de meeste gevallen wordt een pijplijnrun geactiveerd door versiebeheer (zoals GIT of SVN). Een wijziging in de code activeert een melding naar de CI / CD-orchestratie-tool (zoals Jenkins of Azure pipelines), die de bijbehorende pijplijn uitvoert.

Build Stage:  De broncode (bijvoorbeeld Java of C) is gebouwd naar een deployable instance, verpakt of gecontaineriseerd.

Team Test Stage: In deze fase wordt geautomatiseerde code review (statische code analyse, met bijvoorbeeld SonarQube) uitgevoerd, evenals geautomatiseerde unit tests (met bijvoorbeeld JUnit, JMockit of Microsoft Unit Testing Framework) en integratietesten (met bijvoorbeeld Arquillian). Alle tests in de teamtestfase vallen onder de verantwoordelijkheid van het DevOps-team.

CD-pijplijn

Deploy for Business Test Stage: Wanneer de uitvoerbare instantie van de code alle codevalidaties en vooraf gedefinieerde unit- en integratietesten heeft doorstaan, wordt het pakket geïmplementeerd in een testomgeving. Afhankelijk van de implementatiestrategie kunnen er meerdere implementatieomgevingen zijn voor verschillende doeleinden. In dit voorbeeld gebruiken we één omgeving, genaamd Business Test Stage.

Business Test Stage: In deze fase worden testvariëteiten zoals gebruikersacceptatietests, performancetesten, regressietests uitgevoerd. (Geautomatiseerde tests worden uitgevoerd met bijvoorbeeld UFT, Xray, Selenium of Robot Framework.) En, zoals gezegd, kunnen er meerdere omgevingen nodig zijn om de verschillende tests te ondersteunen. Alle tests in de Business Test Stage vallen onder de verantwoordelijkheid van het DevOps-team, maar ze vereisen wel input van verschillende Business belanghebbenden buiten het DevOps-team.

Deploy for Production Stage: Wanneer de applicatie is gevalideerd en goedgekeurd, kan de software worden geïmplementeerd in de productieomgeving. Met betrekking tot cloud-native software wordt de cloudinfrastructuur samen met de applicatie geleverd.

Productie, monitoring Na implementatie moet het gedrag van het systeem continu worden bewaakt tijdens live-gebruik, evenals de verkregen informatie die wordt gebruikt om het toekomstige gedrag van het systeem te voorspellen en, indien nodig, adaptieve maatregelen moeten worden georganiseerd. Met een volledig geautomatiseerde release worden de monitoringtools en het bijbehorende policies automatisch geconfigureerd tijdens de implementatie.

In elke fase van de CI / CD-pijplijn zijn continue monitoring (met tooling zoals Dynatrace en New Relic) en de feedback van de monitoring geïntegreerd. Elk probleem dat zich in een van de fasen voordoet, wordt - automatisch - gerapporteerd (met bijvoorbeeld ALM Octane, Slack of JIRA) en de CI / CD-workflow wordt gestopt. DevOps-teams hebben het gebruik om altijd een succesvolle CI / CD-pijplijn te hebben. DevOps-teamleden lossen het probleem op en het proces herhaalt zich indien nodig.

 

 

Rianne de Neef
Manager Sogeti Academy