Skip to main content

Base pipeline infrastructure

To begin integrating the mainframe into your enterprise CI/CD and DevOps strategy and setup, you must plan how the pipeline processes access the z/OS® build and test environments and the deployment targets.

Pipeline actions that run on the mainframe​

The main two pipeline actions that run on the z/OS platform are:

  • executing the build and package stage that includes:
    • cloning the Git repository
    • running the build framework implementation using IBM® Dependency Based Build (DBB)
    • preparing an application package that can be deployed into the runtime environments
  • driving the deployment and activation of executable application packages into the runtime environments with your selected deployment tool.

Automated testing can be included in both main actions.

These build, test, and deployment tasks are primarily command-line driven and are executed on z/OS UNIX® System Services.

Options to trigger pipeline actions​

Most pipeline orchestrators operate in a server/agent model. The pipeline orchestration server runs on a commodity infrastructure stack on a dedicated machine (bare-metal), in a virtual machine, or in a container, any of which can be hosted on-premises or by a public cloud provider.

The following diagram depicts a generic on-premises infrastructure architecture. Subsequent diagrams showcase the various options where the agent (also known as a runner or executor) can be made available for driving the z/OS-specific pipeline actions.

While agents typically run one job at a time, multiple agents are set up for scaling and allowing multiple pipelines to run concurrently.

IBM z/OS in pipeline infrastructure

In order for the pipeline orchestrator to clone the Git repository into the build workspace on z/OS UNIX System Services, credentials must be provided to allow the z/OS environment to connect to the central Git server. Typically, these credentials are managed in the pipeline configuration.

Remote agents​

If a pipeline orchestrator does not have support to run its agent natively on z/OS, then a remote agent is used to connect to z/OS via either SSH or HTTPS to drive the platform-specific actions. The pipeline creates and manages a workspace on z/OS UNIX System Services in addition to the workspace on the agent's platform.

The remote agent connects from its platform to z/OS using provided credentials of a technical z/OS account. Credentials are managed in the secret store of the pipeline orchestration platform. This allows the agents to be used across projects, which permits teams or organizations to supply their own technical user to drive the pipeline actions on z/OS.

The following diagram illustrates a pipeline orchestrator's connection to z/OS using a remote agent.

Remote agent outside of z/OS

Advantages and considerations of using remote agents include:

  • Existing pipeline infrastructure may already provide a pool of agents that can be reused for your z/OS DevOps project, easily scaling and allowing multiple pipelines to run concurrently.

  • If your pipeline platform server is managed on a cloud environment, the remote agent acts like a gateway that permits the access to the z/OS systems.

  • With the additional workspace managed on z/OS UNIX System Services, the pipeline implementation requires extra steps after the program is built on z/OS to transfer data to the remote agent's workspace in order to use the pipeline orchestrator's built-in tasks and plugins.

Connectivity options​

When using remote agents, there are several ways to connect to the z/OS environment:

  • SSH (via SSH services on z/OS UNIX System Services) allows authentication using a user ID and password, or SSH keys and certificates.

  • HTTPS uses the RSE API service that is available as part of IBM z/OS Explorer. The IBM RSE API Plug-in for Zowe™ CLI (RSE CLI plug-in) is used on the agent runtime as a simple CLI interface to communicate with z/OS and to invoke actions on z/OS UNIX System Services.

Ansible® with the IBM z/OS core collection can be used in the pipeline jobs as an abstraction layer to connect and interact with z/OS platforms.

Native agents​

Some pipeline orchestration technologies have agents that can be installed on the z/OS platform to run the pipeline steps in z/OS UNIX System Services. The z/OS-native agent is generally a long-running process under a z/OS technical user account.

Usually, the agent establishes the connection from the build machine to the pipeline orchestration service. With some pipeline orchestration technologies, the agent can be launched from the pipeline orchestration portal.

Native agent on z/OS

Advantages and considerations of using native agents include:

  • Because it is configured as a started task, the native agent can be included into system automation and workload management. z/OS engineering teams take care of the management of the agent.

  • The native agent can serve multiple projects. All actions on z/OS are performed under the authorization of the technical account, including access to data sets, subsystems, and databases (for example, when performing the Db2® bind process).

  • Pipelines often use a set of predefined tasks or plugins that are executed on z/OS in this setup. Most default steps work straight out of the box, but not all have been tested for the z/OS environment.

Last updated on

On this page