30 docs tagged with "z/OS build engineer"

Building, packaging, and deploying in a pipeline

Once building occurs, the pipeline then publishes and stores the build outputs as a package in the artifact repository. This package contains any artifact that will need to be deployed, such as load modules, DBRMs, DDL, and the configuration files for the subsystems. Importantly, the package also contains the build artifacts' metadata and other necessary pieces of information that enable any changes to be traced back to the version control system. Depending on the system, the package can be a WAR, EAR files, a Windows installer package, among others. The artifact repository can also be used as the publishing platform to store intermediate files needed in the build phase.

This section outlines key application audit requirements and compliance practices within a z/OS® DevOps workflow.

The Build component of a continuous integration/continuous delivery (CI/CD) pipeline converts the source code into executable binaries. It supports multiple platforms and languages. In mainframe environments, it includes understanding dependencies, compile, link-edit, and unit test. The build can include the inspection of code quality to perform automated validation against a set of coding rules. In some cases, code quality inspection could also be a component of its own in the pipeline.

The DevOps Acceleration Team (DAT) offers free courses that are beneficial to learners who want to increase their DevOps skills in a holistic and engaging manner. The available courses are a mix of self-paced and remote instructor-led courses, and cover a variety of topics for different roles. An IBM®-issued Credly badge is awarded to the learner upon successful completion of each course.

DBB Migration Tool overview

An IT system is developed by many teams and composed of different applications driven by the line of businesses and consumers. Applications need to interact to provide the overall system and interact through defined interfaces. Using well-defined interfaces allows the parts of the application to be worked on independently without necessarily requiring a change in other parts of the system. This application separation is visible and clear in a modern source code management (SCM) system, allowing clear identification of each of the applications. However, in most traditional library managers, the applications all share a set of common libraries, so it is much more difficult to create the isolation.

The following diagram depicts the typical workflow to deliver changes for the next planned release. In the default workflow, the development team commits changes to the head of the main branch. The changes of the next planned release are built, packaged, and released from the main branch.

The build step contains all the steps to compile and link the source files into executable code. This page focuses on the different build strategies to support build scenarios at different phases of application development, and points to the relevant sections within the shared sample scripts via IBM®'s zAppBuild repository.

This page covers the essentials of working with Git and introduces some vocabulary and concepts that may feel unfamiliar to those coming from a z/OS application development background. To help with the new terminology and conceptual mapping that come with moving to Git, the following diagram draws analogies between legacy mainframe SCM processes and DevOps with Git on z/OS.

As Git became the de facto version control system in today's IT world, new terminologies such as "repositories", "branches", and "merges" arose. By agreeing upon a central Git server to integrate and consolidate changes, development teams were able to collaborate more efficiently and effectively. Building upon the open-source vanilla Git implementation, popular Git providers including GitHub, GitLab, and Bitbucket have implemented additional workflow features to facilitate a secure and stable development process. These include features such as pull requests (sometimes referred to as "merge requests") to support coordination with Git in larger teams. The term "pull request" will be used throughout this page to designate the operation of reviewing and merging one branch into another.

The video series on this page demonstrates the process for delivering changes with the next planned release using our recommended Git branching model for mainframe application development. This four-part demo series starts with a conceptual walkthrough of the Git branching model, and then follows the activities of an application developer, development lead, and release manager as they each interact with different parts of a sample CI/CD pipeline to deliver changes for their team's upcoming release.

The process of urgent fixes for modules in the production environment follows the fix-forward approach, rather than rolling back the affected modules and reverting to the previous deployed state.

This page details the technical implementation of the different continuous integration/continuous delivery (CI/CD) pipeline types used in the Git branching model for mainframe development. If a branching model workflow demands a specific configuration, it will be covered within the same section.

After the initial setup of your CI/CD pipeline tools (as described in Installing and configuring your tools), pipelines should be configured in a way that promotes best practices and efficient workflows. This section focuses on resources to help you implement our recommended Git branching model for mainframe development:

Common Back-end Scripts

Introduction to CI/CD

How a team employs Git's fundamental feature to create branches, commit changes to them, and flow sets of changes for review and

Introduction

Manual migration of source data from z/OS® to Git is generally not recommended, as it tends to be slower, more tedious, and prone to human error. However, it is possible, and can be done several ways, including the following:

Migrating your source code data from z/OS® to Git is one of the first steps in implementing a modern CI/CD pipeline. Once you have planned your to-be Git repository layouts, you can use the steps in this section to migrate your data from z/OS to Git.

Introducing deployment managers

Because the traditionally large and monolithic nature of enterprise applications can slow down development both at the organizational level and the individual developer level, many enterprises take the migration to Git as an opportunity to examine how they can break their monolithic applications down into more agile functional Git repositories. The repository layout in the source code management (SCM) component of the continuous integration/continuous delivery (CI/CD) pipeline affects other pipeline components in several ways:

Once the Git-based CI/CD pipeline and DevOps tools are set up, they can be used by various end user roles throughout the software development lifecycle. The following sections show typical examples of key end user role interactions with the DevOps tooling and automation, including:

Introduction

A source code management (SCM) tool manages and stores different versions of your application configuration such as source code files, application-specific configuration data, test cases, and more. It provides capabilities to isolate different development activities and enables parallel development.

When migrating data from z/OS to Git, you may encounter potential issues with migrating non-printable or non-roundtrippable characters. Managing code page conversion describes the background behind these issues, as well as options for how to handle them. Once you have decided on a plan for how to handle potential non-printable and non-roundtrippable characters, you can use the following steps to migrate your data from z/OS to Git:

IBM Z Systems software trials (IBM Z Trial)

Let us now focus on change requests that represent significant work effort and require major changes, for instance, due to updates in regulatory frameworks in the banking or insurance industry, or the need to already kick off the development phase of features not planned to be delivered in the very next release.

Working with overlapping releases