Close

DevOps-pipeline

Een DevOps-pipeline is een reeks geautomatiseerde processen en tools waarmee ontwikkelaars en operations professionals kunnen samenwerken aan het bouwen en implementeren van code in een productieomgeving.

Krishna Sai Headshot
Tom Hall

DevOps-vertegenwoordiger en -professional


DevOps is een revolutionaire beweging, omdat het een revolutie teweegbrengt in de geïsoleerde organisatiestructuur die ontwikkeling en operaties scheidde. Het resultaat is een culturele verschuiving waarbij ontwikkelaars en operations professionals samenwerken, automatisering omarmen, de implementatiesnelheid verhogen en flexibeler zijn.

De resulterende DevOps-structuur heeft duidelijke voordelen: teams die DevOps-praktijken toepassen, kunnen hun implementatiepipeline verbeteren en stroomlijnen, wat de frequentie en impact van incident vermindert. De DevOps-praktijk van 'you build it, you run it' is hard op weg de norm te worden en met goede reden - bijna elke respondent (99%) van de DevOps Trends Survey 2020 zei dat DevOps een positieve impact heeft gehad op hun organisatie, met bijna de helft een snellere time-to-market en verbeterde implementatiefrequentie.

Toch is het implementeren van DevOps makkelijker gezegd dan gedaan. Het vereist de juiste mensen, cultuur en tools om DevOps succesvol te implementeren.

Wat is de DevOps-pipeline?


Een DevOps-pipeline is een reeks geautomatiseerde processen en tools waarmee ontwikkelaars en operations professionals kunnen samenwerken aan het bouwen en implementeren van code in een productieomgeving. Hoewel een DevOps-pipeline per organisatie kan verschillen, omvat deze meestal buildautomatisering/continue integratie, automatiseringstests, validatie en rapportage. Het kan ook een of meer handmatige gates bevatten die menselijke tussenkomst vereisen voordat de code door mag gaan.

Continu is een gedifferentieerd kenmerk van een DevOps-pipeline. Dit omvat continue integratie, continue levering/implementatie (CI/CD), continue feedback en continue activiteiten. In plaats van eenmalige tests of geplande implementaties vindt elke functie doorlopend plaats.

Pictogram verbonden ringen
gerelateerd materiaal

Gratis aan de slag

Tandwielpictogram
gerelateerd materiaal

Meer informatie over DevOps-tools

Overwegingen voor het bouwen van een DevOps-pipeline


Aangezien er niet één standaard DevOps-pipeline is, hangt het ontwerp en de implementatie van een DevOps-pipeline door een organisatie af van de technologiestack, de ervaring van de DevOps-engineer, het budget en meer. Een DevOps engineer moet uitgebreide kennis hebben van ontwikkeling en operations, waaronder codering, infrastructuurbeheer, systeembeheer en DevOps-toolchains.

Bovendien heeft elke organisatie een andere technologiestack die van invloed kan zijn op het proces. Als je codebase bijvoorbeeld node.js is, zijn factoren onder meer of je een lokaal proxy npm-register gebruikt, of je de broncode downloadt en `npm install` in elke fase in de pipeline uitvoert, of het eenmalig doet en een artefact genereert dat door de pipeline beweegt. Of, als een toepassing op containerbasis is, moet je besluiten om een lokaal of extern containerregister te gebruiken, de container één keer te bouwen en door de pipeline te verplaatsen of deze in elke fase opnieuw te bouwen.

DevOps Pipeline: commit maken, builden, unit-tests, samenvoegen naar stam, integratietests, staging, regressietests, implementeren. De pipeline wordt gestopt als een test op een bepaald moment mislukt en er wordt feedback gegeven aan de ontwikkelaar.

Hoewel elke pipeline uniek is, gebruiken de meeste organisaties vergelijkbare fundamentele componenten. Elke stap wordt geëvalueerd op succes voordat het proces verder gaat naar de volgende fase van de pipeline. In het geval van een storing wordt de pipeline gestopt en wordt feedback gegeven aan de ontwikkelaar.

Onderdelen van een DevOps-pipeline


Continue integratie/continue levering/implementatie (CI/CD)

Continue integratie is het maken van frequente commits naar een gemeenschappelijke broncoderepository. Het integreert continu codewijzigingen in de bestaande codebasis, zodat eventuele conflicten tussen de codewijzigingen van verschillende ontwikkelaars snel worden geïdentificeerd en relatief eenvoudig kunnen worden verholpen. Deze werkwijze is van cruciaal belang om de efficiëntie van de implementatie te verhogen.

Wij geloven dat trunk-gebaseerde ontwikkeling een vereiste is voor continue integratie. Als je geen frequente commits maakt naar een gemeenschappelijke branch in een gedeelde broncoderepository, doe je geen continue integratie. Als je build- en testprocessen geautomatiseerd zijn, maar je ontwikkelaars werken aan geïsoleerde, langlevende functietakken die niet vaak worden geïntegreerd in een gedeelde branch, doe je ook geen continue integratie.

Continue levering zorgt ervoor dat de 'hoofd-' of 'trunk'-branche van de broncode van een applicatie altijd in een staat verkeert die geschikt is voor release. Met andere woorden, als het management vrijdag om 16.30 uur naar je bureau kwam en zei: "We hebben de nieuwste versie nu nodig”, dan kan die versie met één druk op de push worden geïmplementeerd en zonder angst voor mislukking.

Dit betekent dat er een pre-productieomgeving is die zo dicht mogelijk identiek is aan de productieomgeving en ervoor zorgt dat geautomatiseerde tests worden uitgevoerd, zodat elke variabele die een storing kan veroorzaken, wordt geïdentificeerd voordat code wordt samengevoegd in de hoofd- of stamtak.

Continue implementatie houdt in dat er een mate van continue tests en bewerkingen is dat zo robuust is dat nieuwe softwareversies worden gevalideerd en geïmplementeerd in een productieomgeving zonder dat er menselijke tussenkomst nodig is.

Dit is zeldzaam en in de meeste gevallen niet nodig. Het zijn meestal alleen de eenhoornbedrijven die honderden of duizenden ontwikkelaars hebben en elke dag veel releases hebben die dit automatiseringsniveau vereisen of zelfs willen hebben.

Om het verschil tussen continue levering en continue implementatie te vereenvoudigen, kun je levering zien als de pakketbezorger die je een doos overhandigt, en implementatie zien als het moment dat je die doos opent en gebruikt wat erin zit. Als een wijziging van het product nodig is tussen het moment dat je de doos ontvangt en wanneer je deze opent, zit de fabrikant in de problemen!

Continue feedback

Het grootste pijnpunt van de oude watervalmethode voor softwareontwikkeling - en dus waarom agile methodologieën werden ontworpen - was het gebrek aan tijdige feedback. Toen nieuwe functies maanden of jaren nodig hadden om van idee naar implementatie te gaan, was het bijna gegarandeerd dat het eindresultaat iets anders zou zijn dan wat de klant verwachtte of wilde. Agile is erin geslaagd ervoor te zorgen dat ontwikkelaars sneller feedback kregen van belanghebbenden. Nu krijgen ontwikkelaars met DevOps continue feedback, niet alleen van belanghebbenden, maar ook door systematisch testen en monitoren van hun code in de pipeline.

Continu testen is een essentiële component van elke DevOps-pipeline en een van de belangrijkste voorwaarden voor continue feedback. In een DevOps-proces gaan veranderingen continu van ontwikkeling naar testen naar implementatie, wat niet alleen leidt tot snellere releases, maar ook tot een product van hogere kwaliteit. Dit betekent dat je in je hele pipeline geautomatiseerde tests moet uitvoeren, inclusief eenheidstests die bij elke buildwijziging worden uitgevoerd, smoke-tests, functionele tests en end-to-end tests.

Continue monitoring is een andere belangrijke component van continue feedback. Een DevOps-aanpak omvat het gebruik van continue monitoring in staging-, test- en zelfs ontwikkelingsomgevingen. Het is soms handig om pre-productieomgevingen te monitoren op abnormaal gedrag, maar over het algemeen is dit een benadering die wordt gebruikt om continu de gezondheid en prestaties van toepassingen in de productie te beoordelen.

Er bestaan tal van tools en services om deze functionaliteit te bieden, en dit kan van alles inhouden, van het monitoren van je on-premise of cloudinfrastructuur zoals serverbronnen, netwerken, enz. of de prestaties van je toepassing of de API-interfaces.

Continue activiteiten

Continue activiteiten is een relatief nieuwe en minder gebruikelijke term, en de definities variëren. Een manier om het te interpreteren is als 'continue uptime'. Bijvoorbeeld in het geval van een blauw/groene implementatiestrategie waarin je twee afzonderlijke productieomgevingen hebt: één die 'blauw' is (openbaar toegankelijk) en één die 'groen' is (niet openbaar toegankelijk). In deze situatie zou nieuwe code worden geïmplementeerd in de groene omgeving, en wanneer werd bevestigd dat deze functioneel was, zou een schakelaar worden omgedraaid (meestal op een load-balancer) en zou het verkeer overschakelen van het 'blauwe' systeem naar het 'groene' systeem. Het resultaat is geen downtime voor de eindgebruikers.

Een andere manier om aan continue activiteiten te denken is continue waarschuwingen. Dit is het idee dat technisch personeel aanwezig is en op afroep de hoogte wordt gesteld als er prestatieafwijkingen in de toepassing of infrastructuur optreden. In de meeste gevallen gaat continue waarschuwingen hand in hand met continue monitoring.

Conclusie...


DevOps gaat over het stroomlijnen van softwareontwikkeling, implementatie en bedrijfsvoering. De DevOps-pipeline is hoe deze ideeën in de praktijk worden geïmplementeerd en 'continue alles' is hoe we dit gaan doen, van code-integratie tot applicatiebewerkingen.

Bekijk voor meer informatie over continue levering onze tutorials voor continue levering met Bitbucket, waarmee je kunt builden, testen en implementeren met geïntegreerde CI/CD. Deze tutorials helpen de beginner en de professional om continue levering te bereiken met Bitbucket. Wil je meteen beginnen? Ga gratis aan de slag met Bitbucket Pipelines.

Tom Hall
Tom Hall

Tom Hall is een DevOps-voorstander en -uitvoerder, leest alles wat los en vast zit en speelt piano.
Hij heeft in de afgelopen 20 jaar certificeringen behaald voor Novell, EMC, VMware en AWS. Hij was onderdeel van de organisatie van DevOpsDays in Atlanta in 2016 en daarna in Austin, TX.


Deel dit artikel
Volgend onderwerp

Aanbevolen artikelen

Bookmark deze resources voor meer informatie over soorten DevOps-teams of voor voortdurende updates over DevOps bij Atlassian.

Toelichting DevOps

DevOps-community

Toelichting DevOps

Simulatieworkshop

Map-illustratie

Gratis aan de slag

Meld je aan voor onze DevOps-nieuwsbrief

Thank you for signing up