The Challenge: Balancing Change and Control of Continuous Delivery at Scale

DevOps bridges the gap between development and operations to deliver business value more frequently.

DevOps practices break down traditional domain silos that inhibit communication and process flow, establishing a culture of shared responsibility for development and operations. As the separation between dev and ops is reduced, release trains begin to operate as a Continuous Delivery pipeline to define, implement, and deliver innovation faster by minimizing time-consuming handoffs and reducing operations support.

DevOps and Continuous Delivery

This journey to Continuous Delivery (CD) requires release teams to address inefficiencies and constraints that may have been plaguing the organization for years. Existing software practices may create technical debt and rework that inhibits adoption of new methods. Or the current deployment pipeline is not repeatable, requiring manual heroics that drain resources and restrict team velocity. The application architecture also plays a big role in the transition to DevOps.

When architecture is loosely coupled, release trains can achieve quality validation and deployment independently of one another — ideal when establishing a flow-based CD model. However, the reality for most large enterprises is a tightly coupled application, with many interdependencies across multiple release trains. Deployment pipelines may run in parallel initially, then eventually converge as the test environments become increasingly complex to reflect the final production state. If a single pipeline faces delays, the flow of the entire release is jeopardized.

Coordinating these complex release trains and implementing CD at enterprise scale requires balancing the pace of change with the controls needed for application health and stability. Delivery teams need to optimize the flow of code through the system, and although developers may have established Continuous Integration workflows that rapidly create testable builds, test teams are often stuck waiting for a properly configured test environment to become available. Additionally, everyone needs visibility to understand code quality to stop issues from progressing down the pipeline, however the specialized tools used by dev and test teams are not accessible to all stakeholders, making it difficult to identify problems or assess schedule risk.