CI/CD Pipeline using Azure DevOps

How-to- create a CI/CD Pipeline using Azure

DevOps
 CI/CD Pipeline using Azure DevOps

Introduction 3

Scope 5

Out of Scope 6

Prerequisite 7

Audience 8

Modules/Plugin Versions 9

How-To 10
Creating a Connected App 10
Setting up variable groups and secure files 11
Variable Groups 11
Secure Files 13
Pom file 14
Build Pipeline Configuration 16
Build Pipeline (from develop branch) 16
Build Pipeline (from main branch) 30
Maven Release Plugin configuration 40
Running the main branch build pipeline 44
Release pipeline configuration 46
Executing the Release Pipeline 54

Best Practices 56
YAML Editor over Classic UI 56
Classic UI 56
YAML Editor 57
Example 58
Azure Key Vault 58
Managing Variable groups 58
Setting up Azure Service Connections 59

References 60
 CI/CD Pipeline using Azure DevOps

Introduction
The purpose of the following article is to describe the step by step process for implementing a
basic CI/CD Pipeline using the Mule Maven Plugin and the Maven Release Plugin in Azure
DevOps.

Process overview:
Develop branch : On merge/commit over the "develop" branch, a job is executed and the
generated artifact is deployed in the DEV environment.
main/release branch : On merge/commit over the "main" branch or manual trigger, a job is
executed for releasing a new version of the application. The generated artifact is deployed to
either Anypoint Exchange and the Azure Binary Repository (not a SNAPSHOT). The
generated an artifact can then be promoted to the TEST and PROD environment.
The instructions in this article might not work on different versions of the product.
 CI/CD Pipeline using Azure DevOps

The instructions in this article might not work on different versions of the product.

If there are issues with the approach in the article, please provide feedback. If you experience
any issues with Microsoft Azure DevOps or any non-MuleSoft related products, please refer to
the relevant vendor's documentation or customer support.

The scope / complexity of a CI/CD Pipeline might vary depending on several factors. This
should not be taken as a silver bullet. The main goal is to show different aspects that need to
be considered and serve as a guideline for Azure DevOps configuration.
 CI/CD Pipeline using Azure DevOps

Scope
CI/CD Pipeline configuration using Azure DevOps. Example use cases for CICD are limited to

build, package, release prepare:perform and deployment on Mule CH.

 CI/CD Pipeline using Azure DevOps

Out of Scope
Other Mule project CICD scopes like Deploying on-prem or RTF, MUnit test coverage and
reports upload, Promoting API instances to higher environment, flex GW CD, provisioning the
CH environments (setup AMQ, Policies label, SLA tiers, mapped to new API etc ..) etc (not
limited to) are not covered in this example tasks.
 CI/CD Pipeline using Azure DevOps

Prerequisite

● Azure DevOps project is created under your organization.

● Admin Access to Azure DevOps - project level
● Repos are maintained within Azure Repos.
 CI/CD Pipeline using Azure DevOps

Audience

● Application / Operator Admin

● C4E Architects / Architects
● C4E Core Developers / Developers
 CI/CD Pipeline using Azure DevOps

Modules/Plugin Versions
As a reference, here is the list of Modules/Plugins Versions used for writing the article.

Mule Runtime 4.X

Maven Release Plugin 2.5.3

Mule Maven Plugin 3.3.5

 CI/CD Pipeline using Azure DevOps

How-To

Creating a Connected App

In Anypoint Platform execute the following steps to create a Connected App.

● From the root Business Group, go to the Main Menu Access Management Connected
Apps and click on the Create App button.
● Give a name for the App. E.g.: AzureDevOpsApp.
● Select the option "App acts on its own behalf (client credentials)".
● Add the following Scopes like the image below.
● These are the necessary ones to deploy applications and publish assets to
exchange.
● You must add the Design Center Developer or it will not work.
● You will need to select for some of the Scopes the Business Groups and
Environments that this App will be able to do such actions. You may adjust these
Scopes to allow other actions. E.g. Apply policies in API Manager.

● Your configuration will be like the image below.

 CI/CD Pipeline using Azure DevOps

● Save and copy the Client ID and Secret of the newly created Connected App to use in
the next steps.

Setting up variable groups and secure files

Variable Groups

Variable Groups are frequently used to store values that are desirable to make available across
the pipelines. Additionally, they can be used to store secrets and credentials that are going to
be needed into our build and release pipelines. We are going to create the following variable
groups:

● Anypoint Platform <environment>:

● the environment name, the client id and client secret for each environment.
 CI/CD Pipeline using Azure DevOps

Steps

1. Log into Azure DevOps, select your Project and go to Pipelines → Library:
 CI/CD Pipeline using Azure DevOps

2. Create a new Variable Group, assign a name/description and add the required variables
and verify the correct configuration of each Variable Group:

Problem with Variable Groups in Azure DevOps is there's no history attached to change log for
any modifications. so while no-one else can read your secure password, but accidentally
overwrite it or modify - eventually build failure.

Important Tips is to have another dedicated variable group for secrets per environment and it
should be access protected - limited to Admin. This access protection read/write/manage
applies to non secure files too.

Secure Files

This setup is optional. It's recommended to use azure secure connection. If you plan to use
azure secure connection, skip this setup.

Important Note - If for some reason, you have to use settings.xml instead of secure
connection, remember, If you have to change the settings.xml, azure devops will remove
secure file reference from secure step in all pipelines. This must be manually updated. To avoid
manually updating each (common) step for each repo’s pipeline, “Task Group” feature is
recommended. A task group allows you to encapsulate a sequence of tasks, already defined in
a build or a release pipeline, into a single reusable task that can be added to a build or release
pipeline, just like any other task. You can choose to extract the parameters from the
encapsulated tasks as configuration variables, and abstract the rest of the task information.

The new task group is automatically added to the task catalog, ready to be added to other
release and build pipelines. Task groups are stored at the project level, and are not accessible
outside the project scope. Refer official documentation for more information.
 CI/CD Pipeline using Azure DevOps

Secure Files (maven settings.xml) can be used to encrypt valuable resources that will be
needed during the build and release pipelines. In this case, we are going to upload two files
into the Secure Files Library.

● The Maven settings.xml file containing:

● Mulesoft Enterprise Repository Nexus Credentials.
● Mule Exchange and Anypoint Exchange v2 repositories.
● GIT Repository Credentials (this is going to be used by the Maven Release
Plugin).

Steps

1. Go to Pipeline → Library → Secure files.

2. Click the Add Secure File, and browse into your file systems the items that need to be
uploaded.

Pom file

A pom.xml file that is going to be used during the release pipeline to deploy the generated
artifact. This consists of a typical Maven pom.xml file for Mule Applications containing the Mule
Maven Plugin configuration of your deployment model. E.g: CloudHub Deployment Reference.
 CI/CD Pipeline using Azure DevOps

<?xml version="1.0" encoding="UTF-8" standalone="no"?>

<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd">
<modelVersion>4.0.0</modelVersion>
<groupId>com.mulesoft.services</groupId>
<artifactId>services-azure-devops-mule-deployer</artifactId>
<version>1.0.0</version>
<packaging>mule-application</packaging>
<name>services-azure-devops-mule-deployer</name>
<properties>
<project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
<project.reporting.outputEncoding>UTF-8</project.reporting.outputEncoding>
<app.runtime>4.2.2</app.runtime>
<mule.maven.plugin.version>3.3.5</mule.maven.plugin.version>
</properties>
<build>
<plugins>
<plugin>
<groupId>org.mule.tools.maven</groupId>
<artifactId>mule-maven-plugin</artifactId>
<version>${mule.maven.plugin.version}</version>
<extensions>true</extensions>
<configuration>
<cloudHubDeployment>
<uri>https://anypoint.mulesoft.com</uri>
<muleVersion>${app.runtime}</muleVersion>
<connectedAppClientId>${EnvironmentClientId}</connectedAppClientId>
<connectedAppClientSecret>${EnvironmentClientSecret}</connectedAppClientSecret>
<connectedAppGrantType>client_credentials</connectedAppGrantType>
<applicationName>${cloudhub.application.name}</applicationName>
<environment>${environment}</environment>
<businessGroupId>${business.group.id}</businessGroupId>
<workers>${workers}</workers>
<workerType>${workerType}</workerType>
<artifact>${artifact}</artifact>
<properties>
<anypoint.platform.client_id>${anypoint.platform.client.id}</anypoint.platform.client_id>
<anypoint.platform.client_secret>${anypoint.platform.client.secret}</anypoint.platform.client_secret>
<mule.env>${environment}</mule.env>
</properties>
</cloudHubDeployment>
</configuration>
</plugin>
</plugins>
</build>
<pluginRepositories>
<pluginRepository>
<id>mulesoft-releases</id>
<name>mulesoft release repository</name>
<layout>default</layout>
<url>https://repository.mulesoft.org/releases/</url>
 CI/CD Pipeline using Azure DevOps

<snapshots>
<enabled>false</enabled>
</snapshots>
</pluginRepository>
</pluginRepositories>
</project>
 CI/CD Pipeline using Azure DevOps

Build Pipeline Configuration

In this section, we are going to talk about two pipelines in detail : pipeline from the develop
branch and pipeline from the main branch.

Build Pipeline ( from develop branch) : I am going to assume that developers work over feature
branches which are obtained from a develop branch. When there is a merge into the develop
branch, a build pipeline is going to be executed which will deploy the artifact into the DEV
environment for testing purposes only. This pipeline should be run with some regularity and it's
not expected to keep these builds as this basically consists of a developer checking that the
project works as it is expected.

Build Pipeline ( from main branch) : Additionally, we are going to create a separate pipeline
used as part of the release process. The idea is to execute this pipeline when the team reaches
a milestone of some sort. This pipeline is going to be triggered from the main branch, release a
new version of the application and deploy the generated artifact into Anypoint Exchange in
case an easy rollback is needed from Runtime Manager. As part of this process, the artifact is
also copied into the Azure Staging Directory.

Build Pipeline (from develop branch)

High-level, this pipeline contains the following tasks:

1. Get sources from the develop branch (checkout GIT project).

2. Download the settings.xml secured file from Azure library.
3. Execute the Maven test phase.
4. Execute the Maven package phase.
5. Deploy the generated artifact into the DEV environment (using the Mule Maven Plugin).

Steps

1. Log into Azure DevOps, select your Project and go to Pipelines → Pipelines → New
pipeline.
 CI/CD Pipeline using Azure DevOps

2. Switch to the Classic Editor view.

3. Select a source (e.g.: Azure Repos Git), the project / repository and finally set the default
branch to develop based on the previous explanation. Once finished, click the continue
button.
 CI/CD Pipeline using Azure DevOps

4. Among the available templates choose Maven and click the Apply button.
 CI/CD Pipeline using Azure DevOps

5. Edit pipeline name and delete the Copy Files and Publish Artifact tasks. After saving
your changes the pipeline should looks as follows.

6. There are two options to authenticate the maven repo. static settings.xml or leverage
azure devops service connections
 CI/CD Pipeline using Azure DevOps

Option - 1 azure service connections

Service connections can be set up as per the screenshot below. The configuration is available
within the Project Settings tab with the right permissions - e.g. Project Administrators /
Endpoint Administrators.

When creating a new Service Connection, the following steps can be followed:

1. Select Service Connection type. This would be Maven for the majority of use cases for
Mule applications
 CI/CD Pipeline using Azure DevOps

2. Enter Service connection details based on repository connection credentials - e..g for Nexus
and Exchange.
Note that for Exchange, the username would be '~~~Client~~~' and password would be
'ClientId~?~ClientSecret' if using connected apps. See details here -
https://docs.mulesoft.com/exchange/to-publish-assets-maven#publish-and-consume-federat
ed-assets
CI/CD Pipeline using Azure DevOps
 CI/CD Pipeline using Azure DevOps

Use Service Connections within Build configuration using Maven Authenticate Task
Azure Service Connections can be referenced within pipeline configurations using the Maven
Authenticate Task -
https://docs.microsoft.com/en-us/azure/devops/pipelines/tasks/package/maven-authenticat
e?view=azure-devops

Note that Maven Authenticate supports both Service Connections as well as Azure Artifact
Feeds so this is extremely handy if you also need to publish or consume assets from Azure
Artifacts feeds

Add Maven Authenticate tasks via code

- task: MavenAuthenticate@0

inputs:

artifactsFeeds: 'ndesouza'

mavenServiceConnections: 'Mule Nexus'

Add Maven Authenticate tasks via UI

1 - Add the Maven Authenticate Task to your pipeline configuration

2 - Configure Service connections and Artifact Feeds

 CI/CD Pipeline using Azure DevOps

Option - 2 settings.xml

1. Click the Add task button, search for "Download secure file" and click the Add button.

2. Drag the task to the top of the pipeline and rename as "Download settings.xml". Finally,
select the "settings.xml" file from the drop-down list. Note : if you have multiple
settings.xml for various environments, select respective to this pipeline/job.
 CI/CD Pipeline using Azure DevOps

7. Click the Add task button for adding other two Maven tasks. You should have a total of
three; one for each Maven build lifecycle phase (Test, Package and Deploy).
8. Maven Test Phase Configuration.
a. Select the first Maven Task and rename as Test.

b. Set the goal to:

clean test

c. In the options set a reference to the downloaded settings.xml file from the
Azure Library:

-s $(Agent.TempDirectory)/settings.xml
 CI/CD Pipeline using Azure DevOps

d. Check the Publish to Azure Pipelines checkbox.

9. Maven Package Phase Configuration.

a. Select the second Maven Task and rename it to Package.

b. Set the goal to:

clean package -DskipTests

c. Set the options to:(optional, use only if you have not used secure connection)
 CI/CD Pipeline using Azure DevOps

-s $(Agent.TempDirectory)/settings.xml

d. Uncheck Publish to Azure Pipelines.

10. Mule Maven Deploy Configuration (to DEV environment).

a. Select the third Maven Task and rename to Deploy Dev.

b. Set the goal to:

clean package deploy -DskipTests -DmuleDeploy

c. Set the options to:

 CI/CD Pipeline using Azure DevOps

-Danypoint.platform.client.id=<<EnvironmentClientId>>
-Danypoint.platform.client.secret=<<EnvironmentClientSecret>>
-Dbusiness.group.id=$(BusinessGroupId)
-Danypoint.platform.client.id=$(ClientId)
-Danypoint.platform.client.secret=$(ClientSecret)
-Dcloudhub.application.name=$(Environment)-contacts-sapi-v1
-Denvironment=$(Environment) -Dworkers=2 -DworkerType=MICRO

Note: These parameters will depend on your deployment model. This example
is based on the Deploy to CloudHub configuration. For further information
please refer to Mule Maven Plugin configuration.

Notice that the parameters configured in this step belong to the ones added
into the Variable Groups as part of the initial configuration.
 CI/CD Pipeline using Azure DevOps

d. Uncheck Publish to Azure Pipelines and click the Save & queue → Save button.

11. (OPTIONAL) In order to prevent executions of this pipeline from a different branch (e.g.:
main), on each of the configured tasks (Test, Package and Deploy) you can add the
following configuration so that the task executes only when the previous task finishes
successfully and the pipeline has been triggered from the develop branch:
a. Expand Control Options.
b. Set Run this task to Custom conditions.

c. Set Custom condition to:

and(succeeded(), eq(variables['Build.SourceBranch'],
'refs/heads/develop'))
 CI/CD Pipeline using Azure DevOps

Ref.: Specify Conditions

d. Repeat for the Test, Package and Deploy Dev Maven tasks.
12. Pipeline Variables Configuration.
a. From the build pipeline view, select Variables → Variables Groups → Link
variable group.

b. Link the "Anypoint Platform DEV Variables" variable group which contains the
required variables for the Development deployment.

c. Finally, click the Save & Queue → Save button.

 CI/CD Pipeline using Azure DevOps

13. From the build pipeline view, select the Triggers tab and check the Enable continuous
integration option. Set the branch filters to develop.

14. Finally click the Save & Queue → Save button.

 CI/CD Pipeline using Azure DevOps

Build Pipeline (from main branch)

The first part of the build pipeline is pretty similar to the one we have seen before. This means
that we are going to get a stable version of the code (in this case from the main branch) and we
are going to test and package using the Maven task. Additionally, we are adding the use of the
Maven Release Plugin which simplifies the release of project artifacts and to update the
project's SCM accordingly. We are also going to store the generated artifact into Azure DevOps
in order to use in the release pipeline to promote the artifact across the environments (e.g:
TEST and PROD) and also upload it into Anypoint Exchange.

High-level, this pipeline contains the following tasks:

● Get sources from the main branch (checkout GIT project).

● Authentication:
○ Option-1 : Download the settings.xml secured file from Azure library.
○ Option-2 : Setup Secure connection
● Execute the Maven test phase.
● Execute the Maven package phase.
● Execute the release:prepare goal (using the Maven Release Plugin).
● Execute the release:perform goal (using the Maven Release Plugin).
● Copy build artifact to staging directory.
● Publish the artifact to Azure Pipelines (container).

Steps

1. Log into Azure DevOps, select your Project and go to Pipelines → Pipelines → New
pipeline.
2. Switch to the Classic Editor view.
3. Select a source (e.g.: Azure Repos Git), the project / repository and finally set the default
branch to main based on the previous explanation. Once finished, click the continue
button.
4. Among the available templates choose Maven and click the Apply button.
5. Edit pipeline name.
6. Click the Add task button, search for "Download secure file" and click the Add button.
7. Drag the task to the top of the pipeline and rename it as "Download settings.xml".
Finally, select the "settings.xml" file from the drop-down list.
8. Click the Add task button for adding other "three" Maven tasks. You should have a total
of four; one for each Maven task (Test, Package, Release Prepare and Release Perform).
 CI/CD Pipeline using Azure DevOps

9. Configure the Maven Test Phase (as you did in the previous pipeline).
 CI/CD Pipeline using Azure DevOps

10. Configure the Maven Package Phase (as you did in the previous pipeline).

11. Set GIT identity. As the Maven Release Plugin runs SCM commands in the background
(e.g: to update artifact version in the POM file, creating a tag, etc); we are going to use a
script to enable the use of GIT commands.
a. Click the Add task button, search for Bash script and place immediately after the
Maven Package task.
b. Set the Display name to Set GIT identity.

c. Set as inline type and use the following commands to configure the GIT identity.

git config --global user.email "[email protected]"

git config --global user.name "Your Name"

git checkout main

 CI/CD Pipeline using Azure DevOps

Ref.: Run Git commands in a script

12. Maven release:prepare goal configuration.

a. Select the fourth Maven task and rename as Release Prepare.

b. Set the goal to:

release:prepare --batch-mode

c. Set the options to:

-Darguments='-DskipTests’
 CI/CD Pipeline using Azure DevOps

d. Finally, uncheck the Publish to Azure Pipelines option. Note : this step requires
you to pass azure credential.

13. Maven release:perform goal configuration.

a. Select the last Maven task and rename it as Release Perform.

b. Set the goal to:

Release:perform

c. Set the options to:

-Darguments='-DskipTests’
 CI/CD Pipeline using Azure DevOps

d. Finally, uncheck the Publish to Azure Pipelines option.

14. (OPTIONAL) In order to prevent executions of this pipeline from a different branch (e.g.:
develop), on each of the configured tasks you can add the following configuration so
that the task executes only when the previous task finish successfully and the pipeline
has been triggered from the main branch:

a. Expand Control Options.

b. Set Run this task to Custom conditions.

c. Set Custom condition to:

and(succeeded(), eq(variables['Build.SourceBranch'],
'refs/heads/main'))
 CI/CD Pipeline using Azure DevOps

d. Ref.: Specify Conditions

e. Repeat for all the other tasks in the pipeline.

15. We need to copy the artifacts that was generated by package task

a. Add Task called "Copy Files"

b. Name the step : Copy Files to: $(Build.ArtifactStagingDirectory)

c. Add below code into Source Folder

 CI/CD Pipeline using Azure DevOps

$(Build.SourcesDirectory)

d. Add below code into Contents

**/*

e. Add below code into Target Folder

$(Build.ArtifactStagingDirectory)
 CI/CD Pipeline using Azure DevOps

f. Note : Complete task would look like this

16. We need to publish the artifacts that were copied by the previous task.

a. Add Task called "Publish build artifacts"

b. Name the step : Publish Artifact: drop

c. Add below code into "Path to publish"

$(Build.ArtifactStagingDirectory)
 CI/CD Pipeline using Azure DevOps

d. Add below code into "Artifact name"

drop

e. Select "Azure Pipelines as publish location"

f. Note : Complete task would look like this

17. Click the Save & Queue → Save button.

18. Finally, Click “Save as a template”. After you save this template, you can use it later when
you will create a new build pipeline.
CI/CD Pipeline using Azure DevOps
 CI/CD Pipeline using Azure DevOps

Maven Release Plugin configuration

Before you trigger the main branch pipeline, please make sure to set up maven release plugin
dependencies.

Note: To use the Maven Release Plugin the following configuration is needed in your Mule
Application. Ref.: Maven Release Plugin. Ref.: Release.

When using the release:prepare goal, we need to supply Maven with the information regarding
the current location of the project's SCM. This information can be defined and maintained
within the project's pom.xml. Additionally we are going to add the required configuration for
publishing the generated asset into Anypoint Exchange.
1. Modify the groupId of the Maven project to be your Organization ID in your project's
POM file. Also make sure the artifactId is unique and doesn't overlap with other asset already
published into Anypoint Exchange:

<groupId>ORGANIZATION_ID</groupId>

<artifactId>MY-APP-IMPL</artifactId>

2. Make sure that your version number has -SNAPSHOT added as postfix, otherwise
maven release prepare plugin will fail to add incremental tag

<groupId>ORGANIZATION_ID</groupId>
 CI/CD Pipeline using Azure DevOps

<artifactId>MY-APP-IMPL</artifactId>

<artifactId>1.0.0-SNAPSHOT</artifactId>

3.
Add the Maven facade as a repository in the distribution management section of the project's
POM file (the repository credentials needs to be configured in the settings.xml file uploaded
into the Azure DevOps Library):

<distributionManagement>
<repository>
<id>MuleExchangeRepository</id>
<name>MuleExchangeRepository</name>
<url>https://maven.anypoint.mulesoft.com/api/v1/organizations/ORGANIZATION_ID/maven</
url>
<layout>default</layout>
</repository>
</distributionManagement>

4. Update the POM properties with the SCM ID (the SCM credentials need to also be configured in the
settings.xml file that was uploaded into the Azure DevOps Library) and the Maven Release Plugin Version
(e.g.: 2.5.3):

<properties>
<!-- other properties here -->
<maven.release.plugin.version>2.5.3</maven.release.plugin.version>
 CI/CD Pipeline using Azure DevOps

<project.scm.id>AZURE_GIT_REPO_ID</project.scm.id>
</properties>

5. Add the reference to the project SCM repository (e.g.: Azure GIT repo): Note : Example below shows
complete azure git repo url connection using azure devops username/password for repos.

<scm>
<connection>scm:git:https://${azure.git.user}:${azure.git.password}@dev.azure.com/ORG
-NAME/PROJECT-NAME/_git/REPO-NAME</connection>
<developerConnection>scm:git:https://${azure.git.user}:${azure.git.password}@dev.azur
e.com/ORG-NAME/PROJECT-NAME/_git/REPO-NAME</developerConnection>
<tag>HEAD</tag>
</scm>

6. Add the Maven Release Plugin configuration to the project's POM file:

<build>
<plugins>
<!-- other plugins -->
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-release-plugin</artifactId>
<version>${maven.release.plugin.version}</version>
</plugin>
</plugins>
</build>

Running the main branch build pipeline

 CI/CD Pipeline using Azure DevOps

1. To run the build pipeline, go to the related menu option and search for it under the All
tab.

2. Click the Run pipeline button.

3. Once the build execution finishes successfully, go to Repos → Commit and select the
main branch. Check that:
a. A tag has been created for the released version.
b. The version in the pom.xml file has been increased for the next release.

4. Log into Anypoint Platform and go to Anypoint Exchange. Check that the build artifact
has been successfully uploaded into Exchange. In order to do that, you need to update
 CI/CD Pipeline using Azure DevOps

the following URL with the ORGANIZATION_ID and ARTIFACT_ID values in the
pom.xml file.

https://anypoint.mulesoft.com/exchange/ORGANIZATION_ID/ARTIFACT_ID/
 CI/CD Pipeline using Azure DevOps

Release pipeline configuration

Next step is configuring the release pipeline in order to promote the generated artifact to the
other environments. In this case, we are going to pick the artifact from the Azure staging
directory and deploy it to TEST and PROD using the Mule Maven Plugin.

Steps

1. Log into Azure DevOps, go to the Releases menu and click New → New release
pipeline.

2. Select the Empty job option.

3. Give a name to the pipeline.
4. Rename the default stage with the first environment where you are going to promote
your artifact. E.g.: TEST.

5. Click the Artifacts → Add button.

a. Set the Source type to Build.
b. Select the build pipeline from main created in the previous section as source.
 CI/CD Pipeline using Azure DevOps

c. Set Default Version to Latest.

d. Click add button to finish.

6. Nest step is configuring a trigger for the pipeline. Click on the Continuos deployment
trigger button and enable the trigger in order to create a new release every time a new
build is available.

7. Finally, we need to add the required Maven tasks in order to deploy the Mule
Application into TEST environment.
 CI/CD Pipeline using Azure DevOps

a. Edit the pre-deployment condition and set the trigger to Manual only.

b. Click on the 1 job, 0 task link into the stage activity of your pre-prod environment
(e.g.: TEST).

c. Click on the Add task button and add a Download secure file task.
d. Set the Display name to Download pom.xml file.
 CI/CD Pipeline using Azure DevOps

e. Select the settings.xml file from the dropdown list. This is the secured file that
was previously uploaded to Azure Library.

f. Add a bash script task to the pipeline. This is needed to pick the artifact that was
generated in the build pipeline triggered from main branch which is stored into
the Azure staging directory.
g. Set the Display name to Find artifact.
h. Set the script type to inline.
i. Copy and paste the following lines.

cd $(Release.PrimaryArtifactSourceAlias)/drop/target
ls -la
artifact=$(ls | grep *.jar)
echo "##vso[task.setvariable variable=ARTIFACT;]$artifact"
 CI/CD Pipeline using Azure DevOps

j. Add a Maven task and rename to Deploy.

k. Set the path to the POM file as follows:

$(System.DefaultWorkingDirectory)/$(Release.PrimaryArtifactSourceAlias)
/drop/pom.xml

l. Set the goal to:

 CI/CD Pipeline using Azure DevOps

Mule:deploy

m. In the options box, copy and paste the following lines:

DskipTests -DmuleDeploy
-Danypoint.platform.client.id=<<EnvironmentClientId>>
-Danypoint.platform.client.secret=<<EnvironmentClientSecret>>
-Dbusiness.group.id=$(BusinessGroupId)
-Danypoint.platform.client.id=$(ClientId)
-Dcloudhub.application.name=$(Environment)-contacts-sapi-v1
-Denvironment=$(Environment)
-Danypoint.platform.client.secret=$(ClientSecret)
-Dworkers=$(workers) -DworkerType=$(workerType
-Dartifact="$(Agent.ReleaseDirectory)/$(Release.PrimaryArtifactSource
Alias)/drop/target/$(ARTIFACT)"
 CI/CD Pipeline using Azure DevOps

n. Uncheck the Publish to Azure Pipelines box and click the Save button.

o. Select Variables → Variable groups → Link variable group and link Azure DevOps
Mule Deployer and Anypoint Platform TEST Variables to the current stage. E.g.:
TEST
Click the Save button and go back to the Pipeline tab.
 CI/CD Pipeline using Azure DevOps

8. The stage for your production environment can be cloned from the previous one. For
the purpose of the example I've set a Manual only trigger.
 CI/CD Pipeline using Azure DevOps

9. Click on the View stage tasks link to edit the Variable groups (in this case for the PROD
environment).

10. Update the variable groups as follows:

a. Azure DevOps Mule Deployer should be link to all the environments. E.g.: TEST,
PROD
b. Anypoint Platform <ENVIRONMENT> Variables to the specific one.
 CI/CD Pipeline using Azure DevOps

11. Click the Save button to finish.

12. Finally, Click “Save as a template”. After you save this template, you can use it later when
you will create a new build pipeline.
 CI/CD Pipeline using Azure DevOps

Executing the Release Pipeline

With current configuration, each time a build pipeline is executed from the main branch, the
recently configured release will be triggered and will be ready for deploying our application to
TEST and PROD.

1. Go to Azure DevOps → Pipeline → Releases.

 CI/CD Pipeline using Azure DevOps

2. Check a new release entry has been created ready for promoting the artifact to TEST
and PROD environment.

3. Select the specific release. E.g.: Release-5

4. Click the Deploy option, select the stage and finally press the Deploy button.

5. Verify the artifact has successfully deployed into the specific environment.
 CI/CD Pipeline using Azure DevOps

6. Finally, you can move forward with the deployment into PROD.
 CI/CD Pipeline using Azure DevOps

Best Practices

This section talks about some of the best practices while setting up CICD pipeline using Azure
Devops

■ YAML Editor over Classic UI

■ Azure Key Vault
■ Managing variable groups
■ Setting up Azure Service connections

YAML Editor over Classic UI

While YAML Editor was out of scope from this article, some customers really want to use this
feature as their other non mule projects might be leveraging them.

YAML is the newer way where you can define the pipeline as code, in YAML format, which you
then commit to a repo. Azure DevOps does have an assistant to help you create/modify the
YAML pipelines, so you don’t have to remember every possible setting or keep having to look
up references. Please refer to this official azure article to use YAML Editor over Classical UI.

Let's quickly summarize pros and cons of both approaches :

Classic UI

Pros Cons

No DSL (domain specific language) to learn, which It’s being deprecated. This will
enables super fast on-boarding, especially for become lower and lower in
those that come from a SysAdmin background Microsoft’s priority list when it
rather than a Developer background comes to new features.

Very easy to make quick changes, which if you have dozens (if not
encourages experimentation hundreds) of APIs ( and each API
has its own repo), manual clicks
takes forever to create.
 CI/CD Pipeline using Azure DevOps

A slight change in configuration

means changes - hundreds of UI
clicks. definitely not manageable.

Contrary to popular belief, it does have versioning,

and you can revert to a previous one easily

YAML Editor

Pros Cons

It is code, and managed as a source Not as mature as the Classic UI — some

file, so it will go through a standard features are still on the roadmap but it's
code review / pull request process catching up very rapidly. However, use cases a
standard mule deployment needs, all the
features are available in YAML already.

Because it is in the repo, when you

need to revert the source to an early
commit, the pipeline will be reverted
together as well

Like all text files, it is easy to

manipulate and change multiple
values in one go. If needed it can even
be generated from a script

Comparing changes is much easier

compared to the Classic UI versioning,
which means it’s easier to identify root
cause if build breaks
 CI/CD Pipeline using Azure DevOps

Encourages collaboration — it’s much

easier to code snippets through Slack
or whatever than cropped screenshots

Supports Container Jobs, which is

quite important to some teams

Azure DevOps does have assistant to

help building a YAML file, so it’s not as
daunting as it first looks for
inexperienced users

With work item templates, you can

quickly create work items that have
pre-populated values for your team's
commonly used fields. For example,
create a template that defines the area
path, iteration path, and activity to use
when creating a task.

Please refer to this knowledge hub

article for more information about
pipeline templates and how it’s used
with mule applications.

Example

For all the scenarios, we have discussed in this article for ci-cd pipeline using Classic UI, they are
migrated using YAML editor.Please refer to this github link for more details.

azure-dev-build-pipeline.yml : this azure yaml pipeline file refers to develop branch build
pipeline

azure-release-build-pipeline.yml : this azure yaml pipeline file refers to release branch build
pipeline

Note

Please continue to refer to the github link for latest updates - README for tracking new
features in future.
 CI/CD Pipeline using Azure DevOps

Azure Key Vault

While Azure Key Vault was out of scope from this article, some customers really want to use this
feature as their other non mule projects might be leveraging them. Please refer to this official
azure article to implement Azure Key Vault in your pipeline.

Managing Variable groups

Instead of storing secrets in one generic one group along with other non secret variables, it's
best to keep all secure properties in one group and non secrets in another one per
environment.

Now that a dedicated Secure variable Group is created, it can be access controlled fine grained
to smaller admin groups for non dev environment.
 CI/CD Pipeline using Azure DevOps

Task Groups

A task group allows you to encapsulate a sequence of tasks, already defined in a build or a
release pipeline, into a single reusable task that can be added to a build or release pipeline, just
like any other task. You can choose to extract the parameters from the encapsulated tasks as
configuration variables, and abstract the rest of the task information.

The new task group is automatically added to the task catalog, ready to be added to other
release and build pipelines. Task groups are stored at the project level, and are not accessible
outside the project scope. Refer official documentation for more information.

Setting up Azure Service Connections

In this article we already covered how to use azure service connection to replace settings.xml
with secure service connections. You can create a connection from Azure Pipelines to external
and remote services for executing tasks in a job. Once you establish a connection, you can
view, edit, and add security to the service connection. You can find more details on azure
service connections here.
 CI/CD Pipeline using Azure DevOps

References

● Git Repo
● Azure YAML Pipeline - Azure Devops
● Service Connection – Azure Devops
● Mule Maven Plugin
● Maven Release Plugin