MettleCI Example Pipeline for DevOps
MettleCI ships with a set of example pipelines which demonstrate how to use the MettleCI command line to compose a pipeline which satifies a number of scenarios.
This example uses a screenshot from Jenkins (below). From a MettleCI perspective, the process is identical regardless of the build tool being used.
Jenkins, unlike other automation platforms has split the Build and Deployment sections of the process into their own separate pipelines.
Note: Jenkins also forces a Java version incompatibility issue upon the MettleCI CLI, whereby the agent running the pipelines (and therefore the MettleCI CLI) does not support Java 8, which is required by the MettleCI CLI. We resolve this issue in our pipelines by instructing Jenkins to explicitly set the Java version when running scripts, but it results in additional messages at the beginning of every stage that we have removed from this documentation for the sake of clarity.
DevOps Build
When an update has been committed and pushed to the MettleCI project repository, the Build pipeline is called automatically.
1. Diagnostics 11.7
This stage is simply a diagnostic step to help with initial development of your pipeline. Once you have confirmed that your pipeline is behaving as required you can safely delete this step.
# | Task | Command | Description |
---|---|---|---|
1 | Diags 11.7 | various | Uses the Build Agent to log environment variables and variable groups for diagnostics purposes. |
2. Deploy CI
Deploy to Continuous Integration
This Job is defined in pipeline template mci_deploy.groovy
# | Task | Command | Description |
---|---|---|---|
1 | Create DataStage Project |
| Verify that the CI project exists (otherwise, create it). |
2 | Substitute parameters in DataStage config |
| Replace variables in the This example operates on *.sh files in the 'datastage' base directory, the DSParams file, and all Parameter Sets using values from the file 'var.ci' (as determined by the environmentId parameter) // Substituted files are created in a new temporary build directory on your build agent host called 'config'
|
3 | Cleanup temporary files from previous builds |
| Execute your |
4 | Transfer DataStage config and filesystem assets |
| Upload the |
5 | Deploy DataStage config and file system assets |
| Execute your |
6 | Deploy DataStage project |
| Perform an incremental deployment of your DataStage assets to the CI project. |
7 | Cleanup |
| Execute the script |
8 | Find files in the workspace | Inline script | Detects and records (in a build pipeline variable) whether the Job compilation performed by the Deploy DataStage assets task produced an output JUnit |
9 | Archive JUnit-formatted test results | Build tool specific | If a JUnit |
3. Test CI
Compliance Test CI Warnings
This Job is defined in pipeline template mci_compliance.groovy
.
# | Task | Command | Description |
---|---|---|---|
1 | Check out from version control | Build tool specific | Make the Compliance repository (separate to the DataStage asset repository, where this pipeline definition is stored) accessible to the build agent. |
2 | Compliance Test - Warnings |
| Invokes MettleCI Compliance checks for changes jobs. Note that in this mode (including the
|
3 | Find files in the workspace | Build tool specific | Detects and records (in a build pipeline variable) whether the Compliance check performed by the Run Compliance task produced an output JUnit |
4 | Archive JUnit-formatted test results | Build tool specific | If a JUnit |
Compliance Test CI Failures
This Job is defined in pipeline template mci_compliance.groovy
# | Task | Command | Description |
---|---|---|---|
1 | Check out from version control | Build tool specific | Make the Compliance repository (separate to the DataStage asset repository, where this pipeline definition is stored) accessible to the build agent. |
2 | Compliance Test - Errors |
| Invoke MettleCI Compliance checks for changes jobs. Note that in this mode (omitting the |
3 | Find files in the workspace | Inline script | Detects and records (in a build pipeline variable) whether the Compliance check performed by the Run Compliance task produced an output JUnit |
4 | Archive JUnit-formatted test results | Build tool specific | If a JUnit |
Unit Test
This Job is defined in pipeline template mci_unittest.groovy
# | Task | Command | Description |
---|---|---|---|
| Configure Properties |
| Replace variables in the // Substituted files are created in a new temporary build directory on your build agent host called 'config'. |
7 | Cleanup |
| Execute the script stored in the repository file |
2 | Upload unit test specs |
| Upload your repository’s |
4 | Create unit test report dir |
| Create directory to receive unit test outputs. |
5 | Run Unit Tests |
| Invoke the Unit Tests defined in your |
6 | Download unit test reports |
| Download any JUnit |
8 | Find files in the workspace | Inline script | Detects and records (in a build pipeline variable) whether the Unit Test execution performed by the Run Unit Tests task produced an output JUnit |
9 | Archive JUnit-formatted test results | Build tool specific | If a JUnit |
4. Success - Tag Repository
If the build ran successfully, tag the repository.
# | Task | Command | Description |
---|---|---|---|
1 | Tag current build | various | Adds a tag to the commit that triggered the successful build, thereby identifying it as a candidate for deployment into the QA environment. The tag is in the format ci-{build_number}. |
DevOps Deploy
Once the DevOps Build pipeline has run successfully for a particular checkin, it will have been marked as a candidate for deployment into the first of the testing environments used by the MettleCI example pipelines: QA.
The DevOps Deploy pipeline is triggered manually when one of the possible candidate tags is chosen to be deployed.
The MettleCI example pipelines use different environments to illustrate a promotion path from Development (and automatic Compliance and Unit Testing in CI via the Build pipeline), then QA, Perf and finally Prod. Unlike the pipelines for other supported platforms, Jenkins separates Build from Deployment, but also only deploys to one environment per running of the DevOps Deploy pipeline, using the repository tags to determine what can be promoted..
1. Select Release to Deploy
This first step determines which tag is being promoted to which environment.
The first step is to choose the target environment, out of qa, perf and prod.
Based on the chosen target environment, the user is presented with a list of candidate tags that enforce the proper progression towards Production:
qa - user is only presented with tags starting with “ci-”
perf - only “qa-” tags
prod - only “perf-” tags
Given the fact that a deployment into the Perf environment has to be successful in order to be tagged with a “perf-” tag and only “perf-” tags can be deployed into Production, this ensures that code cannot be deployed directly into Production.
# | Task | Command | Description |
---|---|---|---|
1 | Tag current build | various | Calls upon the the user to choose the target environment, and then choose the desired tag from the list of approved candidates. |
2. Deploy - Target
This Job is defined in pipeline template mci_deploy.groovy
# | Task | Command | Description |
---|---|---|---|
1 | Create DataStage Project |
| Verify that the CI project exists (otherwise, create it). |
2 | Substitute parameters in DataStage config |
| Replace variables in the This example operates on *.sh files in the 'datastage' base directory, the DSParams file, and all Parameter Sets using values from the file 'var.ci' (as determined by the environmentId parameter) // Substituted files are created in a new temporary build directory on your build agent host called 'config'
|
3 | Cleanup temporary files from previous builds |
| Execute your |
4 | Transfer DataStage config and filesystem assets |
| Upload the |
5 | Deploy DataStage config and file system assets |
| Execute your |
6 | Deploy DataStage project |
| Perform an incremental deployment of your DataStage assets to the CI project. |
7 | Cleanup |
| Execute the script |
8 | Find files in the workspace | Inline script | Detects and records (in a build pipeline variable) whether the Job compilation performed by the Deploy DataStage assets task produced an output JUnit |
9 | Archive JUnit-formatted test results | Build tool specific | If a JUnit |
3. Success - Tag Repository
If the build ran successfully, tag the repository.
# | Task | Command | Description |
---|---|---|---|
1 | Tag current build | various | Adds a tag to the commit that triggered the successful build, thereby identifying it as a candidate for deployment into the next environment. ie: if the current run successfully deployed a “ci-” tag into QA, the commit the tag was related to also receives a “qa-” tag, identifying it as a potential candidate for deployment into the Perf environment. |
4. Calling Hotfix Creation Pipeline
The Jenkins DevOps pipeline example is extended to cover a Production hotfix scenario, whereby hotfix changes can be made against a copy of the Production DataStage project. This allows for quick turnaround on critical Production issues without attempting to fix DataStage jobs directly in Production.
# | Task | Command | Description |
---|---|---|---|
1 | Building Jenkins-DevOps-Hotfix-Create | various | If the current deployment was into the Production environment, run a separate Jenkins pipeline that updates a special hotfix DataStage project to always be in line with the Production project, and also create a separate branch in the git repository to manage any hotfix changes that may be made. |
Notes
Note that every build Job has implicit access to the DataStage asset repository where this pipeline definition is stored. Some build tools make this explicit and produce a log entry showing this. For example Azure DevOps automatically introduces a task at the beginning of each Job with a title for the form
Checkout <repository-name@<branch> to s\<project-name>
.Below is the Azure version of the complete DevOps pipeline. This illustrates the way the other automation platform pipelines are structured in terms of the Build and Deploy processes. Arranging them in a continuous pipeline with explicit approval each deployment step (not including CI) enforces the order of deployment through to Production.
© 2015-2024 Data Migrators Pty Ltd.