The Two-week COBOL Sprint: Deployment Automation
In my previous post I talked about getting continuous feedback through a series of Agile feedback loops, aiding the two-week COBOL sprint as a mainframe application development process built on the efficiency of Agile and DevOps. With efficiency in mind, deployment automation is an essential gear for increasing mainframe software deployment frequency.
What Is Deployment Automation?
Deployment is the process of moving binary software components to the systems where they will execute. Deployment automation helps you deliver software components with more speed and efficiency by automating manual steps.
The first step to success with deployment automation is finding someone who can own deployment. You need an accountable person with a bulldog mentality because software deployment involves multiple groups, components and platforms.
Scripted or Manual Deployment Vs. Deployment Automation
For mainframe agility to work, you have to move away from manual or scripted deployment and find a fit-for-purpose deployment automation tool. Stress is high during a manual or scripted deployment. You need to know when you’re done because hundreds of people may be waiting to verify the deployment was successful. If something goes wrong, you need a fast diagnosis.
An assortment of scripts run by different people in different departments at different times isn’t the same as using a deployment automation tool, which provides features that handwritten scripts can’t match, including feedback about where in the deployment process you are. The tool provides this information quickly and often through data visualization by way of its logging and audit trail.
If something goes wrong and you have to roll back to an earlier software version, a deployment automation tool tied to your source code management system can roll back without the drama of deciding what to rollback to. Some of these tools also have the capability of determining how to do a partial rollback. A partial rollback may allow you to succeed with most of your deployment and allow most of the new capabilities to be available. The difficulty with a partial rollback is you have to completely understand the dependencies between your software components. But a deployment automation tool with connection to your source code management system has this knowledge.
Benefits of Using a Deployment Automation Tool
Deployment automation reduces errors of omission, errors related to incorrect versions of components and errors of software moved to wrong locations. It should also reduce or eliminate errors of incorrectly configured software. The configuration files should be managed like code and be included as part of software components that are being deployed.
More Speed, Less Complexity
Deployment automation is faster and requires less coordination between people. The dependencies between the systems and components and the order in which things need to happen are baked into the deployment automation definition. Deployment automation doesn’t have to wait for a confirming phone call that a component managed by another department was successfully deployed. Instead, the tool handles it.
A deployment automation tool captures all of the different deployment requirements previously known only by a few people. Having a tool for this means that you have centralized all of the knowledge that was spread across different individuals and groups. It means you are less dependent on specific individuals being available for the duration of your deployment process. During a manual deployment, missing a key individual means a huge risk if something goes wrong. With automation, the knowledge of that missing person is embodied in the deployment automation.
Goal of Deployment Automation
The goal should be to tie your automated software build system together with your deployment automation tool. Not every build should be deployed, but once an acceptable build has been identified it should be pushbutton-simple to deploy a new build to a test system and ultimately to a production system.
Despite its effectiveness, deployment automation needs constant attention—so do manual deployment tools—because of changes in system hardware, operating system software and subsystems; applied maintenance; new components; and the removal of old software. This brings us back to requiring the person in charge of deployment automation to be detail oriented.
In the end, deployment automation makes it easier to deploy mainframe software to new systems. You already have a centralized complete picture of all the deployment dependencies and all of the software components and configuration files. To move to a new system, just update the deployment target locations and work through the changes required in your configuration files. People are often surprised by how quickly deployment to new systems can be done if the initial automation work is completed on an existing systems and the new system architecture is similar.
My next post will cover unit testing and identifying bottlenecks in the development process. Before we move on to my last blog of the series, recap with my other posts from “The Two-week COBOL Sprint” blog series here, or follow the links below:
- “The Two-week COBOL Sprint: Why Mainframe Shops Need It”
- “The Two-week COBOL Sprint: How Agile Mends Broken Trust”
- “The Two-week COBOL Sprint: Having a Critical Conversation About Agile”
- “The Two-week COBOL Sprint: How to Build a Scrum Team”
- “The Two-week COBOL Sprint: Developing a Process of Continuous Builds”
- “The Two-week COBOL Sprint: Agile Feedbacck Loops”
- “The Two-week COBOL Sprint: Software Development Bottlenecks“