Elaborate CI scenario

In a more elaborate scenario the there are several stages at which Jenkins jobs get triggered, performing different tasks for each corresponding stage. The principles are the same, but in addition, there is also a set of non-virtualized functional/integration tests, and the virtualized unit tests get triggered after each generate of the code:

Step 1 - Check out code

In Total Test, a developer checks out a set of sources, copybooks and other components that are required to fulfill a specific requirement.

Step 2 - Create/maintain unit tests

In Total Test, the developer creates or modifies a set of virtualized unit tests for the modified programs. In order to share the unit tests between development teams and to use them in Jenkins, these Total Test projects are stored and administered using Git/GitHub.

Step 2a - Create/maintain functional tests

In Total Test, the developer or a QA person creates or modifies a set of non-virtualized functional tests for the application. In order to share the tests between development teams and to use them in Jenkins, these Total Test projects are also stored and administered using Git/GitHub.

Step 3 - Mainframe generate

Once the code has been changed, the developer generates (compile, link, etc.) their code within Code Pipeline. This generate, and the corresponding set container in Code Pipeline, will trigger a Jenkins job, that determines the operation and for a generate executes  Mainframe_Generate_Pipeline.groovy which runs the following process:

• Downloading the sources of exactly those (COBOL) tasks that have been generated within the set.
• Getting Total Test tests for this Code Pipelineapplication.
• Executing the virtualized tests for exactly the tasks that have been generated within the set.
• Getting Code Coverage metrics for the test executions.
• Passing all results to SonarQube using a project name that consists of the.
• Owner of the set:
  
  • Code Pipeline Stream name
  • Code Pipeline Application name
• Querying the Sonar Quality Gate
  
  • Sending mail messages informing the developer about the status of the quality gate.

The developer either continues coding or comes to a point when they think their code can be promoted.

Step 4 - Mainframe promote

Once the developer is done with development and (unit) testing, they promote their code to the next level in the Code Pipeline life cycle. This will trigger the same Jenkins job, which again determines the operation and this time for the promote executes Mainframe_Integration_Pipeline.groovy which runs a functional/integration testing process:

• Downloading the sources of all (COBOL) tasks that are at the target level of the promotion.
• Getting Total Test tests for this Code Pipeline application.
• Executing all non virtualized tests.
• Passing all results to SonarQube using a project name that consists of:
  
  • Code Pipeline Stream name
  • Code Pipeline Application name
• Querying the Sonar Quality Gate
  
  • In case that the gate was passed, an XL Release template is triggered to automate the next release process steps.
  • Sending mail messages informing the developer about the status of the quality gate.