How Feedback Loops Make It Safe to Deploy to Production
Almost every organization is being pressured to respond more quickly to changes in the market. As development and operations professionals, supporting this business imperative requires that we get new code into production quickly or risk falling behind our competitors. But whether we work in Dev or Ops, pushing the deploy button can be intimidating. After all, who wants to be the person responsible for bringing down production?
Fear of deploying code by both Dev and Ops is not unusual. In fact, Mike Bland described deploying code at Google in 2005 like this:
Fear became the mind-killer. Fear stopped new team members from changing things because they didn’t understand the system. But fear also stopped experienced people from changing things because they understood it all too well.
By providing faster and more frequent feedback to engineers performing deployments, and by reducing the batch size of their work, we can create a safe system of work, integrating the deployment of changes into production as a part of our daily work and elevating everyone’s productivity. Doing this also promotes a better working relationship between Dev and Ops by reinforcing shared goals, responsibilities and empathy.
Let’s look at what we can do to create the feedback mechanisms needed to take the fear out of deploying to production and keep our companies at the top of the market.
Use Telemetry to Make Deployments Safer
Feedback loops depend on understanding how our systems behave as a whole. For that, we need telemetry — the collecting of measurements and other data within our applications and environments (both in production and pre-production) and in our deployment pipeline.
Telemetry provides the intelligence we need to make fact-based decisions about how to improve the health of the value stream at every stage of the service life cycle, ensuring that our services are “production ready,” even at the earliest stages of the project. The information that telemetry yields empowers us to integrate what we learn from each release and production problem into our future work, resulting in better safety and productivity for everyone.
Using telemetry, we can actively monitor the metrics associated with features during deployment. This enables whoever is doing the deployment, whether Dev or Ops, to catch errors in our deployment pipeline before our features reach production, to quickly determine whether features are operating as designed once they get there, and to quickly restore service in the event of errors that we did not detect.
How to Approach the Measurement and Metrics of Your Continuous Delivery Transformation
Watch this on-demand webinar to learn ways to better measure the processes and output of your DevOps and Continuous Delivery transformation.
Have Dev Share Pager Rotation Duties with Ops
Our production deployment and release went flawlessly, but we still experienced some unexpected problems. Left unfixed, they can cause recurring problems and suffering for Ops engineers downstream. But even if issues are assigned to a feature team, they may be considered low priority, which can cause chaos and disruption in Operations and degrade performance for the entire value stream.
To prevent this upheaval, we can put developers, development managers, and architects on pager rotation so that everyone in the value stream shares the downstream responsibilities of handling operational incidents. In this way, Operations no longer struggles alone with code-related production issues. Instead, everyone works together to find the proper balance between fixing production defects and developing new functionality.
Have Developers Follow Work Downstream
Observing customers using an application in their natural environment often uncovers startling ways that they struggle with the application. For developers who choose to participate in the observation, it can be a difficult thing to watch, but it almost always results in significant learning and a fervent desire to improve the situation for the customer.
We can use this same technique to observe how our work affects internal customers. Developers follow their work downstream so they can see how downstream work centers must interact with their product to get it running into production. UX observation enables the creation of quality at the source and helps developers make more informed decisions in their daily work. It also results in far greater empathy for fellow team members in the value stream, which is important for creating a strong DevOps work culture.¶
Have Developers Initially Self-Manage Their Production Service
Even when developers write and run their code in production-like environments in their daily work, Operations may still experience disastrous production releases. That’s because it is the first time we see how our code behaves under true production conditions. Operational learnings often occur too late in the software life cycle, which can be an outcome of not having enough Ops engineers to support all the product teams and the services already in production.
As a countermeasure, Development can self-manage their services in production before they go to a centralized Ops group to manage. By making developers responsible for deployment and production support, we are far more likely to see a smooth transition to Operations.
Defining launch requirements can help prevent the possibility of problematic, self-managed services going into production and creating organizational risk. Services would need to meet these requirements before interacting with real customers or being exposed to real production traffic. Launch guidance allows every product team to benefit from the cumulative and collective experience of the entire organization, especially Operations.
Ops engineers, acting as consultants, can help the feature team resolve issues or even re-engineer a service if necessary, so that it can be easily deployed and managed in production. For services already in production, creating a “handback” mechanism helps ensure that Operations can return production support responsibility back to Development when a service becomes sufficiently fragile.
To Learn More
Creating fast and continuous feedback from Operations to Development is part of the “Second Way,” which is the second of the three major principles underpinning DevOps. To learn more about the Second Way and the other DevOps principles, see The DevOps Handbook and The Phoenix Project: A Novel About IT, DevOps, and Helping Your Business Win.
(Portions of this article were excerpted with permission from The DevOps Handbook.)
Originally published at blog.xebialabs.com on July 13, 2017.
