“DevOps has been done before – Mainframe Endevor stands for ENVironment for DEVelopers and OpeRations.” Anonymous Mainframer
Why is Endevor spelled incorrectly?
One evening at a conference, I was having dinner with a mainframer and asked him “why is Endevor
spelled wrong?” He simply stated, it is an acronym for “Environment for Development and Operations.” I had just begun hearing the term DevOps, so I was floored. Here I thought that DevOps was new, but it has already been achieved by mainframe developers years ago. Of course it is odd to discuss an old and creaky system like z/OS around agile and DevOps, but there are lessons here to be learned.
Mainframe Endevor is a z/OS version control tool that also performs automated builds, automated deployments and automated configuration management. I decided to write about this based on a recent conversation I had with a Java developer who claimed the mainframe was ‘easy’ compared to developing on a modern system. Having worked as a mainframe developer, I know this was not always true. There was a time when moving code updates on the mainframe was not easy. Compiling code, sorting out dependencies, updating load libs, performing new copies and coordinating database updates was a major undertaking. It became easy after the days of Endevor and the competing solution ChangeMan.
Developers on the mainframe went through a software development revolution in the mid to late 1980s, similar to what we are seeing today on Windows, UNIX and Linux platforms. Instead of DevOps, discussions were around Configuration Management and Application Life Cycle Management. From these discussions, a simple understanding was born that developers did not want to spend time writing one-off compile, link and move JCL that often did not work between development, test and production environments. They also wanted a way to version their source code, automatically compile the objects on check-in and move the objects into the correct environment upon a successful build. Sound familiar? They also wanted a way to track source to object parity to easily identify what was running in production and on what LPAR. They wanted the ability to track dependent objects and libraries, understand impact and automate tasks that had been taking them days to complete.
A change to the software development lifecycle
It was this shift that permanently changed the way in which mainframe programmers managed their software development lifecycle. The shift required developers to give up old habits and embrace a more modern and efficient way of building and deploying software. Even though software development was still being analyzed and planned in a waterfall approach, they had sorted out a method for supporting small incremental changes, quickly updating production and tracking all of the pieces and parts working in synch with testing and production teams – all triggered by a source code check-in.
Just for grins, let me cover the basics of how Endevor works (ChangeMan is very similar). Endevor is a version control tool. It also uses something called ‘processors.’ While Endevor can be configured in many ways, the most basic installation is defined with stages, Dev, Test and Prod for example. Dev is configured so that as developers check-in new code, a processor runs that automatically compiles the code, making sure it did not break something else. It uses a package concept allowing the Administrator to push groups of changes across the ‘pipeline’, from Dev to Test. When the move occurs, another processor runs, re-compiling the code into the Test environment. In some cases, automated configuration management (ACM) is used to determine package dependencies and impact. If all is successful at Test, a processor runs to perform a ‘ship function’ into the Production environment. Gated approvals are used to manage the process, and the process can be initiated for a small change or a much larger set of changes including database updates and LPAR configurations.
If you work in an organization with a mainframe group who uses Endevor or ChangeMan, it is worth your time to take a look at how they have solved the DevOps challenge. A single Endevor Administrator can manage hundreds of applications, unlike the distributed side of the house who must uses 1 or 2 Release Managers per a handful of applications.
In today’s drive to achieve agile and therefore frequent software updates, we could use some of the sanity that Endevor brought to the mainframers in the 1980s. This is ultimately the goal of Continuous Delivery. The gorilla in the room however is what is actually being executed by a continuous integration or continuous delivery process. In most cases, these orchestration tools call the same build and deploy scripts that were used in waterfall approaches. What is needed are the ‘processors’ that transform the static nature of scripts into the dynamic processing of true automation.
A new set of Continuous Deployment and Application Release Automation solutions are becoming available to replace those one-off scripts with an automation tool chain that finally addresses the problem. When defining your Continuous Delivery process, look for the pitfalls of one-off scripts and consider replacing them with continuous deployment tooling for a Continuous Delivery pipeline that can quickly adapt across the lifecycle, and provide you the feedback needed to continuously improve the process from start to finish, and back again.
