Episode 2

Continuous Integration and Continuous Delivery out of the box

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:

  • manual build and deploy
  • build and deploy to a code artifact repository triggered off from the merge of a pull request
  • deploy by retrieving code from our artifact repository and deploy to CloudHub
Dipan video 2 Jake voice over (captioned)

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 of the packaged code into our code artifact 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 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 artifact repository triggered off from the merge of a pull request

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.

 

Deploy by retrieving code from our artifact repository and deploy to CloudHub

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.

 

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 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!

If you have any questions regarding the issues, we covered in this video or want to discuss your challenges, talk to our integration team.

Leave quick feedback