In order to reduce operational risks, organizations put in CONTROLS, typically via Change Management processes. To minimize the frictions in your DevOps journey, and building on my previous Tip#1, let us look below for the Tip#2 for effective change management.
TIP #2 – create traceability and context for your change set
Operations do not want to be Surprised by any change!! When you are working in operations every weekend and having multiple late nights, for supporting servers going down or applications crashing, you really want to know what’s the next patch upgrade going to do and how well it will work on the production box. Operation team members are also human and need to have the same LIFE as development team members. ASK your Operations team the OPS PAIN INDEX
OPS PAIN INDEX = #EXTRA HOURS WORKED x EXTRA NIGHTS
A higher value for this Ops Pain Index will give you a better understanding of the need for Ops to learn more, about every new change being proposed and it’s impact for deployment on existing running stable system. Talk about building TRUST in the development change set!!
Thus, the key is to INCREASE THE TRUST IN YOUR CHANGE SET, by creating traceability and providing context.
With today’s tools and deployment pipelines, it is easy to link your work items in the planning tools (say JIRA, TFS, Rally…etc.). These typically include features/stories/defects – including the Ticket number, version control checkins, comments, release notes. This input can be easily feed into the deployment pipeline tools (Jenkins, Chef, Puppet etc.). This integrated view provides complete traceability across all stages from requirements to the deployment.
The linkage of the work items to the deployment artifacts describes CHANGE SET and provides the CONTEXT for the Operations team.
The additional evidence from a Quality standpoint is typically available from various channels. This includes automated builds results, automated testing results, showing the test cases executed, pass/fail ratio etc. across the various test stages (unit, integration, regression, performance, security tests). All these provide the additional confidence to the operations teams that the development team has really tested the application.
When the development says it works, they really mean it !
Aim to provide evidence of quality test results for the proposed change set, which will provide the required CONFIDENCE for the Operations team.
So go ahead and start providing the traceability and context for your change set to the operations teams and you will be on your way to building some new OPS friends 🙂
Subscribe for more tips in my next post, and feel free to share your feedback here.