Change Management in the DevOps Era
DevOps is all the rage in the high-tech space. Quick revs to fix problems and add features sounds sexy and exactly what sales teams and project managers want to hear. Unfortunately, DevOps has morphed into an excuse to code quickly and trim off the “fat” of proper design, testing, and change management. There is a reason why “Test it in production!” has become the running joke for DevOps in our industry.
When DevOps was first introduced in the middle of this decade, it was intended to increase the frequency of deployments by reducing the scope of change without sacrificing design, testing, and change management requirements. The idea was to make smaller, incremental changes that are easier to code, test, and deploy compared with the long, complex deployment cycles that used to dominate projects. These small, incremental changes would ease testing and change management burdens, thereby speeding up the whole process.
The Value of DevOps
When done well, DevOps brings velocity and stability to a software project. Velocity is found in the steady and incremental changes allowed by the concept of sprints. Sprints break up a project into small chunks that can be easily documented, understood, developed, tested, validated, and deployed in relatively short periods of time. Sprints also allow you to change direction quickly by allowing you to introduce new requirements at more frequent intervals. This means you can change direction quickly without throwing out months and months of work before it gets deployed, as you may have had to do if you were using a more traditional project management model.
Stability is gained by the idea that there are checks and balances involved with the Quality Assurance teams and Change Management teams. Sprints deliver changes in a much more incremental fashion. This provides smaller scopes for QA teams to test, thus allowing for more thorough testing. The incremental changes also allow stakeholders and Change Management teams to better understand the scope of changes, which enables better understanding of the risks related to those changes.
Automation also drives much of the success of DevOps. Because scopes are smaller, and the rate of change is higher, many of the tasks involved in delivering a project need to be automated. Many standard QA and code quality tasks can be automated. Software and asset builds can be automated. Deployment and rollback processes can be automated. Developing complex and time-consuming tasks into automated tasks reduces risk and helps keep end deliverables consistent.
All of this automation frees up time for developers and operational resources to spend time on more productive tasks. DevOps teams can build on automated tasks to deliver more capable systems than ever before. Automation ensures that these tasks are completed on time, consistently, and with as few variables in the process as possible.
Automation is also very Change Management friendly. Automated processes are also standard processes. Standard processes are well understood and well documented, delivering a consistent output for given inputs. Standard processes also require less scrutiny from Change Management teams and will be quickly approved, leading to higher rates of safe, stable change.
DevOps doesn’t have to mean that your dev team runs wild. A well-functioning DevOps team has all the key components that allow for success: quick turnaround of problems, proper vetting of changes, and appropriate controls in place to mitigate risk.
