When developing your MuleSoft Applications, one of the most important things to do is correctly set up your CI/CD Pipeline. A CI/CD pipeline will help your team detect errors as quickly as possible and ensure that every change made is releasable. Setting up a CI/CD Pipeline in MuleSoft can be done in three parts.
1. GitLab config yml file
2. Setting up a config project
3. MuleSoft application deployment
1-GitLab Config.yml File
In this section, you will be looking at a sample GitLab config.yml file, the tags used in the YAML file, and how to define the variables at the project level as well as what GitLab Runners are and how to use them.
When you are setting a CI/CD pipeline in GitLab, each repo will have a .gitlab-ci.yml file that configures the CI/CD pipeline. GitLab will trigger the pipeline jobs when it detects .gitlab-ci.yml file in the project repository. Below is the YAML GitLab config file that was created for this article.
Below are the tags and environment variables that are used in the config yml file with the use of each one.
- Image: Talks about the docker image we are using.
- Variables: The list of global variables for the pipeline.
- Stages: The list of stages in the pipeline.
- Script: Runs the shell script mentioned under this tag.
- Artifacts: Specify a path to the artifact, when to start artifacts, and how long you like to store that artifact
- Dependencies: Will retrieve the artifacts.
Project Variables
Apart from the above tags, there are 4 project variables at the project level and we can access in the pipeline just like how we would access the global variables we defined at the top of the yaml file.
When navigating to Settings of the project under CI/CD settings you will find variables section where you define the variables for the project and it looks like below:
I have defined my GitLab credentials and Anypoint Platform credentials in this section
GitLab Runners
In this case, I am using a GitLab shared runner to execute my jobs and I am using a maven:3.6.1jdk8 image so I have maven setup all ready to run the build and deployment jobs. You can use your own server as a GitLab runner which is the recommended way of doing it, that way you don’t have to download dependencies each time you build, instead, store them in your server’s .m2 repo and share them across the steps with cache option that GitLab provides.
2-Setting Up Config Project
Here we will be looking at the common config project we define with a settings.xml and a template pom file. When using maven you may have a set of configurations done in settings.xml and it’s always better to keep track of the changes you are making to the settings.xml and also as we are passing the artifact from build stage to deploy stage we would like to run the mule:deploy goal of the mule-maven-plugin on the artifact instead of building the application again.
For this, we would like to have a template pom file with mule-maven-plugin in the plugin section and the configuration for the application deployment within plugin’s configuration. These are the two things that I will be storing in my config project which is another repository. We will be using these two files from this repository when running the maven commands in the pipeline.
3-MuleSoft Application Deployment
In this section, we will be looking at how we have leveraged the mule maven plugin for deploying the application to CloudHub.
The first stage of the pipeline is built and the main intention of this stage is to build the application and run unit tests. When we are building an application sometimes we may use artifacts stored in our repositories which are secured. So, in those scenarios, you would define the credentials in the settings.xml file, in our case those credentials would be stored in the settings file of the config project. At the very beginning of the build stage, I am cloning the config repo so I can use the settings file from there. My build command looks like below:
mvn -s mulesoft-ci_cd-blog-config-project/settings.xml clean package
In the above command is giving maven a custom settings file to use for the build and that would pass the credentials we have defined in the settings file for the build.
artifacts:
paths:
- target/
when: always
expire_in: 1 week
The above block of script stores the artifacts generated in the target directory for a week for both successful and failed builds.
The second stage of the pipeline is deploy, where we deploy the artifact we have built to CloudHub. We will be using mule:deploy goal of the mule-maven-plugin to deploy the artifact.
mvn -s mulesoft-ci_cd-blog-config-project/settings.xml
-f mulesoft-ci_cd-blog-config-project/pom.xml
mule:deploy -Dmule.artifact=target/mulesoft-ci_cd-blog-project-1.0.0-SNAPSHOT-mule-application.jar
-Danypoint.userName=$CLOUDHUB_USERNAME -Danypoint.password=$CLOUDHUB_PASSWORD -Dapplication.name=mulesoft-ci-cd-blog-project -Danypoint.businessGroup=AVIO Sandbox
-Danypoint.environment=DEV -Dch.workertype=$CH_WORKER_TYPE -Dch.region=us-east-2
-Dch.workers=$CH_WORKER_NUMBER
-Denv=dev -Dcrypto.key=*******
-Denv.clientId=********* -Denv.clientSecret=***********
The breakdown of the above command is as follows mvn -s mulesoft-ci_cd-blog-config-project/settings.xml is forcing maven to use the settings file defined in the config project. -f mulesoft-ci_cd-blog-config-project/pom.xml is referring to the template pom file defined in the config project and we are forcing maven to use this pom file for the build. mule:deploy is used to deploy the artifact to CloudHub in this case. -Dmule.artifact=target/mulesoft-ci_cd-blog-project-1.0.0-SNAPSHOT-mule-application.jar this is the path to the artifact that we have imported from the previous step. Also, there are a bunch of properties that we have defined in the template pom file’s mule maven plugin config and the remaining arguments are the properties we have defined in the template pom file and their values.
This is how the GitLab pipeline looks like when and it shows the jobs that are executed for each commit:
After the successful execution of the above command, we should see our application deployed to CloudHub.
Below is the configuration snippet from the template pom file for reference.
We can exclude this yaml config to the config project and have a yaml file in your project that refers to the config project’s yml file for the pipeline script and pass some of the variables from the project’s yml file to the config’s yml file. This way we can make sure we are following a uniform pattern for all projects and also any changes to the pipeline can be easily tracked in the config project.
As mentioned at the beginning of this post, getting CI/CD pipelines set up can really help your team and speed up your development time. Now that you know how to set up CI/CD pipelines for MuleSoft, your MuleSoft projects will go even smoother
AVIO is a two-time MuleSoft Partner of the Year winner, recognized for enabling customers to accelerate their digital transformation and its excellence in project implementation and practice development.
{{cta(‘7c51803f-e072-42fd-a1d5-ece0c8629db6’)}}