In my last post, I put together a proof of concept to demonstrate the essential elements of a MuleSoft API. In this post I plan to use that same proof of concept to show how to incorporate a continuous delivery pipeline into your API lifecycle. This is one of the first things that I always try to do, especially when working in a team, because otherwise it’s easy to end up with a development process that quickly becomes difficult to manage.
When researching tools to use for my PoC, I was looking for something cloud based, because I didn’t want to have to worry about setting up and maintaining a build server. Years ago I set up a CI/CD pipeline using Bitbucket Pipelines, which worked really well, but I wanted to use GitHub as my source control repository, so I wasn’t able to use that again. I was leaning toward trying out GitLab when I stumbled upon a relatively recent offering from GitHub, GitHub Actions.
My goal was to set up a CI/CD pipeline that would, on pushing to my master branch, build the application, version the build artifact (by labeling it with the commit hash), and then deploy it to CloudHub. The setup and configuration for this turned out to be surprisingly simple. It only required the addition of a single GitHub Actions workflow configuration file to my project and the addition of a CloudHub deployment configuration section to my application’s POM file.
Following is a detailed write up of the changes. If you’d rather skip straight to the code, you can find it in my public GitHub repository here.
The first thing I did was to create a new Java CI with Maven starter workflow under the Actions tab in my code repository. I then set to work modifying it to meet my requirements. I won’t go into too much detail here about GitHub Actions specifically. Reference documents can be found online and in the reference links section at the bottom of the post.
At a high level, the workflow is triggered by a push or pull request on the master branch and contains two jobs, one to build the app and the other to deploy it to CloudHub. Below is a screenshot of the settings for the build job. The first thing the build job does is to checkout the repo so the workflow can access it. After that, it caches the build dependencies to speed up the jobs. The next step is to set up the Java environment for building the app, since Mule apps are at their core based on Java. Next is the build and packaging step, which creates an output jar file, which is what will be deployed to CloudHub. The next step is to get the latest commit hash for the repo and add it as part of the artifact file name. This adds traceability of the application deployed to CloudHub back to the actual commit from your repo so that you know which version of the code you have deployed. The final step of the job is to upload the build artifact, which allows for sharing data between jobs, as well as providing a place to access build artifacts within your repo after the workflow is complete.
Below are the settings for the deploy job. Note that the deploy job is configured to depend on the successful completion of the build job. So if the build fails, the deploy job won’t run. The first thing the deploy job does is to checkout the repo and cache the dependencies, similar to the build job. But whereas the build job uploaded the artifact, the deploy job downloads it. Next, it gets the name of the artifact file and uses it, as well as the command line username/password arguments and the deploy configuration from the POM file, to deploy the application to CloudHub. The username/password values for authorizing the repo to log into CloudHub are stored as secrets in the GitHub repo. We’ll look at the Maven deploy configuration settings next.
Below is a screenshot of the CloudHub deployment configuration settings from the project POM file. A few things to note here. Firstly, you will have to make sure that the value for the “app.runtime” setting corresponds to a version currently supported by CloudHub in Runtime Manager. Secondly, you will need to create a name for your application that is unique across all of CloudHub. I appended my GitHub username to the app name to make it unique. One other important thing to note is the objectStoreV2 setting, which is set to true. This was to get around the fact that V1 is the default, which apparently isn’t supported in the us-east-2 region of CloudHub using an Anypoint Platform Trial account. Finally, the CloudHub region and environment may vary based on your own CloudHub configuration, but for purposes of the PoC, the worker type and number of workers that I used are more than adequate.
So that’s all there is to it! Add the cloudHubDeployment section to your POM file and add the GitHub Actions workflow file to your repo and you will have a useable CI/CD pipeline to build and deploy your Mule app to CloudHub.
Reference Links
- Proof of Concept GitHub Repo
- GitHub Actions – Building and testing Java with Maven
- GitHub Actions – Creating and storing encrypted secrets
- Deploy to CloudHub Reference (Mule Docs)
- MuleSoft KB article – Object Store V1 not supported
*Featured Image courtesy of Simon Matzinger on Unsplash.
Code Contraire 