The CI/CD pipelines that we've developed include the following:
- manual build and deploy,
- build and deploy to a code artefact repository,
- deploy by retrieving code from our artefact repository and deploy to CloudHub.
Manual Build and Deploy
The pipeline follows several steps:
- First SonarQube checks the code against the API standards and conventions.
- The MUnit tests the code, reporting on any failures, and detailing out the code coverage.
- Upload the packaged code into our code artefact repository, Nexus. This maintains a historic record of all deployable API code packages.
- Deploy the code to CloudHub using the MuleSoft platform API's to carry out the interactions to deploy the API.
- The final stage of this pipeline is the execution of a related Functional Monitor. This monitor will verify the success of the API deployment and will run appropriate smoke tests to ensure the API is up and running, and the main features are returning the responses as expected. The outcome of the Functional Monitors can be viewed in the MuleSoft Anypoint Platform, but it will also send a Slack notification to a specific channel within our workspace if any errors occur.
The outcome of the whole pipeline success/failure and MUnit test results are also communicated via Slack notification. We also have access to the reports that get produced as part of the MUnit test code coverage as well as the Functional Monitor that gets triggered off at the end of the pipeline.
Build and deploy to a code artefact repository triggered off from the merge of a pull request
Our second pipeline is triggered by the merge of a pull request within our BitBucket. When that happens, it builds the code base and deploys the code into our artefact repository. This is currently configured to act when pull requests for feature branches are merged into the develop branch (which is normal practice when following GitFlow). Once the merge is complete, the Jenkins pipeline will listen to the specified repository for this action and will run the pipeline. This is done via the BitBucket plugin for Jenkins.
Deploy by retrieving code from our artefact repository and deploy to CloudHub
Our third pipeline is the process of deploying an API from the built code that is held in our artefact repository into CloudHub. Using Groovy scripts, we interact with the Nexus API to determine which API we want to deploy.
Nexus comes with various APIs out of the box that can be used to search for artefacts. We have leveraged these API's within our pipeline to narrow down which artefact to deploy: API name, the specific snapshot version of the API, and then the relevant build number within that. Once those values have been selected, we then go and select how we would like to deploy the API to CloudHub by choosing the environment, worker type, number of workers to use, and the region. Using these details, we then interact with the MuleSoft platform API's to deploy the API into CloudHub.
When we do a build with parameters, we can see the API name, what version to select, which specific build number, which environment we would like to build to, the worker type, and also how many worker numbers and then also the region.
After that, we'll just trigger off the build. And this will go pick our API of Nexus and deploy to CloudHub.
How do our customers benefit?
All 3 pipelines are easily configurable to each client's specific CI/CD requirements. The process of removing or adding stages into each pipeline is straightforward. So for example, our pipeline that currently builds the codebase on the merge of a pull request into develop branch can be configured to include stages that are defined in the manual build and deploy pipeline.
Having these pipelines available will speed up and give a significant boost to your integration journey!
Watch the other videos in this series:
