CI pipeline job

While there might be differences in details when it comes to the individual implementation examples, certain stages are common, as depicted in Basic Continuous Integration (CI) Scenario. The following are some examples:

Self-contained pipeline: For a simple self-contained pipeline example using Jenkins, follow the description for implementing a basic pipeline using the code in Mainframe-CI-Example-pipeline.
Enterprise grade pipeline: For a more realistic enterprise grade example using Jenkins shared libraries use the code in Mainframe_CI_Pipeline_from_Shared_Lib.
Non-Jenkins pipeline: For an example using Azure DevOps Pipelines - the BMC Command Line Interface and REST-APIs can be used. mainframe_ispw makes use of the CLI and REST API, using PowerShell scripts wrapped around these calls.

Task 1: Retrieving mainframe sources

The ultimate goal of this process is to use SonarQube quality gates to determine if the promoted code is ready to be released. For SonarQube to work, it needs the source code. The source code will be downloaded in one of the early steps (often the first step) of the pipeline.

Task 2: Retrieving tests for Total Test

Total Test scenarios and assets are stored in a Git server repository and need to be downloaded to the Jenkins workspace.

Task 3: Running tests

This step will run the download for the tests. Determining which tests to download or which tests to run varies based on the requirements of the individual implementation. The examples show how to download every Total Test project and execute only those test scenarios that belong to the programs that have been promoted by the developer.

Task 4: Retrieving Code Coverage statistics from the mainframe

The tests will collect code coverage data and store the results in a Code Coverage repository data set on the mainframe. To pass the results to SonarQube, they must be extracted from the mainframe repository and downloaded to the mainframe.

Task 5: Passing results to SonarQube

The sources, test run results, and code coverage data will be passed to SonarQube for analysis.

Task 6: Checking quality gate results

The analysis will be checked against a SonarQube quality gate definition. Based on the result of the quality gate check (pass or fail) further actions will be taken as following:

On failure - Regress code in Code Pipeline: If the quality gates fail, usually the code that has been promoted will be regressed (and the respective personnel will be informed about the failure).
On success - Trigger a CD release: If the quality gates pass, the code is ready to be passed onward in the application life cycle. The Jenkins example will trigger a release in XLRelease, while the Azure DevOps example will trigger an Azure DevOps release pipeline.