DevOps Handleiding: Docker, Kubernetes en Azure DevOps

In dit artikel zullen we meer leren over DevOps en hoe het verschilt van de Agile methodologie. We zullen ook enkele populaire DevOps-tools behandelen en hun rollen in de DevOps-levenscyclus.

Je Zult Leren

• Wat is Docker, Kubernetes en Azure DevOps
• Wat is DevOps en waarom hebben we het nodig?
• Hoe verschilt DevOps van Agile?
• Wat zijn enkele belangrijke DevOps-tools?
• Hoe helpt Docker bij DevOps?
• Hoe helpt Kubernetes bij DevOps?
• Hoe helpt Azure DevOps bij DevOps?
• Wat is Continue Integratie en Continue Levering (CI/CD)?
• Wat is Infrastructuur als Code?
• Hoe helpen Terraform en Ansible bij DevOps?

Docker

Docker is een open-source softwaretool die wordt gebruikt om containerized applicaties te bouwen, testen en implementeren. Wat is Containerisatie, trouwens? Containerisatie is het concept om alle bibliotheken en bestanden samen met de applicatiecode te bundelen in een enkele eenheid genaamd een “Container” zodat het op elke infrastructuur kan draaien.

Kubernetes

Kubernetes is een containerorkestratiesysteem dat containergebaseerde applicaties en services beheert. Het zorgt voor de taken die worden uitgevoerd in de containeromgeving, zoals schaling, implementatie, load balancing, enzovoort. Kubernetes is draagbaar, efficiënt en kosteneffectief, en biedt functies zoals systeemintegraties, API-gebaseerde ondersteuning, enzovoort.

Azure DevOps is een Microsoft-product dat een breed scala aan tools en functies biedt die het proces van softwareontwikkeling en -implementatie sneller en georganiseerder maken. Het biedt een set processen die softwareontwikkelaars, projectmanagers en andere bijdragers in staat stelt om samen te werken aan de ontwikkeling van software. Het kan worden toegevoegd aan de bestaande editors of IDE’s om het team effectief te laten werken aan projecten van alle groottes.

Laten we beginnen met een eenvoudig gebruiksvoorbeeld.

Gratis Cursussen — Leer in 10 Stappen

• Leer Docker in 10 Stappen
• Leer Kubernetes in 10 Stappen
• Leer AWS in 10 Stappen

Wat is DevOps?

Net als bij de meeste buzzwords rond softwareontwikkeling is er geen geaccepteerde definitie voor DevOps.

Definities variëren van eenvoudig, zoals degene hieronder, tot complex, wat een hele pagina van een boek kan beslaan.

DevOps is de combinatie van culturele filosofieën, praktijken en tools die de mogelijkheid van een organisatie vergroten om applicaties en services af te leveren met hoge snelheid — Amazon Web Services (AWS)

In plaats van te proberen DevOps te definiëren, laten we begrijpen hoe softwareontwikkeling is geëvolueerd naar DevOps.

Watervalmodel

Het Watervalmodel is een methodologie die een gestructureerde aanpak volgt. Het bestaat uit zes fasen: Eisen, Ontwerp, Implementatie, Testen, Implementatie en Onderhoud. Elke fase bouwt voort op de voltooiing van de vorige. Het vordert door deze fasen zonder eerdere processen opnieuw te bezoeken, waardoor het een lineair proces is.

De eerste paar decennia van softwareontwikkeling draaiden om het Watervalmodel, en het benaderde softwareontwikkeling op dezelfde manier als je een vastgoedproject zou benaderen — bijvoorbeeld het bouwen van een brug.

Je zult software bouwen in meerdere fasen die kunnen variëren van een paar weken tot een paar maanden.

In de meeste watervalprojecten zou het maanden duren voordat het bedrijf een werkende versie van een applicatie ziet.

Belangrijke elementen om geweldige software te bouwen

Tijdens het werken in het watervalmodel gedurende enkele decennia, begrijpen we een paar belangrijke elementen rond het ontwikkelen van geweldige software:

• Communicatie
• Feedback
• Automatisering

Belang van Communicatie

Communicatie tussen mensen is essentieel voor het succes van een softwareproject.

In het Watervalmodel probeerden we de communicatie te verbeteren door 1000 pagina’s documenten te maken over Vereisten, Ontwerp, Architectuur en Implementatie.

Maar, in de loop van de tijd ontdekten we dat:

• De beste manier om communicatie binnen een team te verbeteren is door ze bij elkaar te brengen. En een verscheidenheid aan vaardigheden in hetzelfde team te hebben.
• Teams met verschillende vaardigheden werken geweldig.

Belang van Vroegtijdige Feedback

Snel feedback krijgen is belangrijk. Het bouwen van geweldige software draait allemaal om het krijgen van snelle feedback.

• Bouwen we een applicatie die voldoet aan de verwachtingen van het bedrijf?
• Zal uw applicatie problemen hebben als deze wordt geïmplementeerd?

Je wilt het niet pas na een paar maanden weten. Je wilt er zo vroeg mogelijk achter komen, want hoe eerder we een probleem ontdekken, hoe makkelijker het is om het op te lossen.

We hebben ontdekt dat de beste softwareteams zijn gestructureerd om snelle feedback mogelijk te maken.

Belang van Automatisering

Automatisering is essentieel. Softwareontwikkeling omvat een breed scala aan activiteiten. Handmatig werken is traag en foutgevoelig. We begrijpen dat het essentieel is om altijd te zoeken naar mogelijkheden om automatisering te introduceren.

Na het begrijpen van de belangrijkste elementen om geweldige software te ontwikkelen, laten we eens kijken hoe we geëvolueerd zijn naar Agile en DevOps.

Evolutie naar Agile

Agile is een aanpak die de nadruk legt op incrementele vooruitgang, frequente feedback en het vermogen om te reageren op veranderende vereisten gedurende de ontwikkelingslevenscyclus. Agile bevordert cross-functionele teams om te werken in korte ontwikkelingscycli, wat continue verbetering bevordert en snel waarde levert aan eindgebruikers. Het was de eerste stap in de evolutie naar het implementeren van onze lessen met verbeterde communicatie tussen teams, het verkrijgen van feedback en het implementeren van automatisering.

Agile bracht de zakelijke en ontwikkelingsteams samen in één team, dat werkt aan het bouwen van geweldige software in kleine iteraties genaamd Sprints.

In plaats van weken of maanden te besteden aan elke fase van ontwikkeling, richt Agile zich op het doorlopen van kleine vereisten genaamd gebruikersverhalen door de ontwikkelingscyclus binnen enkele dagen, soms zelfs binnen dezelfde dag.

Hoe heeft Agile de communicatie tussen teams verbeterd?

Agile bracht zakelijke en ontwikkelingsteams bij elkaar.

• Bedrijven zijn verantwoordelijk voor het definiëren van wat er gebouwd moet worden. Wat zijn de vereisten?
• Ontwikkeling is verantwoordelijk voor het bouwen van een product dat voldoet aan de vereisten. Ontwikkeling omvat iedereen die betrokken is bij het ontwerp, codering, testen en verpakken van uw software.

In Agile is er altijd een vertegenwoordiger van het bedrijf, genaamd een Product Owner, aanwezig bij het team, en het team begrijpt duidelijk de zakelijke doelstellingen.

Wanneer het ontwikkelingsteam de vereisten niet begrijpt en de verkeerde weg inslaat, helpt de Product Owner hen om bij te sturen en op het juiste pad te blijven.

Resultaat: Het uiteindelijke product dat het team bouwt is iets wat het bedrijf wil.

Een ander belangrijk aspect is dat agile teams beschikken over cross-functionele vaardigheden: programmeervaardigheden (frontend, API en databases), testvaardigheden en zakelijke vaardigheden. Dit verbetert de communicatie tussen mensen die samen moeten werken om geweldige software te bouwen.

Agile en Automatisering

Op welke gebieden richt agile teams zich op automatisering?

Softwareproducten kunnen verschillende defecten hebben:

• Functionele defecten betekenen dat het product niet werkt zoals verwacht.
• Technische defecten maken het onderhoud van de software moeilijk. Bijvoorbeeld codekwaliteitsproblemen.

In het algemeen richten agile teams zich op het gebruik van automatisering om technische en functionele defecten zo vroeg mogelijk te vinden.

Agile teams richten zich ook uitgebreid op codekwaliteit. Tools zoals SONAR worden gebruikt om de codekwaliteit van applicaties te beoordelen.

Is het voldoende als je geweldige automatiseringstests en geweldige codekwaliteitscontroles hebt? De sleutel is om deze processen regelmatig uit te voeren. Agile teams benadrukken Continuous Integration, waarbij commits naar versiebeheer een reeks acties activeren. Dit omvat het uitvoeren van unit tests, automatiseringstests en codekwaliteitscontroles, allemaal naadloos geïntegreerd in een Continuous Integration Pipeline. Jenkins, een veelgebruikte CI/CD-tool tijdens het begin van het Agile-tijdperk, speelde een cruciale rol bij het orchestreren van deze geautomatiseerde processen.

Hoe Bevorderde Agile Directe Feedback?

Het belangrijkste is dat een bedrijf niet maanden hoeft te wachten om het eindproduct te zien. Aan het einde van elke sprint wordt het product gedemonstreerd aan alle belanghebbenden, inclusief architectuur- en bedrijfsteams. Alle feedback wordt verzameld terwijl gebruikersverhalen worden geprioriteerd voor de volgende sprint. Resultaat: het uiteindelijke product dat het team bouwt, is iets wat het bedrijf wil.

Nog een belangrijke factor die directe feedback mogelijk maakt, is continue integratie. Stel dat ik wat code commit naar versiebeheer. Binnen 30 minuten krijg ik feedback als mijn code een fout veroorzaakt in een unit test of een integratietest. Ik krijg feedback als mijn code niet voldoet aan de codekwaliteitsnormen of niet voldoende code dekt in de unit tests.

Was Agile succesvol? Ja. Absoluut. Door te focussen op het verbeteren van de communicatie tussen bedrijfs- en ontwikkelingsteams, en te focussen op het vroegtijdig vinden van een verscheidenheid aan fouten, bracht Agile softwareontwikkeling naar een hoger niveau.

Ik had een geweldige ervaring met het werken met fantastische teams die Agile gebruikten. Software engineering, wat voor mij alle inspanningen vertegenwoordigt bij het bouwen van software van vereisten tot het live brengen van applicaties, was voor het eerst net zo plezierig als programmeren.

Maar stopt de evolutie? Nee.

Nieuwe uitdagingen kwamen naar voren.

Evolutie van Microservices Architecturen

We begonnen over te stappen naar een microservices architectuur, en we begonnen meerdere kleine API’s te bouwen in plaats van grote monolithische applicaties.

Wat was de nieuwe uitdaging?

Operations zijn belangrijker geworden. In plaats van één maandelijkse monolithische release, voer je honderden kleine microservice releases per week uit. Problemen oplossen over meerdere microservices en inzicht krijgen in wat er gebeurt met de microservices werd belangrijk.

Het was tijd voor een nieuwe buzzword in softwareontwikkeling. DevOps.

Opkomst van DevOps

Wat was de focus van DevOps?

De focus van DevOps was om de communicatie tussen de ontwikkelings- en operationele teams te verbeteren.

• Hoe maken we implementaties eenvoudiger?
• Hoe maken we het werk van het operationele team zichtbaarder voor het ontwikkelingsteam?

Hoe Heeft DevOps de Communicatie Tussen Teams Verbeterd?

DevOps bracht operationele teams dichter bij ontwikkelingsteams.

• In meer volwassen bedrijven werkten ontwikkelings- en operationele teams als één team. Ze begonnen gemeenschappelijke doelen te delen en beide teams begonnen de uitdagingen te begrijpen waarmee het andere team te maken had.
• In bedrijven in de beginfase van de DevOps-evolutie kan een vertegenwoordiger van het operationele team betrokken zijn bij de sprints – stand-ups en retrospectieven.

Op welke automatiseringsgebieden richten DevOps-teams zich?

Naast de focusgebieden van Agile – continue integratie en testautomatisering – richtten DevOps-teams zich op het helpen automatiseren van verschillende activiteiten van operationele teams, zoals het voorzien van servers, het configureren van software op servers, het implementeren van applicaties en het monitoren van productieomgevingen. Enkele belangrijke terminologieën zijn continue implementatie, continue levering en infrastructuur als code.

Continue implementatie draait om het continu implementeren van een nieuwe versie van software op testomgevingen. In nog meer volwassen organisaties zoals Google en Facebook helpt continue levering bij het continu implementeren van software naar productie – misschien honderden productie-implementaties per dag.

Infrastructuur als code draait om het behandelen van uw infrastructuur zoals u uw toepassingscode behandelt. U maakt uw infrastructuur – servers, load balancers en database – op geautomatiseerde wijze aan met configuratie. U zou uw infrastructuur versiebeheer gebruiken – zodat u uw infrastructuurwijzigingen in de loop van de tijd kunt volgen.

Hoe promootte DevOps directe feedback?

DevOps brengt operatie- en ontwikkelingsteams samen. Omdat operaties en ontwikkeling deel uitmaken van hetzelfde team, begrijpt het hele team de uitdagingen die gepaard gaan met operaties en ontwikkeling.

• Eventuele operationele problemen krijgen snel aandacht van ontwikkelaars.
• Eventuele uitdagingen bij het live brengen van software krijgen vroegtijdige aandacht van het operationsteam.

DevOps stimuleert continue integratie, continue levering en infrastructuur als code.

• Door continue levering, als ik een code- of configuratiewijziging maak die een test of een stagingomgeving zou kunnen breken, zou ik dit binnen een paar uur weten.
• Dankzij Infrastructuur als Code kunnen ontwikkelaars zelf omgevingen voorzien, code implementeren en problemen zelfstandig oplossen zonder hulp van het operationsteam.

Ik zie Agile en DevOps als twee fasen die ons helpen om te verbeteren hoe we geweldige software bouwen. Ze concurreren niet met elkaar, maar samen helpen ze ons geweldige softwareproducten te bouwen.

Voor zover ik weet is het doel van Agile en DevOps samen om dingen te doen die:

• Communicatie en feedback tussen bedrijfs-, ontwikkelings- en operationsteams bevorderen
• De pijnpunten verlichten met automatisering.

Een DevOps-verhaal

Hier is een voorbeeldverhaal:

• Jij bent de sterontwikkelaar in een team en je moet snel een fix maken.
• Je gaat naar een GitHub-opslagplaats.
• Je controleert snel het project uit.
• Je creëert snel je lokale omgeving.
• Je maakt een wijziging. Je test het. Je update de unit- en automatiseringstests.
• Je commit het.
• Je krijgt een e-mail waarin staat dat het is geïmplementeerd in QA.
• Een paar integratietests worden automatisch uitgevoerd.
• Je QA-team krijgt een e-mail met het verzoek om goedkeuring. Ze voeren een handmatige test uit en keuren goed.
• Je code staat binnen enkele minuten live in productie.
• Je zou kunnen denken dat dit een ideaal scenario is. Maar weet je dat dit is wat er dag in dag uit gebeurt bij innovatieve bedrijven zoals Netflix, Amazon en Google?

Dit is het verhaal van DevOps.

DevOps = Ontwikkeling + Operaties

DevOps is een natuurlijke evolutie van softwareontwikkeling. DevOps is NIET ALLEEN een tool, een framework of alleen automatisering. Het is een combinatie van al deze zaken.

DevOps richt zich op mensen, processen en producten. Het mensen-gedeelte van DevOps gaat helemaal over cultuur en het creëren van een geweldige mindset – een cultuur die open communicatie bevordert en waarde hecht aan snelle feedback, een cultuur die hoogwaardige software waardeert.

Agile heeft geholpen bij het overbruggen van de kloof tussen bedrijfs- en ontwikkelingsteams. Ontwikkelingsteams begrepen de prioriteiten van het bedrijf en werkten samen met het bedrijf om de verhalen te leveren die de meeste waarde bieden; echter, de ontwikkelings- en operationele teams waren niet op één lijn.

Ze hadden verschillende doelen.

• Het doel van het ontwikkelingsteam is om zoveel mogelijk nieuwe functies naar productie te brengen.
• Het doel van het ops-team was om de productieomgeving zo stabiel mogelijk te houden.

Zoals je kunt zien, als het moeilijk is om zaken naar productie te brengen, zijn dev en ops niet op één lijn.

DevOps streeft ernaar om de dev en ops teams in lijn te brengen met gedeelde doelen.

Het dev team werkt samen met het ops team om operationele uitdagingen te begrijpen en op te lossen. Het ops team maakt deel uit van het scrum team en begrijpt de functies die in ontwikkeling zijn.

Hoe kunnen we dit mogelijk maken? Breek de muur tussen dev en ops af!

De samenwerking tussen Dev en Ops

Optie 1

In volwassen DevOps-ondernemingen werken dev en ops als onderdeel van hetzelfde scrum team en delen elkaars verantwoordelijkheden.

Optie 2

Als je echter in de beginfase van de DevOps-evolutie zit, hoe kun je ervoor zorgen dat dev en ops gemeenschappelijke doelstellingen hebben en samenwerken?

Hier zijn enkele dingen die je kunt doen:

• Laat het ontwikkelingsteam een deel van de verantwoordelijkheden van het operationele team delen. Bijvoorbeeld, het dev team kan verantwoordelijkheid nemen voor nieuwe releases gedurende de eerste week na de productiedeploy. Dit helpt het ontwikkelingsteam de uitdagingen te begrijpen waarmee operations worden geconfronteerd bij het live brengen van nieuwe releases en helpt hen samen te komen en betere oplossingen te vinden.
• Een andere stap die je kunt nemen is het betrekken van een vertegenwoordiger van het operations team bij de scrum-activiteiten. Betrek hen bij stand-ups en retrospectives.
• Het volgende dat je kunt doen, is de uitdagingen waarmee het Operations-team wordt geconfronteerd, zichtbaarder maken voor het Development-team. Wanneer je tegen uitdagingen in de operaties aanloopt, maak dan de ontwikkelingsteams deel uit van de teams die aan oplossingen werken.

Welke weg je ook kiest, vind manieren om de muur te doorbreken en breng het development- en operations-team samen.

Een andere interessante optie komt voort uit automatisering. Door Infrastructure as Code te gebruiken en zelfvoorziening voor ontwikkelaars mogelijk te maken, kun je een gemeenschappelijke taal creëren die door operations- en ontwikkelingsteams wordt begrepen — code.

Een DevOps-geval

Overweeg de onderstaande afbeelding:

Deze afbeelding toont twee eenvoudige workflows

1. Infrastructure as Code met Terraform en Azure DevOps om Kubernetes-clusters te provisioneren.
2. Continue Deployment van microservices met Azure DevOps om Docker-images voor microservices naar Kubernetes-clusters te bouwen en te implementeren.

Klinkt dit complex?

Laten we het opsplitsen en proberen ze te begrijpen.

Laten we beginnen met #2 — Continue Deployment eerst.

#2: DevOps Continue Deployment met Azure DevOps en Jenkins

Wat heeft het voor zin om geweldige tests en codekwaliteitscontroles te hebben als je ze niet vaak uitvoert?

Wat heeft het voor zin om implementatieautomatisering te hebben als je software niet vaak genoeg implementeert?

Zodra een ontwikkelaar code in het versiebeheersysteem commit, worden de volgende stappen uitgevoerd:

• Eenheidstests
• Codekwaliteitscontroles
• Integratietests
• Applicatieverpakking — Het bouwen van een uitrolbare versie van de applicatie. Tools — Maven, Gradle, Docker
• Applicatie-uitrol — Nieuwe applicaties of nieuwe versies van de applicatie live zetten
• Een e-mail naar het testteam om de applicatie te testen

Zodra er goedkeuring is van het testteam, wordt de app onmiddellijk uitgerold naar de volgende omgeving.

Dit wordt continue uitrol genoemd. Als je continu naar productie uitrolt, wordt dit continue levering genoemd.

De populairste CI/CD-tools zijn Azure DevOps en Jenkins.

#1: DevOps Infrastructuur als Code Met Terraform

Vroeger maakten we omgevingen aan en rolden we applicaties handmatig uit.

Elke keer dat je een server aanmaakt, moet dit handmatig gebeuren.

• De softwareversie moet worden bijgewerkt
• Beveiligingspatches moeten handmatig worden geïnstalleerd

Je doet het handmatig, en dit zijn de resultaten:

• Hoge kans op fouten
• Replicatieomgevingen zijn moeilijk

Infrastructuur als Code

Infrastructuur als Code — behandel infrastructuur op dezelfde manier als applicatiecode.

Hier zijn enkele belangrijke zaken om te begrijpen met Infrastructuur als Code:

• Het infra-team richt zich op waarde toevoegend werk (in plaats van routinematig werk)
• Minder fouten en snelle herstel van storingen
• Servers zijn consistent (vermijdt configuratiedrift)

De populairste IaC-tools zijn Ansible en Terraform.

Typisch zijn dit de stappen in IaC:

• Servers Provisioneren (Ingeschakeld door de Cloud) vanuit een sjabloon
• Software installeren
• Software configureren

Server Provisionering

Typisch worden provisioningtools gebruikt om servers te provisioneren en de nieuwe server gereed te maken met netwerkmogelijkheden. De populairste provisioningtools zijn Cloud Formation en Terraform.

Met Terraform kun je servers en de rest van je infrastructuur provisioneren, zoals load balancers, databases, netwerkinstellingen, enz. Je kunt servers creëren met vooraf gemaakte afbeeldingen die zijn gemaakt met tools zoals Packer en AMI (Amazon Machine Image).

Configuratiebeheer

Configuratiebeheertools worden gebruikt om:

• Software installeren
• Software configureren

Populaire configuratiebeheertools zijn Chef, Puppet, Ansible en SaltStack. Deze zijn ontworpen om software te installeren en te beheren op bestaande servers.

Rol van Docker en Kubernetes in DevOps

In de wereld van microservices kunnen enkele microservices zijn gebouwd met Java, enkele met Python en enkele met JavaScript.

Verschillende microservices zullen verschillende manieren hebben om applicaties te bouwen en deze naar servers te implementeren. Dit maakt het werk van het operatieteam moeilijk. Hoe kunnen we een vergelijkbare manier hebben om meerdere soorten applicaties te implementeren? Daar komen containers en Docker om de hoek kijken.

Met Docker kun je afbeeldingen van microservices bouwen — ongeacht hun taal. Je kunt deze afbeeldingen op dezelfde manier draaien op elke infrastructuur. Dit vereenvoudigt de operaties.

Kubernetes voegt hieraan toe door te helpen bij het orchestreren van verschillende soorten containers en deze naar clusters te implementeren.

Kubernetes biedt ook:

• Service discovery
• Load balancing
• Centrale configuratie

Docker en Kubernetes maken DevOps eenvoudig.

Belangrijke DevOps-metrieken

De volgende zijn enkele van de belangrijke DevOps-metrieken die je in de gaten kunt houden en na verloop van tijd kunt verbeteren.

• Implementatiefrequentie — Hoe vaak worden applicaties geïmplementeerd naar productie?
• Tijd tot Markt — Hoe lang duurt het voordat een functie van codering naar productie gaat?
• Foutenpercentage van Nieuwe Releases — Hoeveel van je releases mislukken?
• Doorlooptijd voor Oplossingen — Hoe lang duurt het voordat je een productiefout oplost en implementeert naar productie?
• Gemiddelde Hersteltijd — Hoe lang duurt het voordat je je productieomgeving herstelt van een groot probleem?

DevOps Beste Praktijken

Agile Projectmanagement

Agile projectmanagement is een iteratieve benadering voor het ontwikkelen van softwaretoepassingen. Via deze praktijk kunnen teams de ontwikkelingssnelheid verbeteren en goed reageren op verschillende klantbehoeften. Agile methodologie verschilt van de traditionele Watervalmethode waarbij lange releasecycli waren. Agile maakt gebruik van Scrum- en Kanban-frameworks om de software te leveren volgens de behoeften van de klant.

Het Gebruik van de Juiste Set Tools

Softwareontwikkelaars en systeembeheerders moeten de juiste set DevOps-tools kiezen en gebruiken in elke fase van de DevOps-levenscyclus om waardevolle applicaties te bouwen.

Hieronder staan enkele voorbeelden van tools die DevOps-engineers, systeembeheerders en andere belanghebbenden kunnen gebruiken:

1. Tools zoals Jira kunnen het team helpen taken op te splitsen in kleinere en beter beheersbare stukken, wat helpt om de productiviteit van het team te verhogen.
2. Tools zoals Jenkins en Bitbucket kunnen je helpen om codeflows te automatiseren, van de testfase tot de implementatiefase.
3. Tools zoals Slack, GetFeedback, enz. kunnen DevOps-teams helpen chattools te integreren met enquêteplatforms om realtime feedback te verzamelen en te beoordelen.

Continue Integratie/Continue Levering

Continue Integratie (CI) en Continue Levering (CD) zijn moderne softwareontwikkelingspraktijken die organisaties helpen om software snel en effectief te leveren. Met CI committeren ontwikkelaars continu de applicatiecode in een gedeeld repository, meerdere keren. Met CD wordt de code snel en naadloos naar productie geleverd. CD zorgt er ook voor dat de integratie zonder vertragingen of problemen plaatsvindt.

Integratie van Beveiliging

Beveiliging is een belangrijk onderdeel van het softwareontwikkelingsproces. In de huidige wereld, waar cybercriminaliteit en datalekken in opkomst zijn, realiseren organisaties zich het belang van het integreren van beveiligingen in hun systemen. In het verleden werd beveiliging meestal pas in de laatste fasen van de softwareontwikkelingscyclus overwogen, maar met de opkomst van DevSecOps wordt beveiliging vanaf dag één van de applicatieontwikkeling overwogen en geïntegreerd.

Observability

Observability is belangrijk bij het ontwikkelen van complexe applicaties die gebruikmaken van microservices en cloudarchitecturen. Observability helpt DevOps-teams de complexe structuur van verschillende applicaties (microservices, cloud-apps, enz.) te begrijpen en helpt te voldoen aan de toekomstige behoeften van de omgeving. Kubernetes-observability en Splunk zijn enkele van de beste observability-platforms.

DevOps Volwassenheidssignalen

Hoe meet je de volwassenheid van je DevOps-implementaties?

• De tijd die nodig is van het ontwikkelingsproces tot de implementatie moet over het algemeen bevredigend zijn
• Het bepalen van de frequentie van de implementatie van nieuwe code
• De gemiddelde tijd tot herstel (MTTR) van een incident of onverwachte gebeurtenis moet zo laag mogelijk zijn
• Succesvolle implementaties moeten de mislukte implementaties overtreffen
• Snellere en betrouwbare releases zouden een hoog rendement op investeringen (ROI) moeten opleveren.

Beste praktijken voor DevOps-transformatie

• Leiderschapsbuy-in is cruciaal
• Betreft voorafgaande kosten
• Zet COE’s op om teams te helpen
• Kies de juiste toepassing en team
• Begin klein
• Deel leerervaringen (nieuwsbrieven, communicatie, COE’s)
• Moedig mensen aan met een exploratie- en automatiseringsmentaliteit
• Erken DevOps-teams