Modernadvanced
DevOps and CI/CD for Mainframe
Understand how modern source control, automated build/test pipelines, and CI/CD practices apply to COBOL/JCL development on z/OS.
Mainframe development historically meant editing a PDS member in place and promoting it by hand. Bringing version control, automated builds and pipelines to it is one of the most active modernisation efforts in the industry.
Mainframe DevOps modernization is like renovating a century-old, still-structurally-sound building to add modern plumbing and electrical systems without touching its proven foundation — the goal isn't tearing down and rebuilding from scratch, it's carefully retrofitting modern conveniences (Git workflows, automated builds, CI/CD pipelines) onto infrastructure whose core reliability was never actually the problem.
Key Concepts
1
The foundational change is where source lives.
before: source in a PDS, edited in place. The library IS the
repository, and it holds one version -- the current one.
after: source in Git. The PDS becomes a build artefact.2
Why the PDS model causes the problems it does. There is no history, so you cannot see what changed or
why. There are no branches, so two people changing one program coordinate by talking. There is no diff, and
no review.
3
Promotion between environments is a copy somebody performs, which is why "it works in test" and "the fix
did not reach production" are recurring mainframe complaints.
4
Bridging the two worlds needs tooling, because the compiler reads a PDS and Git does not produce one:
5
Git --checkout--> workspace --copy--> PDS --compile--> load module6
IBM Dependency Based Build, Wazi, and Compuware/BMC's tooling do this synchronisation.
7
Dependency-based build is the non-obvious part. A COBOL program copies copybooks, and a copybook change
means every program using it must be recompiled.
8
The build has to work that out from the source, or a copybook change gets compiled into some programs and
not others — the classic way a production file is corrupted quietly, because programs compiled at different
times read the same record at different offsets.
9
Automated testing is the harder half. A pipeline that compiles but does not test only tells you the
syntax was valid.
10
unit tests for COBOL logic, with test doubles for I/O
job-level run a job against a known dataset, compare output
regression the same before and after a change11
Legacy programs that read files directly are hard to unit-test, which is the same problem ABAP has, with
the same answer: separate the logic from the I/O so it can be called with fixtures.
12
Where pipelines run. A build server outside the mainframe, driving it through Zowe CLI and z/OSMF —
submitting compile jobs, checking return codes, running tests, promoting on success.
13
The honest scale of it. This is a process change more than a tooling change. The tools work; what takes
the time is decomposing decades of interdependent source, establishing what a build unit is, and creating
test data that can be relied on. Shops that treat it as a tool purchase do not finish.
14
What the interviewer is probing.1. "What does a mainframe pipeline look like?" Probing: the shape. Stalls: "There is none."
Moves up: source in git, compile and bind in a build step, automated unit tests, then promotion
through environments — the same shape as elsewhere.
15
2. "What replaces the traditional promotion library?" Probing: the change. Stalls:
"Nothing." Moves up: git as the source of truth with the build producing load modules, rather than
a library manager where the library is the truth.
16
3. "What is the hardest part to automate?" Probing: honesty. Stalls: "Compilation." *Moves
up:* test data — realistic, masked, repeatable datasets are harder to produce than the build itself.
17
4. "What is the business case?" Probing: the argument. Stalls: "Modernity." Moves up:
shorter lead time and fewer production incidents from manual promotion steps, in an environment
where an incident is expensive.