Hoe je DevOps doet

Stap 1 - Kies een component

De eerste stap is om klein te beginnen. Kies een component die momenteel in productie is. De ideale component heeft een eenvoudige codebasis met weinig afhankelijkheden en een minimale infrastructuur. Deze component zal een proefterrein zijn waar het team ervaring op kan doen met het implementeren van DevOps.

Stap 2 - Denk er over na om een agile methodologie toe te passen, zoals scrum

DevOps gaat vaak gepaard met een agile werkmethode, zoals scrum. Het is niet nodig om alle rituelen en werkwijzen toe te passen die geassocieerd zijn met een methode zoals scrum. Drie elementen van scrum die over het algemeen gemakkelijk toe te passen zijn en snel waarde opleveren zijn de backlog, de sprint en de sprintplanning.

Een DevOps-team kan werk aan een scrumbacklog toevoegen en prioriteren en vervolgens onderdelen ervan in een sprint opnemen, een vaste tijdsduur om een specifiek gedeelte te voltooien. Sprintplanning is het proces waarbij wordt bepaald welke taken van de backlog naar de volgende sprint gaan.

Stap 3 - Bronbeheer op basis van GIT gebruiken

Versiebeheer is een DevOps-best practice die betere samenwerking en snellere releasecycli mogelijk maakt. Met tools zoals Bitbucket kunnen ontwikkelaars software delen, er aan samenwerken, samenvoegen en er een back-up van maken.

Kies een branching-model. Dit artikel geeft een overzicht van het concept. GitHub flow is een goed beginpunt voor teams die nieuw zijn bij Git, omdat het eenvoudig te begrijpen en te implementeren is. Trunk-gebaseerde ontwikkeling krijgt vaak de voorkeur, maar vergt meer discipline en maakt de eerste kennismaking met Git moeilijker.

Stap 4 - Integreer bronbeheer met het bijhouden van werk

Integreer de tool voor bronbeheer met de tool voor het bijhouden van werk. Door op één plek overzicht te kunnen houden op alles wat met een bepaald project te maken heeft, kunnen ontwikkelaars en management een aanzienlijke hoeveelheid tijd besparen. Hieronder staat een voorbeeld van een Jira-issue met updates vanuit een op Git-gebaseerde repository voor bronbeheer. Jira-issues omvatten een ontwikkelingssectie waarin het werk samen wordt gevoegd dat is verricht voor de Jira-issue op het gebied van bronbeheer. Deze issue had één branch, zes commits, één pull request en één build.

Stap 5 - Tests schrijven

CI/CD-pipelines moeten worden getest om te valideren dat de code die in verschillende omgevingen wordt geïmplementeerd, correct werkt. Begin met het schrijven van unittests voor de code. Hoewel het een ambitieuze doelstelling is om 90 procent codedekking te hebben, is dit in het begin niet realistisch. Stel een lage basismeting in voor de codedekking en verhoog geleidelijk de lat voor de dekking van unittests. Je kunt werkitems aan de backlog toevoegen om dit aan te pakken.

Gebruik testgestuurde ontwikkeling bij het fixen van bugs in de productiecode. Als je een bug ontdekt, schrijf dan unittests, integratietests en/of systeemtests die niet werken in omgevingen waar de bug zich voordoet. Fix vervolgens de bug en kijk of de tests nu wel slagen. Dit proces zal op organische wijze de dekking van de code na verloop van tijd vergroten. Als de bug werd ontdekt tijdens een test of in een testomgeving, zullen de tests erop wijzen dat de code naar behoren werkt wanneer deze in productie kan.

Als je vanaf het begin begint, is deze stap arbeidsintensief, maar belangrijk. Door tests kunnen teams zien wat het effect is van codewijzigingen op het gedrag van het systeem voordat ze eindgebruikers blootstellen aan die codewijzigingen.

Unittests

Unittests bevestigen dat de broncode juist is en moeten als een van de eerste stappen in een CI/CD-pipeline worden uitgevoerd. Ontwikkelaars zouden tests moeten schrijven voor het groene pad, problematische invoer en bekende randgevallen. Bij het schrijven van de tests kunnen ontwikkelaars de inputs en verwachte outputs namaken en uitproberen.

Integratietests

Integratietests verifiëren dat twee componenten correct met elkaar communiceren. Maak de inputs en verwachte outputs na. Deze tests zijn een van de eerste stappen van een CI/CD-pipeline voordat ze in een omgeving worden geïmplementeerd. Deze tests moeten doorgaans uitgebreider worden uitgeprobeerd dan unittests om ze goed aan het werk te krijgen.

Systeemtests

Systeemtests verifiëren de end-to-end prestaties van het systeem en geven zekerheid dat het systeem in elke omgeving werkt zoals verwacht. Maak de invoer na die een component zou kunnen ontvangen en het systeem zou kunnen uitvoeren. Controleer vervolgens of het systeem de vereiste waarden teruggeeft en de rest van het systeem correct wordt bijgewerkt. Deze tests moeten na de implementatie in elke omgeving worden uitgevoerd.

Stap 6 - Een CI/CD-proces bouwen om de component te kunnen implementeren

Overweeg om in meerdere omgevingen te implementeren bij het bouwen van een CI/CD-pipeline. Dingen kunnen niet meer worden aangepast als een team een CI/CD-pipeline bouwt die in slechts één omgeving kan worden geïmplementeerd. Het is belangrijk om CI/CD-pipelines te bouwen voor infrastructuur en code. Begin met het bouwen van een CI/CD-pipeline om in elke omgeving de nodige infrastructuur te implementeren. Bouw vervolgens een nieuwe CI/CD-pipeline om de code te implementeren.

Pipeline structuur

Deze pipeline begint met het uitvoeren van unittests en integratietests voordat in de testomgeving wordt geïmplementeerd. Systeemtests worden uitgevoerd na implementatie in een omgeving.

Infrastructuur

Verschillen in infrastructuur tussen omgevingen maken het moeilijk voor de software die in die omgeving draait om correct uitgevoerd te worden. Firewallregels, gebruikersrechten, toegang tot databases en andere onderdelen op infrastructuurniveau moeten zich in een bekende configuratie bevinden om de software goed te laten werken. Het kan lastig zijn om handmatige implementatie van een infrastructuur correct te herhalen. Aangezien dit proces uit vele stappen bestaat, kan het tot fouten leiden als niet elke stap in de juiste volgorde en met de juiste parameters wordt uitgevoerd. Infrastructuur moet waar mogelijk in de code worden gedefinieerd om deze en andere problemen op te lossen.

Infrastructuur kan in de code worden gedefinieerd met verschillende tools, waaronder AWS CloudFormation, Terraform, Ansible, Puppet of Chef.

Schrijf meerdere pipelines om de infrastructuur te kunnen implementeren. Net zoals het schrijven van code, is het nuttig om de implementatie van de infrastructuur modulair te houden. Verdeel de vereiste infrastructuur waar mogelijk in afzonderlijke subsets. Stel dat A, B, C en D abstracties zijn van infrastructuurcomponenten die van elkaar afhankelijk kunnen zijn. A kan bijvoorbeeld een EC2-box zijn en B een S3-bucket. Afhankelijkheden waarbij een infrastructuurcomponent A — en alleen A — afhankelijk is van component B, moeten waarschijnlijk samen in dezelfde CI/CD-pipeline worden gehouden. Afhankelijkheden waarbij A, B en C afhankelijk zijn van D — maar A, B en C onafhankelijk zijn — moeten worden opgedeeld in meerdere CI/CD-pipelines. In dit geval zijn er dan vier onafhankelijke pijpleidingen. In dit geval moet je één pipeline bouwen voor D waar alle andere drie componenten afhankelijk van zijn, en één voor elk van A, B en C.

CODE

CI/CD-pipelines zijn gebouwd om code te implementeren. Deze pipelines zijn doorgaans eenvoudig te implementeren, aangezien de infrastructuur al beschikbaar is vanwege eerder werk dat is gedaan. Belangrijke overwegingen hierbij zijn testen, herhaalbaarheid en de mogelijkheid voor herstel na een slechte implementatie.

Herhaalbaarheid is de mogelijkheid om dezelfde verandering meerdere keren te kunnen implementeren zonder het systeem te beschadigen. De implementatie moet herintredend en idempotent zijn. Een implementatie moet de status van een systeem instellen op een bekende configuratie in plaats van een wijziging toe te passen op de bestaande status. Het toepassen van een wijziging kan niet herhaald worden, aangezien na de eerste implementatie de noodzakelijke beginstatus om de wijziging goed te laten functioneren is gewijzigd.

Een eenvoudig voorbeeld van een niet-herhaalbare update is het updaten van een configuratiebestand door er gegevens aan toe te voegen. Voeg geen rijen toe aan configuratiebestanden of dergelijke wijzigingstechnieken. Het configuratiebestand kan uiteindelijk tientallen duplicaatrijen krijgen als de updates via toevoegen worden uitgevoerd. Vervang in plaats daarvan het configuratiebestand door een correct geschreven bestand uit het bronbeheer.

Dit principe moet ook worden toegepast op het bijwerken van databases. Database-updates kunnen problematisch zijn en vereisen aandacht voor detail. Het is belangrijk om het updateproces van de database herhaalbaar en storingstolerant te maken. Maak meteen vóór het aanbrengen van wijzigingen een back-up zodat herstel mogelijk is.

Iets anders dat je moet overwegen is hoe je kunt herstellen van een slechte implementatie. Of de implementatie nou is mislukt en het systeem zich in een onbekende toestand bevindt, of dat de implementatie is geslaagd, in beide gevallen worden er alarmen geactiveerd en beginnen probleemtickets binnen te stromen. Er zijn twee standaard manieren om hiermee om te gaan. De eerste is terugdraaien door middel van een rollback. De tweede is om functievlaggen te gebruiken en de nodige vlaggen uit te schakelen om terug te keren naar een bekende goede staat. Bekijk stap 8 van dit artikel voor meer informatie over functievlaggen.

Een rollback implementeert de eerder bekende goede toestand in een omgeving nadat een slechte implementatie is vastgesteld. Hiervoor zou in het begin moeten worden gepland. Maak een back-up voordat je een database wijzigt. Zorg ervoor dat je snel de vorige versie van de code kunt implementeren. Test het rollbackproces regelmatig in een test- of testomgeving.

Stap 7 - Monitoring, alarmen en instrumentatie toevoegen

Een DevOps-team moet het gedrag van de actieve applicatie in elke omgeving monitoren. Staan er fouten in de logs? Is er een time-out voor API-calls? Crashen databases? Controleer elke component van het systeem op problemen. Als de controle een probleem detecteert, dien dan een probleemticket in zodat iemand het probleem kan oplossen. Schrijf als onderdeel van de oplossing aanvullende tests om het probleem op te sporen.

Bugs fixen

Het controleren en oplossen van problemen maakt deel uit van het draaien van productiesoftware. Een team met een DevOps-cultuur heeft eigendom over de werking van de software en leent het gedrag van een Site-Reliability Engineer (SRE). Voer een analyse uit op de hoofdoorzaak van het probleem, voer tests uit om het probleem op te sporen, te fixen en te controleren of de tests nu succesvol zijn. Dit proces is op het eerste gezicht vaak omslachtig, maar werpt op de lange termijn vruchten af, aangezien het de technische schulden vermindert en de operationele flexibiliteit behouden blijft.

Optimalisatie van de prestaties

Zodra de basis-gezondheidsmonitoring is opgezet, volgt meestal het afstemmen van prestaties. Kijk hoe elk onderdeel van een systeem werkt en optimaliseer de trage onderdelen. Zoals Knuth opmerkte: "Voortijdige optimalisatie is de oorzaak van al het kwaad." Optimaliseer niet de prestaties van alles in het systeem. Optimaliseer alleen de traagste en duurste stukken. Controleren helpt met vaststellen welke componenten traag en duur zijn.

Stap 8 - Gebruik functievlaggen om proefkonijntests uit te voeren

Om de proefkonijntesten mogelijk te maken, moet je voor elke nieuwe functie een functievlag plaatsen met een lijst met toegestane testgebruikers. De nieuwe functiecode is alleen geldig voor de gebruikers op de toegestane gebruikerslijst zodra deze in een omgeving is geïmplementeerd. Laat de nieuwe functie doordringen in elke omgeving voordat je deze promoot naar de volgende. Besteed aandacht aan statistieken, alarmen en andere instrumenten voor tekenen van problemen terwijl de nieuwe functie doordringt in een nieuwe regio. Let vooral op een stijging van het aantal nieuwe probleemtickets.

Pak problemen aan in een omgeving voordat je ze promoveert naar de volgende omgeving. Problemen die in de productieomgevingen worden gevonden moeten op dezelfde manier worden behandeld als problemen in test of testomgevingen. Zodra je de hoofdoorzaak van het probleem hebt vastgesteld, schrijf je tests om het probleem te identificeren, voer je een oplossing uit, controleer je of de tests geslaagd zijn en promoot je de oplossing via de CI/CD-pipeline. De nieuwe tests zullen slagen en het aantal probleemtickets zal dalen terwijl de wijziging doordringt in de omgeving waar het probleem werd vastgesteld.