Driving DevOps Through Shared Knowledge and Control

“It’s a production application in development,” explained a development manager to a production control administrator, “and that is why we need to do our software releases so frequently.” I watched as the production control team looked at the development manager like he was crazy.

A production application in development can be a difficult concept for a production control administrator to fully grasp or support. For development, a production application should be fully baked and not in what would be considered a “development” state. However, frequent releases are a basic requirement of rapid development methodologies like agile and this impacts the way in which development teams and production control teams must interact.

In essence, applications go to production before they are fully baked, and they get better over time until the last iteration has been completed at which time the application goes into a “maintenance mode” where scheduled releases are approved by the production control team, but often managed by developers. Production control teams are ready to support scheduled releases, but struggle for many reasons with continuous deployments.

For example, production control prefers to manage releases in a stricter manner, including an approval process that may take one to two days. The application moving to production is added to a release calendar and scrutinized through release meetings and discussions. It is not unusual for the production control team to hold a release, just to make sure new changes are not added. This is contrary to continuous deployment where frequent small releases are moved to production in a more automated fashion with less scrutiny or discussion.

Production control teams who support distributed platforms have never fully taken over the task of performing the build to deploy steps for managing production binaries. In many large companies the production control team serves as an “approving” body, providing the development team access to production servers for the purpose of managing its releases. When releases were less frequent, this potential violation of the separation of duties flew “under the radar.”

If there was a problem with production, the production control team was responsible for fixing the issue and answering to upper management, always with the development teams doing the work to get production back on track.

With the introduction of agile development, where frequent releases are a core part of the process, the production control landscape has changed. Production releases are more likely to cause upper management to question the frequency of releases to the production environment. The answer to the question, “Why frequent releases?” is “It’s a production application in development.” Yes we have come full circle, which is why the DevOps conversation has become much more prominent in discussion blogs, technical journals, and in the conference rooms of companies looking to improve the moving of applications between development and production control.

Frequent releases are being reported to upper management exposing that there is a change in the way applications are moved into the production environments. Instead of scheduled releases, production control is being asked to push through frequent releases changing the standard release processes that production control has followed for the last thirty years. While agile teams argue that smaller, more frequent releases reduce risk, upper management may see frequent releases as an unstable, high-risk production environment.

At its core, DevOps attempts to streamline and simplify the hand-off of the software application between development and production as well as calm the nerves of upper management who are wary of frequent releases. Giving production control what they need to manage a production