Popular Articles

The XebiaLabs DevOps Platform provides visibility and synchronizes data across the CI/CD pipeline by connecting issue tracking and ITSM ticketing tools, so that user stories and change tickets are always up to date.

Subscribe for more!

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.

ON-DEMAND WEBINAR

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.

Gene Kim is a DevOps thought-leader, multiple award winning CTO, researcher and author. He is also a Strategic Advisor to XebiaLabs.

The Reality of Software Releases

Many organizations model software delivery as if the features that are initially planned for a release are always the features that are actually delivered to production when the release is done. But the reality of software releases is more complicated than that, because it’s hard to predict the delivery of planned features. The XebiaLabs DevOps Platform can help you deal with the reality of software releases. See for yourself!

Start Your Trial

The XebiaLabs DevOps Platform provides the intelligence, automation, and control that technical and business teams need.