DevOps and CI/CD for IBM Z: a practical guide

How is DevOps used in IBM Z development?

IBM Z DevOps is the integration of modern DevOps practices into mainframe environments, specifically IBM Z systems running z/OS. This approach bridges traditional mainframe application development and contemporary methodologies like Continuous Integration and Continuous Delivery (CI/CD). IBM Z DevOps provides tools and workflows for automating, testing, and deploying mission-critical applications, allowing organizations to increase agility without compromising the reliability or performance associated with mainframes.

Adopting IBM Z DevOps not only modernizes mainframe development but also connects mainframe teams with the broader IT ecosystem. The strategy enables mainframe workloads to interact seamlessly with distributed and cloud systems, maximizing resource use and agility. By aligning with the accelerated pace of enterprise IT operations, IBM Z DevOps helps organizations reduce risk, shorten feedback cycles, and bolster software quality across platforms.

This is part of a series of articles about mainframe modernization.

CI/CD for z/OS applications DevOps pipelines

Continuous Integration and Continuous Delivery (CI/CD) enable z/OS development teams to adopt modern DevOps practices and integrate mainframe applications into enterprise-wide delivery pipelines. Traditional z/OS development methods have made it difficult to keep pace with agile workflows, but IBM Z DevOps introduces tooling that aligns mainframe development with industry standards.

A typical CI/CD pipeline for z/OS uses Git for source control and IBM Dependency Based Build (DBB) for intelligent build automation. Developers begin by cloning source code from a shared Git repository, creating personal branches to work on features or fixes in isolation. After making changes, they use DBB to build the code locally and verify it with tests before pushing it back to the central repository.

Once code is committed, a pull request initiates the automated CI/CD pipeline. This includes building the shared codebase, executing tests, performing static analysis, and optionally deploying the resulting application package. Key approvals and code reviews are incorporated into the process before merging changes.

The CI/CD pipeline includes several components:

• IDE: Where developers write and debug code.
• Source Code Management (SCM): Typically Git, used for versioning and collaboration.
• Build system: Handled by DBB, which compiles and links programs with dependency awareness.
• Artifact repository: Stores the output of builds, including binaries and metadata.
• Deployment manager: Automates distribution to runtime environments, including any mainframe-specific installation steps.
• Pipeline orchestrator: Controls the execution flow of all pipeline stages.

CI/CD on z/OS reduces manual intervention, shortens feedback cycles, and enforces standard development workflows across teams. It enables traceability from code to production, supports parallel development through Git branching, and provides full separation between source code and runtime environments.

Base pipeline infrastructure with IBM

IBM provides a Base Pipeline Infrastructure that can help integrate IBM Z systems into an enterprise CI/CD strategy. This requires defining how pipeline components access z/OS build, test, and deployment environments.

Two main pipeline actions run directly on the mainframe: building and packaging applications, and deploying those packages into runtime environments. These steps typically include cloning source code from Git, using IBM Dependency Based Build (DBB) for compilation, packaging executables, and automating deployment. Automated testing can be incorporated into both stages to ensure quality throughout the process.

These build, test, and deploy operations are executed from the command line on z/OS UNIX System Services. The pipeline orchestrator coordinates these tasks using agents, either native to z/OS or running remotely. Most orchestration platforms (such as Jenkins, GitLab CI, or Tekton) follow a server/agent model, where the orchestration server resides on commodity hardware, virtual machines, or containers, either on-premises or in the cloud.

When z/OS cannot host the pipeline agent natively, a remote agent connects to z/OS through SSH or HTTPS. This setup lets organizations reuse existing agent pools, scale easily, and support multiple concurrent pipelines. Remote agents maintain separate workspaces on both their host systems and z/OS UNIX System Services. Credentials for accessing z/OS are managed securely in the orchestration platform’s secret store. Common connectivity methods include SSH authentication, HTTPS via the RSE API service, or automation through Ansible with the IBM z/OS core collection.

Some orchestration tools support native agents that run directly on z/OS UNIX System Services. These long-running processes, configured as started tasks, operate under a designated technical account and can be integrated with z/OS system automation and workload management. Native agents execute build and deployment tasks locally, including operations like Db2 binds, and can serve multiple projects. Most pipeline steps and plugins work without modification in this configuration, though not all are validated for z/OS.

By establishing a structured pipeline infrastructure, whether through remote or native agents, organizations can unify mainframe and distributed DevOps workflows. This enables consistent automation, reliable builds, and scalable CI/CD integration across hybrid IT environments.

Implementing a pipeline with a Git branching model with IBM z/OS

A branching model on z/OS makes it possible to manage a few focused pipelines that align with feature, integration (main/epic/release), and release activities. Below is a practical layout of how to implement each pipeline, how they relate to DBB/zAppBuild, and where packaging and deployment fit. The technical details are adapted from the IBM Z DevOps Acceleration knowledge base.

Working with feature branches

Developers branch from the current source of truth (main, epic, or a release maintenance branch), clone or pull the new branch locally, and implement changes there. Before commits are pushed, IBM-supported IDEs let developers run a fast DBB-backed local build to validate changes without affecting shared history.

User build (local fast feedback)

User Build uploads modified sources and required dependencies from the developer’s local workspace to a personal directory on z/OS UNIX System Services, then runs the central build framework (for example, zAppBuild) with --userBuild.

• Supported IDEs: IBM Developer for z/OS, VS Code with IBM Z Open Editor, IBM Wazi for Dev Spaces.
• Use a personal --hlq and clean up datasets and sandboxes regularly.
• Outputs are not for shared runtime use; point test JCL to personal libraries, or use a pre-concatenated runtime library for broader testing.
• External includes not in the repo can be supplied via dataset concatenation or git submodules.

Feature branch pipeline (CI on push)

After pushes to the remote feature branch, a pipeline builds the branch and runs automated inspections (for example, IDz Code Review and updates to static analysis like IBM Wazi Analyze).

• Use zAppBuild --impactBuild to compile changed and impacted programs.
• Compute a branch-unique --hlq so build datasets do not collide.
• On first run, zAppBuild clones DBB dependency collections for the branch. Set the originating collection via mainBuildBranch. Override this per workflow: keep default for main-based features, point to the release maintenance branch for hotfixes, or to the epic branch for epic work (pass overrides via zAppBuild’s command-line).

Optional: package and deploy a feature for prototyping

Teams can request an on-demand pipeline to package and deploy a preliminary feature build to controlled dev test regions (for example, a dedicated CICS region).

• Build from the branch using the fork point as baseline, then package the outputs.
• Prevent deployment of preliminary packages to production.
• Keep preliminary packages separate from release packages (use distinct libraries and an environment model like DEV-1-FEATURE-TEST).
• Establish housekeeping to remove short-lived packages and artifacts when testing completes.

Housekeeping

When a feature branch is deleted after merge, also delete DBB collections, z/OS UNIX build workspaces, and build datasets. Automate cleanup via orchestrator hooks (for example, GitLab environments and webhooks) or dedicated scripts.

Basic build pipeline for main, epic, and release branches

Every change merged into an integration branch (main/epic/release) triggers a build to validate the combined state. Optional steps like automated code review and repository updates for application discovery can be included.

Build and test stage (incremental, baseline-driven)

Build all merged changes since the last baseline using zAppBuild --impactBuild --baselineRef <commit-or-tag>, plus a branch-specific --hlq.

• For main, baseline is the prior production release tag/commit.
• For release maintenance, baseline is the commit/tag that formed the maintenance branch.
• For epic, baseline is the fork point of the epic. This decouples “build” from “deploy” and avoids rebuilding unaffected components.

Installing outputs to dev/test

Two options:

• Option A (recommended): Add package and deploy stages to create a preliminary package and deploy it through the deployment solution. This preserves traceability.
• Option B: Copy build outputs directly to runtime libraries and run activation steps (for example, Db2 binds). This is simpler but sacrifices traceability.

Analyze stage

Optionally trigger automated inspections (IDz Code Review, Wazi Analyze) and submit a SonarQube scan to monitor maintainability.

Release pipeline (build, package, deploy)

Run this pipeline on demand to produce a release candidate suitable for controlled test environments, and later the production package.

Build stage

Use the same baseline logic as above to compile all contributed and impacted changes. For main and release maintenance, compile with performance-optimized options and dedicated PDS libraries. For epic branches, test options are sufficient because artifacts will be rebuilt when integrated to main.

Package stage

Create a package containing binaries (for example, load modules, DBRMs, JCLs) and carry source metadata (commit, links to pipeline jobs) for traceability. Use naming rules that drive policy, for example:

• rel-2.1.0_RC01 (release candidate for next release; optimization enabled; can reach production)
• rel-2.0.1-patch_RC01 (urgent fix; can bypass lower environments as per emergency policy)
• epic1-prelim_pkg01 (epic preliminary; only deployable to initiative test environments)

Sample implementations:

• UCD: use CreateUCDComponentVersion to create component versions.
• Scripted/Wazi Deploy: use PackageBuildOutputs to store artifacts in an enterprise repository for IBM Wazi Deploy. Both rely on the DBB build report for metadata.

Deploy stage

• IBM UrbanCode Deploy: trigger via REST APIs from the pipeline or start deployments manually from the UI. A sample DeployUCDComponentVersion script is available.
• IBM Wazi Deploy: invoke CLI steps from the pipeline: wazideploy-generate to create a plan, then wazideploy-deploy to install to a target environment.
• Orchestrator nuances: GitLab can pause for manual promotion steps; Jenkins typically uses separate deployment pipelines or delegates to the deployment manager UI.

Deploying to production

After approvals and quality gates, deploy the release package to production using the deployment manager or a defined deployment pipeline. Tag the exact commit used to build the package (create a git tag/release via provider APIs). This maintains an auditable link from production artifacts back to source and pipeline runs.

Best practices for using IBM Z for DevOps adoption

1. Treat Z as “just another platform” (but with constraints)

While mainframes have unique operational and security requirements, treating IBM Z as part of the wider DevOps ecosystem is key to modernization. Development, testing, and deployment should use the same enterprise tooling: Git for SCM, Jenkins or GitLab for orchestration, and shared artifact repositories. This encourages consistency across platforms and eliminates the “special case” mindset that often isolates mainframe teams.

However, IBM Z systems impose specific constraints that require adaptation rather than exception handling. Build and deployment processes must respect dataset naming conventions, job scheduling policies, and RACF-based access controls. Teams should document these constraints as pipeline configuration rules rather than ad hoc practices. This approach keeps pipelines portable while maintaining compliance and operational stability.

2. Dependency-based builds for z/OS artifacts (DBB, build tools)

IBM Dependency Based Build (DBB) provides the foundation for automating z/OS builds with the same rigor as distributed systems. It tracks program dependencies, ensuring that when a component changes, only affected programs are rebuilt. This reduces build time and minimizes risk by avoiding unnecessary recompilation.

DBB integrates directly with Git and orchestration tools, allowing pipelines to run incremental or baseline-driven builds. Using frameworks like zAppBuild standardizes build logic across teams and repositories, ensuring consistent compilation parameters and output structures. Build reports generated by DBB also provide metadata essential for traceability and release management, linking artifacts to commits and pipeline runs.

3. Standardize branching and versioning strategies

Effective mainframe DevOps depends on disciplined source control and versioning practices. Adopt a branching model (such as GitFlow or a simplified feature/main/release approach) that matches team structure and release cadence. Each branch type should have defined CI/CD pipelines with consistent naming and tagging conventions.

Versioning of both code and build artifacts must be explicit. Tag releases and baseline commits to ensure reproducibility, and use semantic versioning (for example, v2.1.0 or v2.0.1-patch) to indicate compatibility and change scope. Maintaining alignment between Git tags, DBB collections, and package identifiers supports rollback, auditability, and integration with enterprise release tracking systems.

4. Automate testing and deployment early and often

Integrating automated testing into every pipeline stage reduces defects and accelerates delivery. Developers should perform fast, local validation builds before commits, followed by automated unit, integration, and regression tests in shared pipelines. IBM Z DevOps toolchains support automated test execution using zUnit for COBOL and PL/I, or third-party frameworks integrated through Jenkins or GitLab.

Deployments should also be automated using solutions such as IBM Wazi Deploy or UrbanCode Deploy. Automated packaging and deployment ensure repeatability and traceability, removing manual steps that often introduce variability. Establishing early deployment automation, even to non-production environments, lays the groundwork for reliable release and rollback processes in production.

5. Foster collaboration between distributed and mainframe teams

DevOps success on IBM Z depends on breaking down organizational silos. Mainframe teams should work in the same repositories, pipelines, and review processes as distributed developers. Using shared tools, Git for version control, shared CI/CD orchestrators, and common dashboards, enables unified workflows and visibility across the stack.

Cross-platform collaboration is strengthened by adopting consistent terminology, coding standards, and feedback loops. Regular reviews and paired work sessions between mainframe and distributed engineers improve mutual understanding of constraints and capabilities. This alignment ensures that modernization efforts extend beyond tooling to the cultural and procedural level, where true DevOps transformation occurs.

Help us continuously improve

Please let us know if you have any feedback about this page.

Send feedback