The adoption of DevOps practices within the IT industry is bringing automation to many of the traditional testing and deployment processes. As this adoption widens, many application owners and IT Service Management (ITSM) practitioners are wondering if DevOps practices are rendering traditional change management processes obsolete.
That being said, change management as we know it today should and will evolve as DevOps becomes more pervasive as an accepted development and release methodology, largely because of the concept of trust—or perhaps, federated trust, between the development and operational sides of the IT organization.
Before we look at the specifics of how this might impact organizations today, it is important to level set on the intersection between traditional release management and change management, and how DevOps best practices bridge what was traditionally attempted through policy and process.
The History of Change Management
Traditional change management grew historically out of the need to protect production and originated as a set of controls that worked backward in time and execution from planned production deployment activities. This often manifested itself in weekly Change Control Board (CCB) or Change Advisory Board (CAB) meetings that reviewed requested/planned production deployments targeted for the coming weekend (when most planned downtime or maintenance windows are scheduled). During this time, they attempted to mitigate the risk of service disruption through analysis and planning to provide visibility into impacted environments and stakeholders. As this practice inevitably delivered uneven results, the need for more scrutiny and longer mandated lead times inevitably grew as well. As these change processes became more bureaucratic over time, the poor usability of legacy IT Service Management (ITSM) tools (i.e. prior to the emergence of cloud/SaaS options such as ServiceNow), compounded this trend to result in a process often completely disconnected from the release management activities. As such, change management combined with an eleventh hour burdensome and tedious process was seen as adding very little stakeholder value.
Although ITIL (v3 and later) practices have mitigated this trend somewhat by recommending more of an integrated life cycle process and context, this is unevenly applied and adopted, and the entropy of traditional practice makes it the exception in most large enterprises.
Conversely, the controls and best practices from traditional release management (e.g. separation of tasks, managed user acceptance and system testing, and panned deployment and back-out procedures) have historically suffered from two key dynamics: 1.) underfunding the resources and the compute environments in non-production that compromised efforts to perform effective testing and 2.) compromised testing windows due to waterfall project management methods and immovable delivery timelines.
Historically, testing and staging environments (where the heavy lifting of testing takes place) have been underfunded. As a result, they have not always been at the same maintenance level or configuration as the target production environment(s). This mismatch often caused testing results to be suspect, contributing to a lack of trust between development and operations. As a result, testing–a pillar of the waterfall methodology–has traditionally only been able to ensure certain aspects of an application’s testing complement. Additionally, since time and opportunity for testing were typically compressed (or in some cultures, bypassed entirely) based on the need to make delivery dates, deployment with defects (both known and unknown) became the norm. While these dynamics varied by organization, across the industry, a culture of mistrust between development and operations organizations impacted how best practices were implemented and evolved over time.
The Introduction of DevOps in the Enterprise
In a true DevOps environment, several dynamics come together to alter the impeding mismatch between change and release management. This combination accomplishes what traditional change management never could: high quality and high confidence in application deployments that require little to no qualitative review, besides coordination to ensure a successful application deployment. The reason that this verified trust can be achieved is because of a rather significant investment in DevOps.
DevOps combines several dynamics that allow application releases to be continuously delivered through an agile software development life cycle (SDLC) that ensures the following:
- applications can be built and rebuilt (through continuous automated builds)
- applications can be automatically tested (through comprehensive automated testing)
- applications can be systemically deployed (through continuous automated deployment) in a manner that ensures repeatability and high confidence.
The DevOps Advantage
Organizations that adopt a DevOps methodology deliver small changes rapidly within an agile/scrum development culture. This culture integrates testing methods with development, so that automated testing is curated and updated as needed if new functionality requires it. By automating testing and deployment through continuous integration and continuous deployment (CICD), change management stakeholders can shift their attention from traditional concerns, such as separation of tasks and back-out plans. This leaves them with the ability to focus on curation and review of the DevOps/CICD process and standards in use by the development teams requesting or deploying a change. Deployments via containers are also highly automated, scripted, and scheduled so that relatively small releases are on a continuous cycle into production.
How DevOps Impacts the Change Management Process
DevOps transformation is not easy for most large traditional development organizations. Hiring a scrum master and claiming that your development team is “agile” is not going to cut it. It requires a shift in organizational structure, value creation and recognition, and product management concepts and communication methods with the business, as well as a significant investment in non-production infrastructure, tooling, and resources for care and feeding. As a result, the change management process may adopt a “trust-but-verify” stance with respect to DevOps delivery of applications, but may still require fail-safe documentation and process to ensure production environments are protected and audit requirements are satisfied.
At the end of the day, the evolution of change management is inevitable. The change management process owner/manager will be compelled to engineer an onboarding mechanism for DevOps delivered applications. This process will enable gates by which an application team can demonstrate DevOps best practices. Application teams will have to prove that automation, curation, and process ownership exists, and that continuous or automated build/test/deploy capabilities can be certified and categorized as standard or pre-approved changes that do not require the diligence and oversight of traditional change management processes.
The wider adoption of DevOps is causing some disruption and evolution in traditional change management, but that evolution will result in a new streamlined and integrated approach to change management standards and practices. This evolution will impact the change management process owner/manager as they evolve from traffic cop to trust-broker. While change management will not be obsolate, the delineation of change and release management will become less defined. In an ironic twist of fate, change and release management–which were for so long culturally and operationally segregated–will become federated and integrated processes.
If DevOps adoption is growing within your organization, now is the time to evolve your change mangement processes and policies and build trusted relationships with application teams that demonstrate DevOps best practices. To start enabling the DevOps movement within your organization, contact us today!