Pipeline voor continue levering voor beginners

Hoe cliché het ook mag klinken, het gezegde 'fouten maken is menselijk' gaat nog steeds op. Teams zetten zich schrap voor impact tijdens handmatige releases, aangezien die processen broos zijn. Voorspelbaarheid houdt in dat releases bepalend van aard zijn wanneer ze uitgevoerd worden via pipelines voor continue levering. Aangezien pipelines een programmeerbare infrastructuur zijn, kunnen teams elke keer het gewenste gedrag verwachten. Ongelukken kunnen natuurlijk gebeuren, aangezien geen enkele software foutloos is. Pipelines zijn echter exponentieel beter dan handmatige, foutgevoelige releaseprocessen, aangezien pipelines, in tegenstelling tot mensen, niet haperen bij strakke deadlines.

Pipelines hebben softwarepoorten die automatisch de doorvoer van artefacten in een versie bevorderen of weigeren. Als het releaseprotocol niet wordt nageleefd, blijven de softwarepoorten gesloten en wordt de pipeline afgebroken. Er worden waarschuwingen gegenereerd en meldingen worden naar een distributielijst gestuurd met teamleden die mogelijk verantwoordelijk zijn voor het breken van de pipeline.

Zo werkt een CD-pipeline: elke keer dat de pipeline succesvol loopt, wordt een commit, of een kleine groep commits, naar de productie geleid. Uiteindelijk verzenden teams functies en producten op een veilige en controleerbare manier.

De architectuur van het product dat door de pipeline stroomt, is een belangrijke factor die de opmaak van de pipeline voor continue levering bepaalt. Een sterk gekoppelde productarchitectuur genereert een ingewikkeld grafisch pipeline-patroon waarbij verschillende pipelines verstrikt raken voordat ze uiteindelijk naar de productie gaan.

De productarchitectuur heeft ook invloed op de verschillende fasen van de pipeline en op de artefacten die in elke fase worden geproduceerd. Laten we het hebben over de vier veelvoorkomende fasen bij continue levering:

1. De componentfase
2. De subsysteemfase
3. De systeemfase
4. De productiefase

Zelfs als je in je organisatie meer dan vier of minder dan vier fasen verwacht, zijn de onderstaande concepten nog steeds van toepassing.

Een veel voorkomende misvatting is dat er tijdens deze fasen fysieke verschijnselen in je pipeline zitten. Dat hoeft niet zo te zijn. Dit zijn logische fasen en kunnen worden gerelateerd aan mijlpalen in de omgeving, zoals testen, stagen en productie. Componenten en subsystemen kunnen bijvoorbeeld worden gebouwd, getest en geïmplementeerd in de test. Subsystemen of systemen kunnen in staging worden verzameld, getest en geïmplementeerd. Subsystemen of systemen kunnen als onderdeel van de productiefase worden gepromoot tot productie.

De kosten van defecten zijn laag wanneer ze worden ontdekt in de tests, gemiddeld wanneer ze worden ontdekt tijdens het stagen en hoog in de productie. 'Shift Left' verwijst naar validaties die eerder in de pipeline worden uitgevoerd. De overgang van testen naar stagen heeft tegenwoordig veel meer verdedigingstechnieken ingebouwd, en daarom hoeft stagen er niet meer uit te zien als een plaats delict!

Historisch gezien ontstond InfoSec aan het einde van de levenscyclus van softwareontwikkeling, toen afgewezen releases een bedreiging voor de cyberbeveiliging van het bedrijf konden vormen. Hoewel deze bedoelingen nobel zijn, veroorzaakten ze frustratie en vertraging. 'DevSecOps' pleit ervoor dat beveiliging vanaf de ontwerpfase in producten wordt ingebouwd, in plaats van een (mogelijk onveilig) eindproduct ter evaluatie op te sturen.

Laten we eens nader bekijken hoe 'Shift Left' en 'DevSecOps' kunnen worden aangepakt binnen de workflow voor continue levering. In de volgende secties zullen we elke fase in detail bespreken.

De pipeline bouwt eerst componenten, de kleinste te distribueren en testbare units van het product. Een bibliotheek die door de pipeline is gebouwd, kan bijvoorbeeld een component worden genoemd. Een component kan onder andere worden gecertificeerd door middel van codebeoordelingen, unittests en statische code-analysatoren.

Codebeoordelingen zijn belangrijk voor teams om een gedeeld inzicht te hebben in de functies, tests en infrastructuur die nodig zijn om het product live te laten gaan. Een tweede paar ogen kan vaak wonderen doen. In de loop der jaren kunnen we immuun worden voor slechte code, zodat we niet meer inzien dat de code slecht is. Nieuwe perspectieven kunnen ons dwingen om die zwakke punten opnieuw te bekijken en ze waar nodig rigoureus opnieuw in te richten.

Unittests zijn bijna altijd de eerste reeks softwaretests die we uitvoeren op onze code. Ze raken de database of het netwerk niet aan. Codedekking is het percentage code dat is gebruikt tijdens unittests. Er zijn veel manieren om de dekking te meten, zoals regeldekking, klassedekking, methodedekking, enz.

Het is geweldig om een goede codedekking te hebben om refactoring te vereenvoudigen, maar het is nadelig om hoge dekkingsdoelen te stellen. In tegenstelling tot wat vaak wordt gedacht, hebben sommige teams met hoge codedekking meer productieonderbrekingen dan teams met een lagere codedekking. Houd er ook rekening mee dat het makkelijk is om met de hoeveelheden voor dekking te sjoemelen. Onder grote druk, vooral tijdens prestatiebeoordelingen, kunnen ontwikkelaars terugvallen op oneerlijke praktijken om de codedekking te vergroten. En dat ga ik hier niet behandelen!

Statische code-analyse detecteert codeproblemen zonder deze uit te voeren. Dit is een goedkope manier om problemen op te sporen. Zoals unittests, worden deze tests uitgevoerd op de broncode en kunnen ze snel worden uitgevoerd. Statische analysatoren detecteren mogelijke geheugenlekken, samen met indicatoren voor de kwaliteit van de code, zoals cyclomatische complexiteit en codeduplicatie. In deze fase zijn statische analyse beveiligingstests (SAST) een bewezen manier om beveiligingsproblemen op te sporen.

Definieer de statistieken die van invloed zijn op je softwarepoorten en op de codepromotie, van de componentfase tot de subsysteemfase.

Losjes gekoppelde componenten vormen subsystemen, de kleinste implementeerbare en uitvoerbare units. Een server is bijvoorbeeld een subsysteem. Een microservice die in een container draait, is ook een voorbeeld van een subsysteem. In tegenstelling tot componenten kunnen subsystemen worden opgesteld en gevalideerd op basis van usecases van klanten.

Net zoals een UI van Node.js en een Java API-laag subsystemen zijn, zijn databases ook subsystemen. In sommige organisaties worden RDBMS (relationele databasebeheersystemen) handmatig afgehandeld, ook al is er een nieuwe generatie tools opgedoken die het beheer van databasewijzigingen automatiseren en met succes databases continu leveren. CD-pipelines met NoSQL-databases zijn eenvoudiger te implementeren dan RDBMS.

Subsystemen kunnen worden geïmplementeerd en gecertificeerd door middel van functionele, prestatie- en beveiligingstests. Laten we eens kijken hoe elk van deze testtypen het product valideert.

Functionele tests omvatten alle usecases van klanten met betrekking tot internationalisatie (I18N), lokalisatie (L10N), gegevenskwaliteit, toegankelijkheid, negatieve scenario's enz. Deze tests zorgen ervoor dat je product voldoet aan de verwachtingen van de klant, voldoet aan de normen voor inclusiviteit en de markt dient waarvoor het is gemaakt.

Bepaal samen met je producteigenaren je prestatiebenchmarks. Integreer je prestatietests in de pipeline en gebruik de benchmarks om de pipelines te laten slagen of falen. Een veel voorkomende mythe is dat prestatietests niet hoeven te worden geïntegreerd met pipelines voor continue levering, maar dat doorbreekt het continue model.

Grote organisaties zijn de laatste tijd gehackt en cyberdreigingen zijn nog nooit zo hoog geweest. We moeten ons schrap zetten en ervoor zorgen dat er geen beveiligingskwetsbaarheden in onze producten zitten, of dat nu in de code is die we schrijven of in bibliotheken van derden die we in onze code importeren. In feite zijn er grote inbreuken ontdekt in OSS (open source software) en we zouden tools en technieken moeten gebruiken om deze fouten te signaleren en te zorgen dat de pipeline wordt afgebroken. DAST (dynamische analyse beveiligingstests) een bewezen manier om beveiligingsproblemen op te sporen.

In de volgende afbeelding wordt de workflow beschreven die werd besproken in de component- en subsysteemfasen. Voer onafhankelijke stappen parallel uit om de totale uitvoeringstijd van de pipeline te optimaliseren en snel feedback te krijgen.

Zodra subsystemen voldoen aan de functionele, prestatie- en beveiligingsverwachtingen, kan de pipeline worden geleerd om een systeem samen te stellen uit losjes gekoppelde subsystemen wanneer het hele systeem als geheel wordt gereleased. Dat betekent dat het snelste team met de snelheid van het traagste team kan werken. Dit doet me denken aan het oude gezegde: 'Een ketting is zo sterk als de zwakste schakel'.

We raden dit samenstellingsantipatroon af waarbij subsystemen worden samengevoegd tot een systeem om als geheel gereleased te worden. Dit antipatroon koppelt alle subsystemen aan elkaar voor succes. Als je investeert in onafhankelijk inzetbare artefacten, kun je dit antipatroon vermijden.

Als systemen in hun geheel gevalideerd moeten worden, kunnen ze gecertificeerd worden door middel van integratie-, prestatie- en beveiligingstests. In tegenstelling tot de fase van het subsysteem mag je tijdens de tests in deze fase geen mocks of stubs gebruiken. Het is ook belangrijk om je vooral te richten op het testen van interfaces en netwerken.

De volgende afbeelding geeft een samenvatting van de workflow in de systeemfase, voor het geval je je subsystemen moet samenstellen met behulp van compositie. Zelfs als je je subsystemen naar productie kunt sturen, helpt de volgende afbeelding om vast te stellen welke softwarepoorten nodig zijn om code van deze fase naar de volgende fase te promoten.

De pipeline kan automatisch wijzigingsaanvragen (CR) indienen om een auditspoor achter te laten. De meeste organisaties gebruiken deze workflow voor standaardwijzigingen. Dit betekent geplande releases. Deze workflow moet ook worden gebruikt voor noodwijzigingen of ongeplande releases. Hoewel sommige teams hierop vaak bezuinigen. Merk op dat het wijzigingsaanvraag automatisch door de CD-pipeline wordt afgesloten wanneer fouten ertoe leiden dat het wordt afgebroken. Dit voorkomt dat wijzigingsaanvragen halverwege de pipeline van de workflow worden verlaten.

In de volgende illustratie wordt de workflow beschreven die werd besproken in de systeemfase van CD. Houd er rekening mee dat voor sommige stappen menselijke tussenkomst nodig kan zijn, en deze handmatige stappen kunnen worden uitgevoerd als onderdeel van handmatige poorten in de pipeline. Als de visualisatie van de pipeline in zijn geheel in kaart wordt gebracht, lijkt het sterk op de waardestroommapping van je productreleases!

Zodra het geassembleerde systeem gecertificeerd is, laat je de assemblage ongewijzigd en promoot je het voor productie.

Of subsystemen nu onafhankelijk kunnen worden geïmplementeerd of tot een systeem kunnen worden samengevoegd, de artefacten waarvan versies zijn gemaakt, worden als onderdeel van deze laatste fase in productie geïmplementeerd.

Zero downtime-installatie (ZDD) voorkomt downtime voor klanten en moet van testen tot staging tot productie worden toegepast. Blauw-groen is een populaire ZDD-techniek waarbij de nieuwe bits worden ingezet op een klein deel van de bevolking (genaamd 'groen'), terwijl het grote deel zich gelukkig niet bewust is van 'blauw', wat de oude onderdelen bevat. Als puntje bij paaltje komt, zet dan iedereen terug naar 'blauw' en dat heeft gevolgen voor heel weinig klanten en misschien zelfs geen. Als het er goed uitziet op 'groen', roep dan iedereen langzaam omhoog, van 'blauw' naar 'groen'.

Ik zie echter dat handmatige poorten in bepaalde organisaties worden misbruikt. Ze vereisen dat teams handmatige goedkeuring krijgen tijdens een bijeenkomst voor goedkeuring van wijzigingen (CAB). De reden hiervoor is meestal een verkeerde interpretatie van functiescheiding of scheiding van belangen. De ene afdeling geeft hun werk over aan de andere voor goedkeuring voordat het proces verder kan gaan. Ik heb ook gezien dat sommige CAB-goedkeurders over een oppervlakkige technische kennis beschikken van de veranderingen in de productie, waardoor het handmatige goedkeuringsproces traag en moeizaam verliep.

Dit is een mooie overgang om het verschil te bepalen tussen continue levering en continue implementatie. Continue levering maakt handmatige poorten mogelijk, terwijl bij continu implementatie dat niet mogelijk is. Beide worden CD genoemd, maar continue implementatie vereist meer discipline en nauwkeurigheid, aangezien er geen menselijke tussenkomst in de pipeline is.

Er is een verschil tussen het verplaatsen en inschakelen van onderdelen. Voer smoke-tests uit in de productie, die een subset vormen van de integratie-, prestatie- en beveiligingstestsuites. Zodra de smoke-tests zijn geslaagd, gaan de onderdelen aan en wordt het product beschikbaar voor klanten!

Het volgende diagram illustreert de stappen die het team heeft uitgevoerd in deze laatste fase van continue levering.

Om succesvol te zijn in continue levering of continue implementatie, is het van groot belang om continue integratie en continue tests goed uit te voeren. Met een solide basis slaag je op alle drie de fronten: kwaliteit, frequentie en voorspelbaarheid.

Een pipeline voor continue levering zet je ideeën om in producten door middel van een reeks duurzame experimenten. Als je ontdekt dat je idee niet zo goed is als je dacht, kun je snel met een nieuw idee beginnen. Bovendien verkorten pipelines de gemiddelde tijd tot oplossing (MTTR) van problemen in de productie, waardoor de downtime voor je klanten wordt verminderd. Met continue levering krijg je productieve teams en tevreden klanten, en wie wil dat niet?

Meer informatie vind je in onze tutorial voor continue levering.