Solutions / Mainframe DevOps

Run z/OS through the same pipeline as everything else

Your mainframe builds and deployments belong in the CI/CD tool you already run — Jenkins, GitHub Actions, GitLab, or Azure DevOps. We wire z/OS in so mainframe changes pass the same gates, on the same dashboards, as the rest of your code.

The Problem

The pipeline stops at the z/OS boundary

Most enterprises already have a real CI/CD practice — for everything except the mainframe. A commit to a distributed service triggers a build, tests, scans, and a deploy without anyone touching it. A change to a COBOL program stops at a handoff: an email, a manual build request, a change ticket, a person who runs the job. The mainframe is the one place the pipeline doesn’t reach.

That gap isn’t technical necessity — it’s a missing integration. A Dependency Based Build can run from a pipeline agent, tests and code scans can run as pipeline stages, and deployment can be handed to Wazi Deploy or IBM DevOps Deploy. Once that’s wired up, mainframe changes flow through the exact same gates, approvals, and visibility as everything else.

And it doesn’t mean a new tool. We integrate with the pipeline you already run — meeting your mainframe team where the rest of engineering already is.

Jenkins GitHub Actions GitLab CI Azure DevOps
How A z/OS Pipeline Runs

A pipeline, not a sequence of handoffs

A common misconception is that each stage waits on the one before it. In practice, once a build produces its artifacts, several checks run at once — the pipeline is a graph, not a line.

Commit → Build
DBB on an agent
Run in parallel
Unit tests (zUnit)stage
Code scan / quality gatestage
Package artifactsstage
Deploy
Wazi / DevOps Deploy

The build runs first because everything downstream needs its output — but tests, static analysis, and packaging then run concurrently, and deployment gates on all of them. We design the stage graph around what actually depends on what, not a rigid checklist.

How We Integrate It

Wiring z/OS into your existing pipeline

01
Connect an agent to z/OS
We set up a pipeline agent or runner that can reach z/OS — running builds and jobs on the host through your CI tool’s native agent model, with the right security and access.
02
Run the DBB build as a pipeline job
A commit triggers a Dependency Based Build from the pipeline — impact-aware, producing the same artifacts a developer would, but automatically and on every change.
03
Add tests, scans, and quality gates
zUnit tests, code analysis, and your organization’s quality gates run as pipeline stages — several concurrently — so a mainframe change is held to the same bar as any other code before it can proceed.
04
Hand deployment to the right tool
The pipeline triggers deployment through Wazi Deploy or IBM DevOps Deploy, so promotion to each environment is a governed, auditable step in the same workflow — not a separate manual process.
05
Unify visibility and approvals
Mainframe builds, test results, and deployments show up on the same dashboards and pass the same approval gates as the rest of engineering — one pipeline, one source of truth.
Why Strongback

We integrate the z/OS end ourselves — the agent, the DBB build, the deploy step — instead of handing your platform team a wiki and wishing them luck.

— Strongback Consulting, mainframe DevOps since before it had a name
Next Step

Tell us which pipeline you run. We’ll wire the mainframe into it.

An integration assessment maps your existing CI/CD tooling to a z/OS pipeline design — build, test, and deploy — so mainframe work stops being the exception.