Driving DevOps Through Shared Knowledge and Control

build or deploy if needed. Thus, the constant struggle for control of the deploy process continues between teams. Production control team members asks for what they consider to be basic information, which development teams are unable to produce in a standard and repeatable way across the organization. Static scripts hide critical information such as the technology stack dependencies and generate no common reports that should be shared across team.

We must strive towards using real automation and standardization. A one-off script executed by a job-scheduler or workflow tool is not real automation. Creating re-useable build and deploy scripts will ultimately be the answer for delivering standardization to both build and deploy. Today’s DevOps solutions are quickly beginning to address the problem of one-off scripts and lack of repeatability. There are DevOps solutions that address both the build and deploy by generating your build and deploy scripts in a consistent, repeatable, and transparent way.

These methods deliver standard reports, continuous build and deploy, incremental processing, accelerated builds, parallelized deploys, the management of server configuration, and the validation of the correct technology stack as part of the build and deploy process. In essence, the tools that move away from one-off scripts are providing a framework for sharing the build and deploy details between development and production so that the hand-off is indeed simplified through shared knowledge and control.

Moving away from one-off script driven processes is not entirely new. We simply need to look at the transformation the mainframe teams went through in the early 1980s. Compile and deploy Job Control Language (JCL) used to be the most common way for build and deploys to occur on the mainframe. It is now extremely uncommon to see private compile and deploy JCL used on the mainframe. You may argue “the mainframe is easier to manage so they can standardize their scripts,” but as a person who has done both, I would disagree.

There are as many variables on the mainframe as there are in the distributed environments from Windows to Unix to Linux. And yes, mainframers can do a check-in and build (continuous integration) and move only the updated files through the lifecycle quickly (incremental continuous deploy) while production control manages the entire process without using a single one-off JCL script. Ultimately, a similar process will be adopted on the distributed platforms allowing production control teams and development teams to share the knowledge and management of software builds and deploys.

Developers can then spend less time and money on writing one-off script driven processes and instead focus on what they do best—quickly deliver awesome business software to maximize the profits of their employers.