We use automated build systems not only because they make our lives easier by taking care of building our apps, but because they can run our automated tests and deploy what we build to the target platform. One of our options for building applications (especially Mule applications) is Gradle. The Gradle plugin for Mule apps provides a variety of ways to deploy Mule apps and that’s what we’ll be covering in this post!
Note:This is the fifth part of our Gradle plugin series; be sure to check out the previous posts!
First, I want to mention what our current version of Gradle can do today. Then, I’ll introduce features that are under development for release 2.0 of the plugin.
Deployment to the local File System
This option consists on copying the resulting app (or domain) to a local runtime. There are a couple of options for configuring the target runtime:
- Through the ‘MULE_HOME’ system Variable.
- Through the Mule DSL.
This type of deployment is also available out-of-the-box by applying the basic ‘mule‘ or ‘mulestudio‘ plugin. Let’s take a look at how this is done:
export MULE_HOME=/path/to/mule
In linux / unix or:
set MULE_HOME=c:pathtomule
In windows. As well the DSL would look like the following:
mule.installPath = '/path/to/mule/home'
Now we can build, run our tests and if everything is successful deploy locally with the following command line:
$ gradle clean build deployLocally
Deployment to MMC
One of our favorite ways of deploying apps is through the Mule Management Console. Although this way does not deploy directly (it instead loads the deployable to the Management Console Repository), it allows us to do the heavy lifting. If we want a fully automated deployment, further calls to the API can be done directly through a Gradle task.
We do have a DSL for configuring multiple MMC environments and it looks like this:
Then, we can call the ‘uploadToRepository’ task to invoke the MMC API and upload to its repository. In the previous example I also externalized the selection of the environment, this is very suitable for continuous integration. Now, the command line for performing the build is:
$ gradle clean build uploadToRepository -PmmcEnv = 'prod'
Deployment to Cloudhub
For us, CloudHub is the platform of choice for SaaS integration (not restricted to only SaaS). We can very easily deploy our apps thanks to the ‘cloudhub’ plugin. This plugin performs the deployment itself and it is configured through a DSL. The following is an example of that DSL:
We can call the ‘deploy’ task to invoke the CloudHub API and deploy this application. In the previous example I also externalized the selection of the domain, this is very suitable for continuous integration (similar to the MMC settings), and allows the user to select the domain through the command line:
$ gradle clean build deploy -PchDomain = 'myapp-dev'
Features coming on Version 2.0
Currently we’re focusing con the version 2.0 of gradle, this release will join the current evolution of the product and apart for building by default 3.6.x applications, it will introduce:
- A DSL for deploying to single instances or clustered instances running the all new mule agent.
- Accept environment variables or system properties for selecting environments out of the box.
The following is a sneak peak of the DSL that we’ll be implementing for deployment to the new Mule agent:
Final Words
So this is what the Gradle plugin offers to tackle continuous integration. I would like to take the time and thank the great community effort, especially through pull requests and issue reporting. If you like what you’re seeing and would be interested in participating, please feel free to fill in this anonymous survey to help us improve this plugin:
