DevOps-pipeline

1. 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, betekent dat problemen voor de fabrikant!

2. Continue feedback

Het grootste pijnpunt van de oude watervalmethode voor softwareontwikkeling en waarom agile methodologieën zijn 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.

3. 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.