26 docs tagged with "DevOps engineer"

Building, packaging, and deploying in a pipeline

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

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.

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

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 deployment manager is responsible for understanding the execution environments and maintains an inventory of the environment’s deployed content. It is used to rollout application packages. For many runtimes, copying artifacts is not enough to actually make them executable. There are numerous installation steps to perform. A good example of this would be a CICS® NEWCOPY/PHASE-IN, or, when Db2® is involved, a bind against the database of the environment.

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

This page contains installation and setup instructions for the components of our recommended CI/CD pipeline (described in our Introduction to CI/CD for z/OS®), as well as links to installation documentation for specific products. The CI/CD pipeline is based on Git for source code management (SCM), while IBM® Dependency Based Build (DBB) and zAppbuild are required for the Build component. For the remaining components of the CI/CD pipeline, enterprises will generally select one technology for each component category, although sometimes more than one IDE option is selected (depending on developer preference).

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

Also known as the CI (Continuous Integration) Orchestrator - This is where automation happens. The CI Orchestrator provides connectors to version control, build systems, and packaging and deployment. Its goal is to remove manual and repetitive tasks as much as possible. It also drives the building of the application package, includes automated unit tests, and publishes the results in an artifact repository to make them available to the provisioning and deployment practices.

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

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