The Four Stages of DevOps Software Release Cycles
Originally published on CloudOps’ blog.
DevOps increases an organization’s ability to deliver applications and services at high velocity, evolving and improving products at a faster pace than organizations using traditional software development and infrastructure management processes. This is accomplished by redesigning processes so development and operations tasks are no longer fully separated by silos.
At CloudOps, we help customers design, build, and operate cloud platforms with DevOps tools and practices. The first phase is always to provide a DevOps Platform and Practices Assessment (DPPA), which provides an objective understanding of the business impact, technical risks, and path to DevOps best practices and cloud native development and delivery.
The DevOps Platform and Practices Assessment provides recommendations for evolving culture, processes, and tooling, and begins with both value stream mapping as well as a Scaled Agile health assessment, which measures software delivery pipelines within four distinct phases: continuous exploration, continuous integration, continuous deployment, and release on demand. Release cycles move clockwise around the radar, improving in performance as they get closer to the center. Advanced organizations can iterate through all steps and release new features in under twenty-four hours, flying across the radar. Those with legacy systems can take months as they crawl across or even sit in the Radar. The SAFe DevOps Health Radar from Scaled Agile can be used to assess the performance of teams in each phase, and provide a benchmark for measuring future improvements.
Through engaging in practices of continuous exploration teams can provide each other with honest feedback and compare their performance to the industry standard. It is an extension of the lean startup methodology, which acknowledges that problems often come from persevering for too long, and encourages teams to retrospect, learn from their mistakes, and improve with each project. Business agility depends on decision-makers being informed enough to know when to persevere and when to pivot, and having the means to quickly change direction when required. Continuous exploration enables the former. Strong performance in this phase will allow teams to identify the viability of diverse ideas and become clear about their goals.
DevOps teams continuously integrate components, systems, and solutions using a prioritized backlog from continuous exploration. This is the build phase and it is owned by the developer. As much as possible should be automated, and the process of committing, containerizing, testing, and deploying code should ideally take no more than a few minutes. Continuous integration covers the development, building, testing, and staging of features.
Improved performance in continuous deployment involves reviewing each sub-dimension and comparing the performance of all teams to the industry standard. Features are deployed to production in this phase, and teams aspire to consistently release features that can then be utilized by the business.
Release On Demand
Through continuous deployments, businesses release features on demand, but not all features are necessarily or immediately visible to end-users. How features are ultimately consumed by end-users depends on decisions made in the release on demand phase of the DevOps Health Radar. While the frequency of feature releases is addressed in continuous integration and deployment, how, if, and when they are consumed by end-users depends on the business’s requirements. In this phase, businesses ensure features provide optimal business value by releasing, stabilizing, measuring, and then learning from the complete cycle.
Assessing your performance across these four phases of software releases will allow you to start overcoming your biggest roadblocks to high-velocity software release cycles.
Always keep in mind that DevOps is not just about tools and processes, it’s also about culture. DevOps organizations are not monolithic or hierarchical in structure and are therefore not slow to pivot or deliver software releases. They are instead comprised of many small teams, each of which is multi-disciplinary and able to act quickly and autonomously. Only once leaders have shifted the culture of an organization can they focus on defining a blueprint for adopting tools and processes that will sustain accelerated software delivery.
To gain a blueprint for assessing your performance in the DevOps Health Radar, download our white paper called ‘How to Initiate DevOps Transformation by Assessing Culture and Processes’.