MuleSoft Dallas meetup group is a growing community group welcoming anyone who wants learn about MuleSoft and its existing/upcoming products. This group has participants with different levels of integration experience from experts who have been MuleSoft to newbies who just started, including individuals who never heard about MuleSoft and want to learn. As part of the group, everyone is encouraged and given opportunity to present something interesting they solved with MuleSoft or even get their problem to the meetup which they would like to discuss and get solutions.
In the most recent meetup i.e. July 20th 2017, two interesting topics were presented:
- DEVOPS: How to integrate with Jenkins with Mule project to achieve CI/CD for your integrations by Shekar Meduri
- How to run mule on a Dockerized Container and what are the benefits? by Anwesh Rijal
CI / CD using Jenkins was more of a hands on lab where Shekar helped to create a simple CI/CD project using Jenkins, tie it up with Mule application and get it auto deployed to Cloudhub.
Where as, “Dockerized Mule” by Anwesh was a quick overview about using Docker to run Mule and the benefits using docker containers.
In this blog I am going to record steps involved in using Jenkins to implement CI/CD for a Mule project. Before we begin, we need a running Mavenized Mule project and Anypoint account. If you don’t already have a mule project, you can download working sample from GitHub. Below are the steps taken for setting up Jenkins and deploying to Cloudhub:
Step1: Jenkins Setup with Maven
Download Jenkins and set it up if not already done. Since maven is being used for Mule application builds, if not already configured in Jenkins, maven can be configured by installing the Maven plugin:
Install Maven Plugin: Navigate to Jenkins –> Manage Jenkins –> Manage Plugins. Search for maven and install below plugin:
Once installed, configure Jenkins to point to Maven installation. This can be set to either automatically install or point to local directory. I have pointed on maven folder on my machine.
Step2: Create new Build Item for Mule project
Step3: Configure build
This step involves pointing to the pom file and setting up the build. If your source code is in git, you may additionally have to configure “Source Code Management” to point to the git location. Since I am using local machine I have left Source Code Management to default value as None.
In this example, at the build step, I am doing a direct deploy to cloudhub. This will also run tests and will stop if the tests failed. However, you can split it as two steps, with Build step doing just the build with running tests and then adding Post Steps for deploying to cloudhub.
In the Goals and Options, the maven command to do clean deploy is also using parameters which are anypoint platform cloudhub credentials: -Dcloudhubusername and -Dcloudhubpassword.
Step4: Configure pom file to cloudhub
In this step, we need to update pom.xml in the mule application to do two things:
- Add configuration to Deploy to cloudhub
- Add configuration to skip deployment to maven repository – This is required only if you don’t want to push to your own/maven repository as part of deploy
Adding cloudhub configuration involves adding below plugin in pom.xml:
[xml] <plugin><groupId>org.mule.tools.maven</groupId>
<artifactId>mule-maven-plugin</artifactId>
<version>2.1.1</version>
<configuration>
<muleVersion>${mule.version}</muleVersion>
<deploymentType>cloudhub</deploymentType>
<applicationName>${artifactId}-${version}</applicationName>
<username>${cloudhub.username}</username>
<password>${cloudhub.password}</password>
<workerType>Micro</workerType>
<redeploy>true</redeploy>
<environment>Sandbox</environment>
</configuration>
<executions>
<execution>
<id>deploy</id>
<phase>deploy</phase>
<goals>
<goal>deploy</goal>
</goals>
</execution>
</executions>
</plugin>
[/xml]
Most of the elements are self explanatory in the above plugin configuration. The plugin used mule-maven-plugin supports deployments to both cloudhub and standalone servers which is indicated by the deploymentType element. applicationName element accepts only alphabets/numerics with hyphens with max length of 49. So make sure to remove “.” from the version number “1.0.0-SNAPSHOT”which is by default added in pom. In my example, I just used version number as “1”.
${cloudhub.username} and ${cloudhub.password} are configured as properties:
[xml] <properties><project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
<project.reporting.outputEncoding>UTF-8</project.reporting.outputEncoding>
<cloudhub.username>${cloudhubusername}</cloudhub.username>
<cloudhub.password>${cloudhubpassword}</cloudhub.password>
<mule.version>3.8.1</mule.version>
<mule.tools.version>1.2</mule.tools.version>
</properties>
[/xml]
Values cloudhubusername, cloudhubpassword are passed during the build as shown in Step4.
One last thing to notice is that we are using goal as deploy in the plugin. Using a goal as deploy will by default trigger maven to deploy the project to repository. If you do not intend to do that which is most likely the case, you will have to add below plugin telling maven to skip the default deploy phase:
[xml] <plugin><groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-deploy-plugin</artifactId>
<configuration>
<skip>true</skip>
</configuration>
</plugin>
[/xml]
If you forget to add this and do not have a distributionManagement element, you will get an error indicating:
[ERROR] Failed to execute goal org.apache.maven.plugins:maven-deploy-plugin:2.8.2:deploy (default-deploy) on project MuleCICDWithJenkins: Deployment failed: repository element was not specified in the POM inside distributionManagement element or in -DaltDeploymentRepository=id::layout::url parameter -> [Help 1]
Step5: Once the pom file is updated, you should be able to run jenkins build by hitting “BuildNow”
Step6: Verification
Once the build is completed, you should be able to verify the logs by clicking on the build number and navigating to console output.
In Jenkins, you can get a quick glance of build status from the build history without having to go to console output. Build failure due to errors are indicated with a RED circle, build failure due to failing tests are indicated by a YELLOW circle and all successful builds are indicated by a BLUE circle
If no errors, navigate to anypoint manager to verify that the build was successfully auto deployed:
NOTE on re-deployments
If you encounter error indicating, [ERROR] Domain MuleCICDWithJenkins-2 is not available. Aborting. [ERROR] Failed to deploy MuleCICDWithJenkins-2: Domain MuleCICDWithJenkins-2 is not available. Aborting. org.mule.tools.maven.plugin.mule.DeploymentException: Domain MuleCICDWithJenkins-2 is not available. Aborting. at org.mule.tools.maven.plugin.mule.cloudhub.CloudhubDeployer.deploy(CloudhubDeployer.java:89)
there is already a open thread and github issue logged against it:
https://forums.mulesoft.com/questions/71972/redeploy-to-cloudhub-failed-becoz-domain-is-not-av.html
Source Code for Sample project
The source code used in this test can be found and downloaded from GitHub
References:
