In this post I will discuss a traditional view of the DevOps processes and tools for z/OS, and in the follow-on post I will discuss a somewhat futuristic view. The ideal situation for development for z/OS is work for all of us. However, significant progress has been made of the past few years to change the traditional waterfall-oriented processes and tools for development of applications on z/OS into a modern-day agile way of working.

Traditional DevOps process for development

Before we look at modern development tools for z/OS, let’s first have a look at how application development was traditionally done.

The traditional waterfall is a staged approach that is reflected in the processes and tools

The development process of applications on z/OS traditionally goes through a number of stages, typically called Development – Test – Acceptance and Production.

An application is developed in the development stage. It is unit-tested in the Development environment. When that is done the application moves to the Test stage, from which it is integration-tested in the Test environment. When all is well, the application moved to the Acceptance stage, from which it is Acceptance-tested in the Acceptance environment. Finally, for Go-Live in Production the application is moved to the Production stage, reflecting the situation in the Production environment.

What you read from the above simplified process description is that every stage in the process, also has an environment associated with it. The infrastructure setup for the development process, is very much aligned with this waterfall-oriented development process. An application version that has its source code in the Test stage, is using the Test environment to validate correct functioning.

Not only does this create obvious source code management problems with parallel development, it also creates a rigid relation between the development process and the physical infrastructure.

Deployments are incremental – the concept of a build does not exist

What is also different is the traditional development process compared to modern ideas, is that the concept of a build did not exist. A build today, is a collection of all the application artefacts that are needed to run an application in a runtime environment.  To run an application you need an executable, and typically also configuration files, scripts and definitions.

On the mainframe we get an executable program through a compilation process. For a z/OS application to work, there are typically also some runtime definitions required. These are things like JCL scripts, properties files, database definitions, interface definitions, etcetera. All these artefacts together we nowadays call a build.

Most of the processes to create all the z/OS application artefacts that are needed for an application, were disparate, unique processes. Some technologies allowed for standardization of build processes for certain components, mostly for the compilation processes. But most processes were either manual, or automated with in-house created tools, using whatever technology the organization thought best at the time when the need was identified.

In summary, creating an application build as we know it today was impossible, and automation of the development process was very much limited.

Problems with the waterfall model

While the long development processes in the waterfall model existed, this DTAP approach was satisfying most of the needs of for the application development process. Quality problems with this way were definitely identified already, like dependencies on manual processes and lack of standardization. These were tackled in a haphazard manner, through custom-build processes where possible and especially through extremely rigid change processes. And while speed was a concern yet, this was more or less acceptable for the clients of the IT departments.

There are on number of tools available on z/OS that support this traditional development model. Almost all of them support the source code management process for DTAP-based development. Endevor from CA/Broadcom, ISPW from Compuware and Changeman from Microfocus are amongst the mostly used tools for mainframe SCM. IBM had a free tool SCLM but stopped supporting that some years ago. Whilst giving good support for source code management, most of the tools had limited functionality for build and deploy processes.