Solutions / Mainframe DevOps

Deploy z/OS the way the rest of your pipeline already works

IBM Wazi Deploy is scripted, YAML-driven z/OS deployment that lives inside your pipeline — part of IBM Developer for z/OS Enterprise Edition. It’s the natural next step after a Dependency Based Build, and we implement it end to end.

The Problem

DBB builds it. Something still has to move it.

Once Dependency Based Build knows exactly which load modules a change produced, the last mile is getting that output promoted from DEV to TEST to PROD. In too many shops that last mile is still a hand-typed IEBCOPY job, a copy-and-paste of member names, or a script only one person maintains — the one manual step in an otherwise automated pipeline.

Wazi Deploy closes it declaratively. You describe what to deploy and where in a YAML deployment manifest kept in Git next to the code; Wazi Deploy generates and executes the deployment from that manifest. It’s Git-native and pipeline-first — no separate deployment server to run, no UI to click through — which makes it a clean fit for teams already building with DBB.

That focus is the trade-off to understand: Wazi Deploy is z/OS-focused and lightweight. When a release has to span mainframe and distributed platforms under one workflow-driven tool, IBM DevOps Deploy is the better fit — and we’ll say so.

What It Looks Like

Deployment as a file in your repo

The deployment manifest lives in Git beside the code it ships. It’s reviewable in a pull request, versioned with the release, and identical across environments — the target changes, the definition doesn’t.

deployment-method.yml
# Illustrative — a Wazi Deploy manifest describes artifacts and targets
apiVersion: deploy.ibm.com/v1
kind: DeploymentMethod
metadata:
  name: payments-batch
artifacts:
  - name: PAYCALC
    type: PGM          # load module from the DBB build
    deployTo: CICS.PROD.LOADLIB
    actions: [ copy, cics-newcopy ]
How We Implement It

From DBB output to a promoted, auditable deploy

Wazi Deploy is most valuable directly downstream of a Dependency Based Build. We wire the two together so a build flows straight into a governed deployment.

01
Assess targets and access
We inventory your deployment targets — load libraries, CICS regions, DB2, JCL procs — and the access and change-control rules each one carries, so the manifests reflect reality.
02
Author the deployment manifests
We write the YAML deployment methods and index files that describe what ships where, kept in Git alongside the source — reviewable, versioned, and consistent across environments.
03
Connect it to the DBB build output
The artifacts a Dependency Based Build produces feed straight into Wazi Deploy, so what gets deployed is exactly what the impact build produced — no manual re-selection of members.
04
Run it from the pipeline, with evidence and rollback
Deployment executes as a pipeline step. Each run records what it did for audit, and the declarative manifest makes reversing a deployment a defined operation rather than an emergency.
05
Hand it over to your team
Because it’s just YAML in Git and a pipeline step, your developers can own and extend it — we train them on the manifest model rather than leaving a black box behind.
Why It Fits

Lightweight on purpose

Git-native

The deployment definition is a versioned file in the same repo as the code — reviewed in pull requests, not configured in a separate console.

Pipeline-first

No standing deployment server to operate. Wazi Deploy runs as a step in the CI/CD pipeline you already have.

Built for z/OS

Load libraries, CICS, DB2, and JCL are native concepts — part of IBM Developer for z/OS Enterprise Edition, not a distributed tool bent onto the mainframe.

Why Strongback

We implement Wazi Deploy as the far end of the same pipeline we build with DBB — so build and deploy are one flow, not two projects stapled together.

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

Already building with DBB? Deployment is the next step.

An implementation assessment maps your z/OS deployment targets to a Wazi Deploy manifest model — and confirms it’s the right fit versus a broader tool.