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:
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.
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.
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.
How to thrive in a fast-changing world using Enterprise DevOps
Aanvragen
