September 10, 2024

CI/CD
Duurt het soms weken voordat een nieuwe feature eindelijk naar productie kan? Zijn er in je versiebeheersysteem branches of features die überhaupt nooit naar productie zijn gegaan? Continuous Integration/Continuous Delivery (CI/CD) maakt een einde aan inefficiënte software development. Hoe pak je dit aan, wat is de CI/CD Way of Working?

Erik Jansen, DevTest Expert bij Sogeti licht toe wat in hoofdlijnen de beste manier van werken is als je CI/CD-principes toepast. De basis zit in de CI/CD-principes, waarbij je door de juiste branching-strategie, automatisch testen en het creatief inzetten van release-strategieën continu software kunt integreren en releasen. Ofwel, Continuous Integration en Continuous Delivery.

Stop met het gebruiken van branches

Erik schetst een uitdaging waar veel ontwikkelteams in de praktijk tegenaan lopen. “Stel, je begint een autoverhuurbedrijf. Dan heb je software nodig om auto’s te verhuren. In het begin heb je één developer in dienst. De zaken gaan goed en al snel worden dat er meer, waarbij elke developer werkt aan de code van andere features. Maar op een gegeven moment moeten al deze kopieën in verschillende feature branches gecombineerd worden in een hoofdkopie, ook wel main of trunk genoemd. Hoe zorg je dat er geen problemen ontstaan als je deze verschillende branches samenvoegt: bijvoorbeeld dat er geen bug of conflict optreedt?”

Trunk based development

In plaats van langlevende feature branches te gebruiken, werk je met één branch waar alle code zo snel mogelijk samenkomt. Deze hoofdkopie wordt verschillende keren per dag geüpdate. Dit kan je doen met trunkbased development. “Bij Continuous Integration voert iedere developer zijn of haar codewijzigingen zo snel mogelijk door in de main branch. De periode tussen een wijziging en de integratie in de hoofdcode, moet zo kort mogelijk zijn, maximaal een dag”, zegt Erik. “Al deze kleine codewijzigingen moeten ook getest worden. Dus tegelijkertijd met de nieuwe code, voeg je een passende test toe. Testautomatisering is daarbij onmisbaar.”

Hoe testen?

Alle wijzigingen, voor elke feature, van iedere developer moeten minimaal dagelijks getest worden. Hoe kan je al deze kleine codewijzigingen het beste en meest efficiënt testen? Testautomatisering biedt dan uitkomst. “Let er ook op dat je wel risk based test. Dat vergeten DevOps-tams nog wel eens omdat de focus vaak op snelheid ligt”, vult Erik aan. “Maak ook onderscheid tussen verschillende testtypes, zoals in de bekende testintegratie-piramide; besteed veel tijd aan unit-testen, minder aan integratietesten en nog minder aan business proces-testen. En tot slot, zorg dat je werkt met een up-to-date, robuuste testset.”

Welke release-strategie past bij jouw team?

Binnen Continuous Delivery zoomen we in op de deployment- en release-stap. Daarbij kan vooral in de release veel winst op het gebied van snelheid en kwaliteit geboekt worden. Elke organisatie en elk team is anders. Er zijn dan ook uiteenlopende release-strategieën. Het is vooral zaak om daar vooraf over na te denken en de best passende strategie te kiezen. Wat is voor jouw team de beste optie? In zijn presentatie op QX Day zoomt Erik in op vier populaire release-strategieën. Bekijk de video van de QX day-presentatie ‘De CI/CD WoW.(externe link)

Meer weten?

Ben je benieuwd hoe we organisaties kunnen helpen hun Quality Engineering naar het volgende level te tillen? Bekijk dan onze Quality Engineering & Testing oplossingen en services.

Quality Engingeering & Testing services

Marco
Marco van Winsen

Head of Quality Engineering & Testing