Continue integratie vs.
Continue levering

Wat is continue integratie (CI)?

CI of Continue Integratie is een praktijk in ontwikkeling waarbij de codebases van alle ontwikkelaars meerdere keren per dag worden samengevoegd in een gedeelde repository. Deze praktijk draait om het opzetten van een consistente build-, pakket- en testproces in een project. 

Wanneer er consistentie is in integratie, zullen de teams code wijzigingen veel frequenter committen. Door betere samenwerking in ontwikkeling kunnen bugs en integratieproblemen veel eerder worden gedetecteerd. Ook eindigen ontwikkelaars met het schrijven van meer modulaire code die gemakkelijker te ondersteunen is. Dit alles resulteert in een algehele betere softwarekwaliteit.

Continue Integratie is geen nieuw concept, aangezien het al sinds de jaren 90 bestaat. Echter, de naam CI werd iets later bedacht en ook de werkwijze is enigszins aangepast, maar het algemene concept blijft hetzelfde: veranderingen in de code combineren in kleine eenheden, maar meerdere keren per dag, en testen of het project wordt gebouwd en uitgevoerd nadat die wijzigingen zijn geïmplementeerd. Het begon als een praktijk om de beruchte samenvoegingsproblemen te vermijden die regelmatig opduiken.

Wat is Continue Levering?

CD of Continue Levering is een andere praktijk in ontwikkeling die je in staat stelt om je samengevoegde code in productie te implementeren zonder dat iemand dit handmatig hoeft te doen. CD gaat verder waar CI is gestopt en neemt de opgeslagen code in de repository via CI en levert deze voortdurend af aan productie.

CD is zeer nuttig, vooral als je team werkt aan meerdere omgevingen zoals ontwikkeling en testen. CD zorgt ervoor dat eventuele code wijzigingen automatisch worden doorgevoerd in al deze omgevingen. Het hoofddoel van CD is om automatisch alle obstakels op te ruimen die kunnen ontstaan bij de implementatie of release. Omdat elke stap geautomatiseerd is in het bouwproces, kan de release van de code op elk moment veilig worden uitgevoerd zonder dat je je zorgen hoeft te maken over eventuele last-minute problemen.

Wat is de CI/CD-pijplijn?

De CI/CD-pijplijn is een uitvoerbare specificatie van alle stappen die moeten worden uitgevoerd om een bijgewerkte versie van de applicatie te leveren. Zoals we eerder hebben gezien, is deze pijplijn volledig geautomatiseerd en vereist geen menselijke tussenkomst. 

De CI/CD-pijplijn bestaat doorgaans uit 4 fasen: 

1. Bronfase: de eerste fase draait om het triggeren van de broncodeopslagplaats. Dit gebeurt wanneer er een wijziging in de code is die automatisch een melding naar de CI/CD-tool triggert. De tool voert vervolgens de overeenkomstige pijplijn uit. Geplande of door de gebruiker geïnitieerde workflows en resultaten van andere pijplijnen zijn ook veelvoorkomende triggers.
2. Bouwfase: De tweede fase is het samenvoegen van de broncode en de afhankelijkheden ervan om de uitvoerbare instantie van de software te bouwen. Dit kan vervolgens worden geleverd aan de eindgebruikers. Ongeacht in welke taal de code is geschreven, wordt alle cloud-native software voornamelijk ingezet met Docker, en deze fase bouwt typisch de Docker-containers. Als je de bouwfase niet kunt doorlopen, betekent dit dat er een fundamenteel probleem is in de configuratie.
3. Testfase: Deze fase draait helemaal om het uitvoeren van geautomatiseerde tests en het valideren van de code op eventuele fouten, om een foutloos product aan de eindgebruikers te leveren. Deze fase kan uren duren, afhankelijk van de complexiteit van het project. Sommige complexe projecten vereisen mogelijk meerdere smoke tests en end-to-end integratietests, terwijl eenvoudige projecten mogelijk niet tot dat niveau vereisen. Als je de testfase niet kunt doorlopen, betekent dit dat de ontwikkelaars wat problemen hebben geïntroduceerd bij het schrijven van de code. Hoe sneller het probleem de ontwikkelaars bereikt, hoe sneller ze het kunnen verhelpen.
4. Deploymentfases: Dit is de laatste fase waarin we de uitvoerbare instantie van de code implementeren die alle voorgaande drie fasen heeft doorlopen. De code kan worden geïmplementeerd naar meerdere omgevingen zoals staging of productie.

Voordelen van CI/CD

Er zijn veel voordelen verbonden aan het gebruik van CI/CD. 

1. Snellere release: Dit is het meest voor de hand liggende voordeel dat je zult ervaren zodra je CI/CD gaat gebruiken in je project. Een project met CI/CD zal snellere release-snelheden hebben omdat de builds sneller zijn, er minder handmatige interactie is en de implementatie regelmatig plaatsvindt. De gehele duur van de SDLC neemt drastisch af.
2. Efficiënte testen & foutisolatie: Je testproces verbetert aanzienlijk en je blijft achter met minimale bugs bij het gebruik van CI/CD. Dit komt doordat de testen worden uitgevoerd op kleine stukjes wijzigingen, wat ervoor zorgt dat de nauwkeurigheid van de testen verbetert. Niet alleen dat, foutisolatie wordt veel gemakkelijker omdat je gemakkelijk kunt identificeren wanneer en waar de fout is opgetreden. Dit beperkt de bugs nog verder. Dit helpt bij het verminderen van de kans op ernstige problemen die ernstige problemen kunnen veroorzaken voor de applicatie.
3. Verbeterde teamdynamiek: Wanneer je dagelijkse ontwikkelingstaken worden teruggebracht tot kleine brokjes, wordt je leven als ontwikkelaar veel eenvoudiger. Dit verhoogt niet alleen de teamgeest, maar maakt ze ook zeer efficiënt. CI/CD is een uitstekende manier om continu feedback van het team te ontvangen, waardoor de algehele transparantie tussen hen verbetert. Het beste van CI/CD is dat je snelle feedback krijgt van zowel het interne team als de klanten, waardoor je snel kunt bijsturen.
4. Hoge kwaliteit van code: Als je deel uitmaakt van een van die projecten waar de kwaliteit van de code van het grootste belang is, dan kan CI/CD worden omarmd om dat te bereiken. Vanwege de meerdere en repetitieve stappen in een CI/CD worden fouten snel ontdekt en snel opgelost. Dit verbetert automatisch de kwaliteit van de code.

Wanneer je niet voor CI/CD kiest

Hoewel het logisch lijkt om CI/CD voor elk project te adopteren, zijn er bepaalde momenten waarop het het beste is om het niet te omarmen. Het implementeren van CI/CD is niet goedkoop en vereist veel inspanning en geld, vooral wanneer je al een bestaand project hebt dat draait zonder CI/CD. Als je vanaf nul begint, is het een ander verhaal.

Wanneer je CI/CD-workflows toevoegt aan je bestaande project, zul je uiteindelijk de hele workflow veranderen en het testproces automatiseren. Dit is allemaal geweldig op de lange termijn, maar het opzetten ervan vereist veel manuren, wat misschien moeilijk te beheren is als je al een beperkt budget hebt. Een project met CI/CD vereist continue ondersteuning, wat moeilijk kan zijn voor een organisatie die diverse diensten aanbiedt.

Conclusie

Als je je project wilt stroomlijnen en een betere efficiëntie en minder bugs wilt ervaren, dan is het omarmen van CI/CD een verstandige keuze. Organisaties moeten echter de voor- en nadelen van CI/CD afwegen en beslissen wat voor hen belangrijker is. Met dat gezegd te hebben, hebben de meeste organisaties tegenwoordig al efficiënte CI/CD-tools zoals Jenkins of Azure DevOps die een belangrijke rol spelen in hun dagelijkse ontwikkeling.