In our second video, we take a closer look at the CI/CD pipelines that are included in the 50 days Acceleration Kit and how these can be tailored to client's specific needs and requirements. Don't miss the previous episode, which focuses on reusable assets to jump-start your API project.
The CI/CD pipelines that we've developed include the following:
The pipeline follows several steps:
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.
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.
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.
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!