Yes to DevOps, no to automatic deployment?
In aety, we spend a lot of time helping organizations with their development- and operations processes.
We have seen a growing interest in DevOps, and we will gladly tell you why it is a good idea to standardize and automate processes. However, we also meet resistance towards automating software operation – often because the organization has a fixed set of processes that they have a hard time letting go of, e.g. ITIL. These processes typically involve all changes to the production system being discussed at a Change-Advisory Board (CAB) meeting, the purpose of which is to assess the effect of the change on the overall system – both from a technical and business perspective.
Get everyone on board
It is necessary to know the state of the system. Therefore the CAB meetings make sense. The challenge is that they lower the cadence for the release of new functionality, presenting business challenges.
When we suggest that a new release of software should take place without the manual step, it is clear that the operating organization reacts with rejection. But what to do then?
First and foremost, it is important to recognize the need for “control”. Operations must be critical of changes, otherwise, they can not guarantee stability in the services for which they are responsible.
Agree on the purpose
But then it is important to agree on why the process exists, namely to ensure quality, document the changes and thus minimize the risk of things going wrong. And if they do go wrong, you can easily troubleshoot as you can focus on the individual changes made to the system.
The “State of DevOps” report (https://puppet.com/blog/2020-state-of-devops-report-is-here/), which is an annual publication that takes the temperature of organizations’ maturity concerning software, last year focused on Change Management. Here, the result was that organizations streamline their change processes by automating the process. The report also resulted in a clarification that habitual thinking – “the way we have always done it” – makes the processes ineffective.
What does it mean and how do we move forward?
So the first message we want to give is that automation of deployments is not the same as riding around Cowboy country. The development process must ensure that we know exactly what changes are in a given release, and in that way, be able to document the changes. Traceability can (and should) be at the code level, so we can say what changes were made to which files in a given release.
Next, there is the quality itself. An automated pipeline enables testing at many levels, from unit testing of the particular method to verify whether the code for infrastructure provisioning contains possible problems. And let it be said: it is a huge challenge to ensure good automated tests at all levels, so the organization must agree on what is most important and make strict priorities. Quality goals must be agreed upon for what must be in place before a change can be brought up to the following environment. Likewise, the changes must be small and many, rather than few and large.
To summarize the thought process, it would sound like the following:
Automation is a driver for standardization, and standardization gives predictability.
Finally: Start by agreeing on what the goal should be. Divide the plan into several sub-goals, and accept that it all does not fall into place immediately. Stay focused on the collaboration, and thereby gain the confidence that the transformation can be performed.
And give us a call, if you need help.
Error: Contact form not found.
