Close

Continue levering

Continue levering (CD) is de praktijk waarbij automatisering wordt gebruikt om software in korte iteraties vrij te geven

Wat is continue levering?


Continue levering is een aanpak waarbij teams op een geautomatiseerde manier regelmatig en voorspelbaar kwaliteitsproducten uitbrengen, van de broncoderepository tot de productie.

Sommige organisaties brengen producten handmatig uit door ze van het ene team naar het andere door te geven, zoals geïllustreerd in het onderstaande diagram. Meestal bevinden ontwikkelaars zich aan de linkerkant van dit spectrum en operationeel personeel aan de ontvangende kant. Dit zorgt voor vertragingen bij elke overdracht en dat leidt weer tot gefrustreerde teams en ontevreden klanten. Het product gaat uiteindelijk live via een moeizaam en foutgevoelig proces dat het genereren van inkomsten vertraagt.

Afbeelding 1: Handmatige release van producten aan klanten
Stappen voor handmatige release: Dev, QA, Tools, Infrastructuur, Platform, Release, InfoSec

Bekijk nu de pipeline voor continue levering hieronder. Deze illustreert hoe ontwikkelaars code schrijven op hun laptops en wijzigingen doorvoeren in een broncoderepository, zoals Bitbucket. Met code bedoelen we het systeem dat wordt getest, de tests en de infrastructuur die wordt gebruikt om het systeem te implementeren en te onderhouden. Bitbucket Pipelines kan het product van test tot stagen tot productie verzenden en klanten helpen om aan die leuke nieuwe functies te komen.

Afbeelding 2: Pipeline voor continue levering met geautomatiseerde releases
Stappen voor continue levering: ontwikkelaar, laptop, Bitbucket, Bitbucket Pipelines, klanten

Hoe werkt continue levering?


Een pipeline voor continue levering kan een handmatige poort voor de productie hebben. Voor een handmatige poort is menselijke tussenkomst vereist, en er kunnen zich in je organisatie scenario's voordoen waarin handmatige poorten in pipelines nodig zijn. Sommige handmatige poorten zijn misschien twijfelachtig, terwijl andere legitiem kunnen zijn. Eén legitiem scenario stelt het bedrijfsteam in staat om op het laatste moment een beslissing te nemen over de release. Het technische team houdt na elke sprint een verzendbare versie van het product gereed. Het bedrijfsteam neemt de laatste beslissing om het product beschikbaar te stellen aan alle klanten, of aan een deel van de bevolking, of misschien aan mensen die op een bepaalde geografische locatie wonen.

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 kunnen 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. 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. Dit is de componentfase.

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. Dit is de subsysteemfase. In tegenstelling tot componenten kunnen subsystemen worden opgesteld en getest.

Daarom kan de pipeline worden geleerd om een systeem samen te stellen op basis van losjes gekoppelde subsystemen in gevallen waarin het hele systeem als geheel gereleased zou moeten worden. Dit is de systeemfase.

We raden deze samenstelling af waarbij subsystemen worden samengevoegd tot een systeem. Hiervan zie je een illustratie in Afbeelding 3.

Afbeelding 3: Subsystemen verzameld in een systeem
Diagram van het subsysteem

Deze alles-of-niets-benadering zorgt ervoor dat het snelste subsysteem met de snelheid van het langzaamste subsysteem werkt. 'De ketting is zo sterk als de zwakste schakel' is een cliché dat we gebruiken om teams te waarschuwen die ten prooi vallen aan dit architectuurpatroon.

Eenmaal gevalideerd, wordt het verzamelde systeem vervolgens zonder verdere aanpassingen naar productie gebracht, in de laatste fase, de zogenaamde productiefase.

Merk op dat deze fasen logischer zijn dan fysieke, en enkel aangemaakt zijn om een groot probleem op te splitsen in meerdere kleinere deelproblemen. Het kan zijn dat je minder of meer fasen hebt, afhankelijk van je architectuur en vereisten.

Snelheid zonder kwaliteit is nutteloos voor onze klanten. Continu testen is een techniek waarbij geautomatiseerde tests worden geïntegreerd in de pipeline voor softwarelevering en waarbij elke wijziging die daaruit komt, wordt gevalideerd. In elke fase van de pipeline worden tests uitgevoerd om artefacten te valideren die in die fase zijn geproduceerd. Unittests en statische code-analyse valideren componenten in de componentfase van de pipeline. Functionele, prestatie- en beveiligingstests valideren subsystemen in de subsysteemfase. Integratie-, prestatie- en beveiligingstests valideren systemen in de systeemfase. Ten slotte valideren smoke-tests het product in de productiefase.

Afbeelding van codebeoordeling

Geautomatiseerde tests integreren in de pipeline

Een monolithische productarchitectuur, of een 'grote modderbal', kan resulteren in een 'grote bal van tests'. We raden aan te investeren in microservices, zodat onafhankelijk inzetbare artefacten door pipelines kunnen stromen zonder dat er een sterk geïntegreerde omgeving nodig is voor certificering. Bovendien zorgen onafhankelijk inzetbare artefacten ervoor dat snellere teams niet tegengehouden worden door tragere teams.

De waarde van continue levering


De pipeline voor de softwarelevering is een product an sich en zou een prioriteit moeten zijn voor bedrijven. Anders moet je er geen inkomstengenererende producten doorheen sturen. Continue levering voegt op drie manieren waarde toe. Het verbetert de snelheid, productiviteit en duurzaamheid van ontwikkelingsteams voor software.

Afbeelding van raket

Snelheid

Snelheid betekent verantwoordelijke snelheid en niet suïcidale snelheid. Pipelines zijn bedoeld om kwaliteitsproducten naar klanten te verzenden. Tenzij teams gedisciplineerd zijn, kunnen pipelines foutieve code naar productie sturen, maar dan sneller! Geautomatiseerde pipelines voor de softwarelevering helpen organisaties beter te reageren op veranderingen in de markt.

Afbeelding van code-pipeline

Productiviteit

Een piek in productiviteit ontstaat wanneer vervelende taken, zoals een wijzigingsverzoek indienen voor elke wijziging die naar de productie gaat, via pipelines kunnen worden uitgevoerd in plaats van door mensen. Zo kunnen scrumteams zich concentreren op producten die wereldwijd indruk maken, in plaats van hun energie te besteden aan logistiek. En dat kan ervoor zorgen dat teamleden gelukkiger zijn, meer betrokken zijn bij hun werk en dat ze langer in het team willen blijven.

Afbeelding van beslissing

Duurzaamheid

Duurzaamheid is essentieel voor alle bedrijven, niet alleen voor technologie. 'Software probeert de wereld te veroveren' is niet langer waar, software heeft de wereld al veroverd! Elk bedrijf gebruikt uiteindelijk technologie om zich te onderscheiden en de concurrentie te slim af te zijn, of het nu gaat om gezondheidszorg, financiën, detailhandel of een ander domein. Automatisering helpt handmatige taken die foutgevoelig en repetitief zijn te verminderen/elimineren, waardoor het bedrijf beter en sneller kan innoveren om aan de behoeften van hun klanten te voldoen.

Wie moet continue levering doen en wanneer?


Wat is een goed moment om continue levering te implementeren? Dat moment was gisteren.
Teams hebben één geprioriteerde backlog nodig waarbij:

  1. Continue levering wordt omarmd, in plaats van naar de achtergrond geschoven
  2. De acceptatiecriteria voor userstory's expliciet de geautomatiseerde softwareleveringsmethoden vermelden in plaats van handmatige methoden
  3. De sprint Definitie van Voltooid (DoD) voorkomt dat teams sprints afmaken waarbij het product handmatig wordt verzonden

Continue levering is de juiste keuze en soms zijn er kampioenen nodig om de transformatie een vliegende start te geven. Uiteindelijk betalen pipelines voor continue levering zichzelf terug als ze goed zijn ontworpen.

Dus, wie is erbij betrokken?

Sommige organisaties zetten onervaren mensen in om pipelines voor continue levering te ontwerpen en te implementeren, en kwamen er op de harde manier achter dat daar ingewikkelde structuren bij kwamen kijken. Het aanstellen van junior leden geeft een verkeerd signaal af aan de teams, en impliceert dat continue levering een lage prioriteit heeft. We raden ten zeerste aan om een senior architect de leiding te geven, die een grote waardering heeft voor technologie en het bedrijf.

Meer dan continue levering


Waar je je ook bevindt in je traject van continu alles (integratie, testen, levering, implementatie, analyse, enz.), het is geen checklist of bestemming, en continue verbetering vormt de kern ervan.

Vroeg of laat wordt iedereen in de organisatie opgeroepen als er pipelines voor continue levering worden aangelegd. Leidinggevend personeel, engineering, productmanagement, gegevensbeheer, risico, compliance, InfoSec, bedrijfsvoering, juridische zaken en wat je nog meer hebt. Pipelines knagen door silo's en breken muren af. We maken allemaal op de een of andere manier deel uit van deze transformatie, en 'continu' is voor iedereen het nieuwe normaal!

Aan de slag met CI/CD

Om CI/CD te oefenen kun je tools gebruiken om ontwikkeling, implementatie en testen te automatiseren. Specifieke tools bieden integratie, andere zorgen voor ontwikkeling en implementatie, terwijl weer andere tools testen aanbieden.

Atlassian biedt een Open DevOps-oplossing die end-to-end DevOps-processen biedt, waaronder CI/CD. Teams kunnen tal van CI/CD-tools gebruiken, waaronder Bitbucket Pipelines, een geïntegreerde CI/CD-service ingebouwd in Bitbucket. Hiermee kun je automatisch je code bouwen, testen en zelfs implementeren, op basis van een configuratiebestand in je repository. Open DevOps kan ook geïntegreerd worden met andere CI/CD-tools, waaronder Harness, GitLab, JFrog, Codefresh en CircleCI.

Hier is een nadere blik op onze Open DevOps-integraties. Bekijk zeker onze DevOps CI/CD-tutorials.

Afbeelding van continue levering