Leestijd : 3 minuten
Veel organisaties zijn actief bezig met de transitie naar een DevOps strategie. Hoewel DevOps een veel gebruikte methode is binnen de softwareontwikkeling is het wellicht een nieuwe aanpak voor andere afdelingen zoals bijvoorbeeld de wekplek beheer binnen een organisatie. Zo lopen veel organisaties tegen verschillende uitdagingen bij de adoptie van de DevOps strategie binnen deze afdelingen. In deze blog post voorzien we je van 5 tips voor een betere adoptie van een DevOps strategie.
Voor diegene die nog niet bekend zijn met DevOps, DevOps is een set van middelen voor het combineren van software development (Dev) en IT-operations (Ops). Het is bedoeld voor het inkorten van de development lifecycle en intoduceert ook nieuwe manieren van werken zoals bijvoorbeeld continous delivery. Meer informatie over DevOps is hier te vinden.
1. Think big but start small
Desondanks de werkplek relatief simpel in gebruik is, komen er veel verschillende componenten bij kijken. In combinatie met het formaat van de organisatie moet je met verschillende zaken en afhankelijkheden rekening houden. Het is met die reden cruciaal om een hoog-over doel te hebben wat te bereiken met de DevOps strategie binnen de afdeling. Gezien de hoge mate van verandering van de verschillende componenten, is het daarom zeer belangrijk om de wendbaarheid (agility) zo veel mogelijk te verhogen.
Voor een werkplek strategie zal de focus liggen bij het automatiseren van de gehele infrastructuur. Hierdoor is het mogelijk om de gehele omgeving opnieuw op te bouwen zonder enige interactie van een medewerker. Dit zal het ultieme doel zijn waardoor de afdeling zich kan richten op het verhelpen van eventuele problemen en het iteratief toevoegen van nieuwe functionaliteiten.
Het is niet realistisch om het einddoel in een keer te realiseren. Helemaal binnen een werkplek omgeving zijn er verschillende componenten vereist voor de werking. Het is cruciaal om klein te beginnen om zo iteratief het einddoel te bereiken. Hierdoor zal het team kleine mijlpalen behalen en bekender worden met de verschillende (nieuwe) technieken binnen DevOps.
2. Alles in code
Voor sommigen zal dit misschien afschrikken maar ‘code’ is de core van een goede DevOps strategie. Met behulp van code is het mogelijk om alles te automatiseren binnen de werkplek omgeving. Alle DevOps oplossingen bevatten Git of een vergelijkbaar versiebeheersysteem. Door het gebruik van een versiebeheersysteem, zoals Git, zijn alle wijzigingen binnen de code inzichtelijk en traceerbaar. Voor het correct gebruik van Git is het advies om de juiste informatie op het internet te zoeken, zoals de volgende instructie video.
Learn Git In 15 Minutes – YouTube
Ervaring leert dat de learning curve best hoog is voor mensen die nooit gebruik hebbengemaakt van Git, en met die reden is de juiste begeleiding cruciaal.
Binnen veel DevOps oplossing wordt er ook gebruik gemaakt van Markdown. Markdown is een markup taal voor het formatteren van tekst. Het is vergelijkbaar met HTML, maar dan vele malen minder complex en is hierdoor gemakkelijk en snel op te pakken. Hierdoor is het mogelijk om ook direct documentatie op te nemen binnen de Git repository. Documentatie is door vele gezien als vervelend of niet noodzakelijk. Het is daarom belangrijk om allen relevante informatie op te nemen. Ervaring leert dat een detail level ontwerp vrijwel nooit meer gebruikt wordt en gezien de tijd en energie zonde is van de tijd. Met behulp van Markdown Architectural Decision Record, kan de structuur opgenomen worden voor het bijhouden van architecturale keuzes, wat het belangrijkste onderdeel is van documentatie.
3. Git strategie
Zoals in de vorige tip benoemd gaat het allemaal om de code. Code wordt opgeslagenin een versiebeheersysteem zoals Git. Git is dan ook de meest voorkomende oplossing binnen veel DevOps oplossingen. Desondanks dit nu specifiek om Git gaat, is dit van toepassing voor elke type versiebeheersysteem.
Binnen Git is het belangrijk om een goede strategie te benoemen betreft het gebruik van Git. Denk dan de structuur van je code repository maar ook hoe om te gaan met branches. Een branch is een aftakking dan wel een kopie van de code. Het is gebruikelijk binnen een werkplek omgeving om DTAP omgeving te hebben. Met behulp van branches is het mogelijk om een branch te hebben voor development, test, acceptatie en productie. Nieuwe functionaliteiten dan wel deployment zullen ontwikkelt worden in de development omgeving. Zodra de functionaliteit succesvol is deployed dan wel getest kan door middel van een merge of nog beter een pull request de code doorgezet worden naar test. Na het testen in de testomgeving gaat de code door naar acceptatie en als laatst naar productie.
De term pull request zal vaak binnen DevOps voorbijkomen, dit is een methode om wijzigingen binnen zowel de code als documentatie te reviewen. Helemaal in de tijd van remote werken is het een zeer prettige manier om de interactie aan te gaan over de inhoud. Met die reden is het advies om pull requests mee te nemen in de implementatie van de DevOps oplossing.
Er zijn verschillende uitgewerkte strategien beschikbaar op het internet en het advies is ook om goed in te lezen en een te adopteren binnen de omgeving. Een veel gebruikte strategie is GitFlow en is altijd een goed startpunt.
4. Pipelines
Mocht je in aanraking zijn gekomen met DevOps dan zal vast de term pipeline bekent voorkomen. Binnen alle DevOps oplossingen zit een pipeline of vergelijkbare mechanisme verwerkt om een stappenplan te doorlopen. In het stappenplan is het dus mogelijk om allerlei acties uit te voeren zoals het bouwen van een applicatie of in het geval van een werkplek omgeving, een machine uit te rollen en te configureren. De pipeline is dus de gehele motor om alle geautomatiseerd uit te rollen.
Bij het gebruik van een pipeline zijn een aantal principes belangrijk om rekening mee te houden. Maak de logica van de automation op een generieke manier zodat het bruikbaar is binnen de verschillende omgeving in de DTAP straat. Binnen de pipeline is het mogelijk om gebruik te maken van verschillende variabelen, onder andere de huidige branch. Met deze methode is het mogelijk om één pipeline te gebruiken voor alle deployments. Let hierbij wel op hoe de pipeline daadwerkelijk is opgeslagen binnen de omgeving. Binnen Azure DevOps zal een YAML gebaseerde pipeline in de Git repository worden opgeslagen. Hierdoor kan de branching strategie worden gebruikt om wijziging in de pipeline door te voeren. Indien de oplossing dit niet kan, is het verstandig om onderscheid te maken tussen de verschillende omgevingen.
5. Continous delivery
Binnen een traditioneel werkplek bouwtraject kan het soms maanden duren totdat een werkplek daadwerkelijk is opgeleverd. Dit is dan ookwel bekend als een waterval aanpak. Het bouwen gaat per component en zodra het staat is de taak van de beheerder om regulier beheer op uit te voeren. Onderdeel van de DevOps mindset is continuous delivery. Zoals eerder benoemt moet het op elk moment van de dag mogelijk zijn om de volledige omgeving op te bouwen zonder enige interactie van een persoon. Zo zou het in theorie mogelijk zijn om elke nacht de volledige omgeving opnieuw klaar te zetten zodat alles identiek en compliant is. Dit is geheel in lijn met een “immutable infrattrucutre” of “infrastrucure as code” strategie. Wellicht gaat dat net iets te ver als startpunt, maar het is een goed steven als einddoel. Met de mindset om op elk moment te kunnen deployment creëer je de mogelijkheid om continue kleine onderdelen te releasen. Zo creëer je de wendbaarheid (agility) om snel te voldoen aan eventuele nieuwe wensen en eisen van de klant.
Conclusie
DevOps is niet alleen een toolset maar ook een mindset welke moet gaan leven binnen de organisatie voordat er daadwerkelijk waarde behaald kan worden met DevOps. Bovenstaande tips zijn een aantal aandachtspunten om rekening mee te houden bij het implementeren van DevOps binnen een werkplek omgeving. Geduld en begrip voor het leren van iets nieuws is daarbij zeer belangrijk, gezien de materie voor sommige nieuw en complex kan zijn.
Het is daarom belangrijk om ook goed te kijken naar de toolset binnen de organisatie. Het mag nooit zo zijn dat tools en andere middelen een beperking zijn bij het uitvoeren van je werk, helemaal als die het DevOps werk tegenhouden. Indien de toolset een beperking is, zal de adoptie alleen maar lastiger worden.
Afhankelijk van de werkmethodes binnen de organisatie kan het verstandig zijn om een Agile framework als SCRUM of Kanban te adopteren. Een belangrijk onderdeel van zo’n framework zijn de reviews. Dit is een ceremonie om aan verschillende stakeholder te laten zien wat de afgelopen iteratie is opgeleverd. Afhankelijk van het formaat van de organisatie is dit ook een mooi moment inzicht te krijgen wat andere afdelingen aan het doen zijn. Naast de review is de retrospective een belangrijk onderdeel om niet alleen het process, maar ook de mensen continue te verbeteren in hun werk.
Wil je meer weten over het gebruik van DevOps of eventueel hulp nodig? Vind hier meer informatie wat we vanuit RawWorks kunnen betekenen.
