Driving DevOps Through Shared Knowledge and Control

application in development is critical to simplifying the hand-off. Of the most critical information that production control needs from development is the ability to confirm that the application has been built on the correct production level of the underlying technology stack.

They want to see that the executables have matching source code and can be rebuilt for an emergency release or a corporate audit.  They often want sign off from a testing team that confirms that the new release has been fully tested in an environment that models production.  Details on server configurations, environment variables, and release steps are needed from the development teams for production control to repeat the deploy process at the production state.

To satisfy upper management, production control needs to report and manage key facts about the applications moving into production. Production control members need to report that the new release is compatible with the production environment, that emergency fixes are possible, and that there is an audit trail for tracking who requested the release, the time and date of the release and what new features or fixes initiated the release often down to what source code was updated and what new binaries were moved to production for the new release. Production control needs to confirm that the application moving to production is built on the production technology stack, not the development technology stack.

Additionally, production control members need a clear topography of the servers that are used, the steps necessary to perform the deployment, and details about the server’s configuration. Even though the team members may not themselves execute the deployment, they are responsible for it. This means that team members need the knowledge of what is occurring at the production deployment level. In other words, production control needs basic information about how applications are built and deployed.

A lack of shared information is the primary reason why the hand-off between development and production is problematic. This information is hidden in one-off script-driven processes that manage both the build and deploy. These one-off script driven processes are known by only a few individuals on the development team, and in most cases cannot be known to production control. Furthermore, these processes impede the sharing of control between development and production. Ultimately, this creates some nasty politics between the two teams. What appears to be a constant struggle for power, in reality is simply a struggle for shared knowledge and control.

Most organizations use scripting to manage builds and deploys. Each development team determines how their build and deploy scripts will operate. Because of this, a company with fifty java teams can have fifty plus build and deploy scripts that look and act completely different. All scripts can be building and deploying a Jboss application, but they do it in their own unique way. And no, there is never a reason for the difference, other than the names of files and servers. The Java compiler works the same regardless of the file name. JBoss applications are deployed the same way every time with the exception of binary names and some server configurations. Each developer who writes his application’s build and deploy scripts, simply manages the logic in different ways making the scripts non-standard and often hard to debug, fix, and re-execute.

Some developers do an outstanding job of writing their build and deploy scripts, and others not so much. As a result, production control must manage a web of scripts with no standards, no common reports, no method for matching source to binaries, no method for validating the technology stack, or no method for repeating a build