Updated: Sep 29
Github repository with the project can be found at the end of the post.
Once we start developing applications in MuleSoft and we keep our code stored in any source control platform like Github, Bitbucket, GitLab, or Azure; as a developer and as a best practice, we look into automating the process to deploy our applications to either CloudHub or an On-Premise server.
In this post I will explain how a MuleSoft application can be automatically deployed into CloudHub or an On-Premise server from Azure DevOps as our main Continuous Integration (CI) and source control platform.
Creating a new project in Azure
The first step would be to setup our project in Azure DevOps, for this you need a Microsoft account. You can get one here.
Then, we can create a new project, provide a name and a description, as well as set the privacy settings. By default you can set it as "private".
Once it is created, we can go into the main page and locate the "Repos" section. Once we see the page, we can use the information to send our code directly from our local environment.
Just before actually pushing any code we can create a pretty simple endpoint that we can hit later to verify it’s all working. Let's create a simple RAML definition in Anypoint Platform:
Then we can generate the flows in our project. Right click on the RAML file > Mule > Generate Flows from Local REST API.
Once we have our flow generated, we can proceed to create our test.yaml file in order to identify any value we want to attach to our environment.
It will look just like this:
http: port: "8081" environment: "[TEST]"
I will create a "global.xml" configuration file to keep my configurations. I will add a Configuration Properties element:
After that, we can create a Global Property, in this case called env which will allow us to know which environment we are working on.
I know, a lot of steps, right? But let's try to make it right, just before our final check to verify everything is working. Let's add an environment variable called env in our Run Configuration.
Now let's run the project. If everything was correctly set up, you'll see your project deployed!
We can start pushing our first version of this working code into our Azure repository, so let's do that.
Generating a personal access token to push our code to Azure
Let's go back into the Azure DevOps main project page:
And let's create a personal access token:
Click con Create a new token. You'll see a bunch of options, select the actions and permissions you consider are the best depending on your needs.
Once created, you'll have a new token which becomes your project password, so keep it safe!
Now we can push our code. If the terminal asks you for a password, use the token you just generated and your code should be on master.
All right, so we have our code already in Azure. Now let's create a new branch for our repository, just let's call it test based from master and let's create another one as a developer branch called emoran.
It's important to mention that during this sample on emoran branch we will review the build and in the test branch we will deploy to CloudHub.
Creating an Artifact
Before creating our pipeline we need to make sure we have the right information in our settings.xml and our pom.xml files. This artifact will allow us to get the Distribution Management piece we need to set in our project.
For this, we will need to go into our main project page, and locate the artifact option on the left, then we need to click on "Connect to feed". We select maven and then it will show the information we need to put in place in our settings.xml and pom.xml files.
Preparing the settings.xml and pom.xml files
The next task will be to prepare our files in order to make sure we will be able to build and deploy our application into CloudHub.
Here's how my settings.xml file looks like:
and here's the pom.xml:
Basically, we are specifying where is our repository for source control, and then we specify where we want to deploy our application with the cloudHubDeployment configuration into the mule-maven-pluging tag.
We can verify everything works using this command:
mvn clean install -s settings.xml -e
Creating a pipeline
Now we can create our pipeline configuration. Find the Pipelines options and select "Create Pipeline."
Select the Azure Repos Git option and select your repository from your project.
In the next step we can select Maven and then a template yaml file would be generated (we will change this eventually).
When you finish, the new yaml file will appear as part of your code. We need to modify the script, leaving it this way:
It’s important to set the variables we will use during deployment, for example: credentials to login to nexus repositories in case we need to, credentials for Anypoint Platform and the personal token we created in Azure.
Once we create our pipeline we can select the option Variables.
Finally, let's create as many as we need, according to what we need from our yaml file.
Now the last piece of the puzzle is basically to send a change from source control to Azure on the first step (sending a change to the emoran branch, for example).
We'll see our pipeline running for emoran.
When it finishes, we'll see a clean install build command for this branch.
Now all happens in source control, so if we want to deploy our application to CloudHub, then, we need to promote our changes from emoran to the test branch.
Let's create a Pull Request in Azure, from emoran to test:
Once we click on Create, then we need to complete the Pull Request and Merge Request in order to trigger the pipeline.
When the pipeline that we ran for test finishes, we can see the deployment happened this time:
So now we can go to Anypoint Platform and see our app deploying.
Finally, with this you can set as many branches you need and try other processes along.
Hope this helps others to set their process. You can find the complete code here.
Hope to hear from you on comments and let me know if this was helpful.
Our mission is to provide different levels of expertise and knowledge to those that want to keep up with the IT world. Nowadays, we all have to use technology somehow; we can work together to share what we know and what our struggles to learn were.
Contact us for suggestions.
Read more of our articles.
Meet the team and become a contributor!