DevOps has three principles or “ways.” The first way is focused on systems, or the overall efficiency of the entire process. The second way prioritizes feedback loops, and minimizing the time to incorporate changes. The second way also prioritizes adaptations in each individual segment of the process. Finally, the third way values experimentation as the only way to find new and more efficient processes. Those who follow the third way of DevOps will accept the occasional setbacks of experimentation, in favor of the better methods that will often result from trying new things.
The First Way
In DevOps, the first way is unique in that it focuses on improving the entire process as a whole, rather than focusing on individual areas and components. Much the same way that medical professionals treat the whole health of patients instead of dealing with individual symptoms, the first way of DevOps seeks to make the most efficient overall process.
One of the ways that the first principle accomplishes this is by verifying that bugs are fixed as soon as they are detected. This ensures that stages of the product development process do not pass known problematic processes to the next stage. If a later stage does find errors, the product is returned to the appropriate stage and does not move forward until the problem is corrected. This ensures a quality product at the end of each stage of development and reduces technical debt.
The first way also prevents optimization of one stage harming later stages in the process. In more traditional development environments, individual stages optimize their own workflow to push a product to the next stage as quickly as possible. Occasionally, this local optimization can make things more difficult for later stages, ultimately increasing the total time that a feature spends in development. By ensuring that all stages work together as efficiently as possible, the first way of DevOps minimizes the time from the beginning of a feature until it is released to customers. Even if a feature might spend more time in one particular stage, this is beneficial to the whole health of the process.
Creating the Deployment Pipeline
The deployment pipeline is the sequence of steps that a feature must go through to become a functioning part of a software product. This pipeline spans from customer request to finished and delivered product. Though every request must go through this process, it is beneficial to lay out the entire process logically and observe where optimizations can be made. Another benefit of the deployment pipeline is that it identifies which parties are responsible for what steps. If a stakeholder needs information on the status of a request, the deployment pipeline displays exactly who is responsible for the feature at any step.
As useful as it is, the deployment pipeline does not simply come into existence on its own. Teams must work together to examine how a request behaves and passes through an organization. Where does a request start when it enters a system? What does a typical customer request look like? Where does the request go once it is finalized? These are the kinds of questions that the teams must answer to put together a comprehensive deployment pipeline that offers value to the organization. They go step by step, following a request through the process until the finished product reaches customers.
Similar to physical pipelines, the deployment pipeline has a maximum flow. An organisation can only have so much development work pass through at a time. Limiting work in progress allows each stage of the process to put more effort into any given item. By keeping the number of requests in progress to a minimum, the team can pass fewer items through the pipeline more quickly. This ultimately reduces the amount of time from beginning to end, and gets working code to stakeholders more quickly. Improving efficiency is the overall goal of first way DevOps.