Sla een brug tussen DevOps en Change Management
De laatste tijd heb ik een kloof zien ontstaan tussen developers en het Change Management-proces. Een kloof die volkomen logisch is, aangezien het changemanagementproces de developers belemmert. Het ondermijnt de ware essentie van DevOps: het verkorten van de time-to-market van producten en verbeteringen (Dev) en het handhaven van product- en procesbeheer (Ops). Het changeproces is echter vaak geen onderdeel van DevOps en wordt daarom weggelaten in de DevOps’ manier van werken. Maar DevOps toepassen zonder Change Management is eigenlijk alleen ‘Dev’ toepassen, waarbij je het ‘Ops’ gedeelte totaal vergeet.
Het probleem
Developers moeten handmatig een change aanvragen voor elke implementatie die ze uitvoeren, wat betekent dat ze minder werk kunnen doen in een Sprint. Bovendien begrijpen de developers de noodzaak van changes niet, omdat alles al in hun commits staat geregistreerd. Vervolgens worden steeds minder changeverzoeken ingediend, wat betekent dat je geleidelijk het overzicht en de controle verliest (de ‘Ops’ in DevOps). Uiteindelijk resulteert dit in auditbevindingen, waardoor het moeilijker wordt om (P1-)incidenten op te sporen en op te lossen of het zou zelfs de oorzaak kunnen zijn.
Standaard changetemplates maakt het al makkelijker voor de developers, maar het dwingt hen nog steeds om hun ‘bubbel’ te verlaten om het changeproces uit te voeren. Ze gebruiken liever de informatie die al in hun commits staat dan deze te kopiëren/plakken naar een changetemplate. In dit geval is automatisering met het Now-platform dé oplossing, omdat het een brug slaat tussen de developers en het changeproces. Maar de technologie gaat het belangrijkste principe van DevOps, teamwork, niet alleen bewerkstelligen. Je moet ook je mensen en processen op elkaar afstemmen.
Mensen
Je moet mensen afstemmen op processen. De developers moeten op de hoogte zijn van de changetemplate(s). Zowel de changemanagers als de developers moeten het eens worden over hoe het changetemplate moet worden ingevuld. Vragen zoals welke velden of waarden in bepaalde gevallen kunnen worden hergebruikt of welke waarden uit bestaande gegevensbronnen kunnen worden gehaald, zijn voorbeelden van vragen die de teams samen moeten beantwoorden. Daarna moet je bepalen in welke situaties het Now-platform moet worden ingeschakeld. Ik zal daar verder op ingaan onder “Technologie”.
Processen
Meestal is er wel een changeproces aanwezig. Maar dit proces ondersteunt automatisering mogelijk niet (volledig). Veel organisaties gebruiken stappen of fasen die niet makkelijk of logisch te automatiseren zijn, zoals bijvoorbeeld een change-implementatieplan dat moet worden geschreven en aan de change moet worden toegevoegd. Daarom is de cyclus van een change misschien niet eens compleet terwijl de commits al in productie zijn genomen. De developer heeft bijvoorbeeld een nieuw changeverzoek gemaakt en gaat ervan uit dat zijn taak is voltooid. De sourcecode is beoordeeld en de samenvoegverzoeken zijn goedgekeurd, waardoor de change in productie gaat. Maar wat hij niet in de gaten had, was dat de change in de wacht werd gezet omdat er al een belangrijke update was gepland voor de doelserver, wat tot een mislukte implementatie leidde.
Je kunt dergelijke situaties voorkomen door een risicogoedkeuringsstap op te nemen in je proces. Voor andere soorten diensten is de fouttolerantie meestal hoger dan voor productiediensten, aangezien er geen eindgebruikers zijn. Dus misschien wil je ook een goedkeuring inbouwen voor productiereleases, terwijl dat misschien niet nodig is voor andere soorten releases. Een andere maatregel die je kunt nemen, is de automatiseringsfuncties van het Now-platform gebruiken. Zo voorkom je de implementatie niet-goedgekeurde en ongewenste changes.
Technologie
Zodra de mensen op de hoogte zijn van het changemanagementproces en Change Management klaar is om te worden geautomatiseerd, kan je de kracht van het Now-platform gaan benutten en verschillende producten integreren en stappen automatiseren:
- Productbacklog
Alle changes in DevOps komen voort uit Stories. Waarom zou je het risico lopen om changevereisten te verliezen vanwege onbekende changeroots? Wanneer je Jira bijvoorbeeld met ServiceNow integreert met behulp van onze Connector4U-toepassing, kan je Stories uit de Jira-backlog synchroniseren met de ServiceNow-instance. Vervolgens kan je al deze gegevens gebruiken om het changeverzoek te vullen of te verrijken. En wanneer je een bi-directionele integratie instelt, kunnen Stories later zelfs worden verrijkt met een URL die naar de change leidt, zodat de implementatie vanuit beide systemen kan worden gevolgd.
- Sourcecontrole
Elke change in de sourcecode wordt opgeslagen in een centrale opslagplaats. Gewoonlijk resulteren een of meerdere Stories uit de backlog in een nieuwe versie. Alle commits die bijdragen aan die release worden dus gebundeld in de sourcecontrole. Deze commits moeten echter uiteindelijk in productie worden genomen en daarvoor zal een changeverzoek moeten worden ingediend. Je kunt deze stap volledig automatiseren met ServiceNow. Door gebruik te maken van changetemplates en een risicogoedkeuringsstap, hoeft de sourcecontrole alleen een API aan te roepen en een eenvoudige payload met enkele gegevens te verstrekken om het changeverzoek te verrijken. Dit voegt al veel waarde toe aan de CI-/CD-pijplijn, maar dit is zeker niet de enige stap die je kunt automatiseren.
- Geautomatiseerde tests
Wat als de pijplijn een geautomatiseerde test bevat die moet worden uitgevoerd voordat de implementatie kan plaatsvinden? Er is geen enkele reden waarom iemand die knop handmatig moet indrukken. ServiceNow kan dit automatisch activeren nadat de change is goedgekeurd. Na respons wordt de change doorgevoerd of als de test mislukt, wordt een taak gemaakt voor de developers.
- Implementatie
Na goedkeuring en een succesvolle test kan ServiceNow ook de daadwerkelijke implementatie activeren. Hoe? Door de ontwikkelde code samen te voegen met de productiecode of via een API. Na respons stelt ServiceNow de producteigenaar en/of gebruikers automatisch op de hoogte van de productupdate.
- Documentatie
Na een succesvolle implementatie van de changes moet ook de productdocumentatie worden bijgewerkt. Je kunt ServiceNow zodanig configureren dat er een koppeling naar de Knowledge Base wordt opgenomen die naar het artikel met productfuncties leidt zodra een change is voltooid. Op die manier houd je de developers automatisch op de hoogte. Om het documentatieproces nóg makkelijker te maken, kan je zelfs nuttige gegevens uit de samenvoegverzoeken extraheren om het Knowledge-artikel mee te vullen.
De toegevoegde waarde
Voorkom dagen- of wekenlange uitloop van code-implementaties door Change Management. ServiceNow lost dit probleem onmiddellijk op dankzij de uitgebreide integratie met DevOps-tools. Dit betekent dat je je developers kunt bevrijden van hun administratieve taken en kunt profiteren van:
– Meer ontwikkeltijd
– Snellere time-to-market
– Geen auditbevindingen
– Minder P1-incidenten
– Tevreden Product Owners
Vond je mijn artikel interessant? Aarzel dan niet om contact met me op te nemen om te bespreken hoe we jouw DevOps-uitdagingen kunnen oplossen.
Ben jij ook bij ons webinar?
Ontdek hoe je DevOps-teams in lijn brengt met je bedrijfsdoelstellingen met behulp van ServiceNow en hoe je sneller changes kan doorvoeren zonder in te boeten op controle óf agility.
Blijf op de hoogte, net als 1400 andere ServiceNow-professionals
Schrijf je in voor onze maandelijkse Flow@Work Exclusive nieuwsbrief bomvol inzichten, best practices en tips over hoe je werk laat flowen op het Now®-platform.
Richard van Goch