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. If you missed episode one, that focused on MuleSoft reusable assets you'll find it here.
The CI/CD pipelines are:
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 from the merge of a pull request within our BitBucket. When that happens, it builds the code base and deploys the code into our artifact repository. This is currently configured to act when pull requests for feature branches are merged into the develop branch (which is normal practise when following GitFlow). Once the merge is complete, the Jenkins pipeline will listen on 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 artifact repository into CloudHub. Using Groovy scripts, we interact with the Nexus API to determine which API we want to deploy.
Nexus comes with various API's out of the box that can be used to search for artifacts. We have leveraged these API's within our pipeline to narrow down on which artifact 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 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 code base on the merge of a pull request into develop branch can be configured to include stages which are defined in the manual build and deploy pipeline.
Having these pipelines available will speed up and give a significant boots to the journey with CI/CD and MuleSoft!
Did you enjoy our 2nd video? Don't miss our next videos!