18 docs tagged with "Release 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 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

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

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:

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