Author: Twinkle Jagani

  1. Creation of Demo Mule Application

Create a basic Mule application with HTTP listener component and the response is a simple text message. Set the path to “/test” and response payload to “Azure DevOps POC test application”.

  1. Create Azure Repository and Sync Application Code
  • Create Azure DevOps account and then create a new empty repository for the project.
  • Azure Repos is a repository for the source code which is managed by version control. We can have multiple repositories under a single project and multiple branches under each repository  as per the requirement.
  • With Git bash commands Clone the repository on your local then add the Mule application created above and push the code.
  • Here is a sample project “tjagani” under which there is a repository named “azure-devops-poc”. It consists of a Mule project “azure-devops-poc
  1. Azure Build Pipeline [YAML method]
  • Edit pom.xml of the mule project and add the following snippet to repositories and distributionManagement tags. Screenshot is attached on the next page.
<repository>
           <id>tjagani</id>
           <url>https://pkgs.dev.azure.com/tjagani/_packaging/tjagani/maven/v1</url>
           <releases>
              <enabled>true</enabled>
           </releases>
           <snapshots>
              <enabled>true</enabled>
           </snapshots>
</repository>
<plugin>
     <groupId>org.mule.tools.maven</groupId>
     <artifactId>mule-maven-plugin</artifactId>
     <version>3.1.6</version>
     <extensions>true</extensions>
     <configuration>
        <cloudHubDeployment>
             <uri>https://anypoint.mulesoft.com/</uri>
             <muleVersion>4.3.0</muleVersion>
             <username>Anypoimt Platform Username</username>
             <password>Anypoimt Platform Password</password>
             <businessGroup>${businessGroup}</businessGroup>
             <workers>${workers}</workers>
             <workerType>${workerType}</workerType>
             <region>us-west-1</region>
             <environment>${environment}</environment>
             <applicationName>${applicationName}</applicationName>
             <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>        <anypoint.platform.config.analytics.agent.enabled>true</anypoint.platform.config.analytics.agent.enabled>
            </properties>
        </cloudHubDeployment>
     </configuration>
</plugin>
  • Go to the Pipelines menu and create a new pipeline with following configurations:
    • Click Create New Pipeline
    • Select Azure Repos Git option
    • Select the repository created
    • Select Maven and then click Save and Run.
  1. Variable Groups

To reuse the variables across all the pipelines, we can create variable groups and reference those variables inside the pipeline.

To make use of the variable group in the pipeline, include the following

variables:
- group: PipelineCachingVariables

Once this is included, we can access the variables with $(variableName)

  1. Create Azure Artifacts

We can create azure artifacts in the Maven task by using the option goals: ‘deploy’. This will create artifacts as shown below:

  1. Triggers

We can use triggers to run a pipeline automatically in order to perform continuous integration (CI). We can have the below configuration in the YAML file to trigger the pipeline whenever the source code located under a certain location and under a certain branch changes.

trigger:
  branches:
    include:
    - dev
  paths:
    include:
    - 'demo-domain/*'
  1. Tag Sources

We can tag the sources once the build pipeline is completed by following the below steps:

  1. Goto the specific build pipeline and then click on Edit option
  2. Then, click on the three dots button and select the Triggers option
  1. Then, click on YAML tab and select Get sources below it
  1. Then we can tag the sources on certain conditions (Never, On success and always) and we can configure the tag format as per standards
  1. Once the build is completed, we can see the tags created under Repos
  1. Pipeline Caching

To reduce the time for the build pipeline to execute, we can implement pipeline caching. 

Note: Pipeline Caching can be implemented only on Build Pipelines and not on release pipelines

Following are the steps to implement caching:

  1. Create the below pipeline variables before building the pipeline

Below is the cache task configuration:

- task: Cache@2
  inputs:
    key: 'maven | "$(Agent.OS)" | demo-domain/pom.xml'
    path: '$(MAVEN_CACHE_FOLDER)'
    cacheHitVar: 'CacheRestored'
    restoreKeys: |
      maven | "$(Agent.OS)"
      maven
  displayName: Cache Maven local repo

Configure the pom location in the cache task as per the location of pom

We need to include the below option in Maven task to make use of the pipeline caching strategy

mavenOptions: '-Xmx3072m $(MAVEN_OPTS)
  1. Reference YAML Code
variables:
- name: MAVEN_CACHE_FOLDER
  value: $(Pipeline.Workspace)/.m2/repository
- name: MAVEN_OPTS
  value: -Dmaven.repo.local=$(MAVEN_CACHE_FOLDER)
trigger:
  branches:
    include:
    - master
  paths:
    include:
    - azure-devops-poc/*
stages:
- stage: __default
  jobs:
  - job: Job
    pool:
      vmImage: ubuntu-latest
    steps:
    - task: MavenAuthenticate@0
      inputs:
        artifactsFeeds: xxxx
    - task: Cache@2
      inputs:
        key: maven | "$(Agent.OS)" | azure-devops-poc/pom.xml
        path: $(MAVEN_CACHE_FOLDER)
        cacheHitVar: CacheRestored
        restoreKeys: >
          maven | "$(Agent.OS)"

          maven
      displayName: Cache Maven local repo
    - task: Maven@3
      inputs:
        mavenPomFile: azure-devops-poc/pom.xml
        goals: deploy
        publishJUnitResults: true
        testResultsFiles: '**/surefire-reports/TEST-*.xml'
        javaHomeOption: JDKVersion
        mavenVersionOption: Default
        mavenOptions: -Xmx3072m $(MAVEN_OPTS)
        mavenAuthenticateFeed: false
        effectivePomSkip: false
        sonarQubeRunAnalysis: false
    - task: CopyFiles@2
      inputs:
        Contents: '**/target/*.jar'
        TargetFolder: $(Build.ArtifactStagingDirectory)
        CleanTargetFolder: true
        flattenFolders: true
    - task: PublishBuildArtifacts@1
      inputs:
        PathtoPublish: $(Build.ArtifactStagingDirectory)
        ArtifactName: DemoApplication
        publishLocation: Container

Run the Pipeline Job once the above steps are completed. The Artifacts should be built and published to Azure Artifacts.

  1. Release Pipeline

Once the build pipeline is completed, we can trigger the release pipeline as per requirements. Here is a sample release pipeline which gets triggered whenever the build pipeline is completed. We can have multiple Stages in the release pipeline.

Necessary artifacts must be added in the Artifacts section of the release pipeline in order to trigger it. Below is the artifact configured.

We can also configure the pre-deployment conditions of stages as per requirement Here, we have triggered using “After release” option.

As this document is about deploying the application to the cloudHub, we have configured the task as per our requirements. We require two tasks to be configured, 1. Downloading credentials file and  2. Bash script tasks which deploy the jar to cloudHub required environment with anypoint CLI command.

Refer below snippet for credentials file creation. Please provide no extension to the file

{
 "Sandbox": {
  "username": "anypoint_username",
  "password": "anypoint_password",
  "organization": "xxxx",
  "environment": "Sandbox",
  "host": ""
 },
 "QA": {
 "username": "anypoint_username",
  "password": "anypoint_password",
  "organization": "xxxx",
  "environment": "QA",
  "host": ""
 }
}

Upload the credentials file to the library section.

Configure the Download Secure File task of a Stage as below.

Next Configure the second task for deploy to cloudhub as below, also refer the below commands for deploying to cloudhub with anypoint CLI [Only for new application.]

Note: This command will throw an error if the application with the same name is already deployed. For redeploying the application use Modify instead of deploy in the below command

npm install -g anypoint-cli@latest
mkdir ~/.anypoint
cp $AGENT_TEMPDIRECTORY/credentials ~/.anypoint/

export ANYPOINT_PROFILE="$(environment)"

anypoint-cli runtime-mgr cloudhub-application deploy --runtime "$(runtime)" --workers "$(workers)" --workerSize "$(worker_size)" --property "anypoint.platform.platform_base_uri:https://anypoint.mulesoft.com/"   --property "anypoint.platform.client_id:8aacf1bc75bb4b7f846f0f449b49ec88" --property "anypoint.platform.client_secret:61E03EE97ddB43469E078De2D56aca69" $(application_name) $(jar_file_path) 

Below is the command for redeploying the application:

npm install -g anypoint-cli@latest
mkdir ~/.anypoint
cp $AGENT_TEMPDIRECTORY/credentials ~/.anypoint/

export ANYPOINT_PROFILE="$(environment)"

anypoint-cli runtime-mgr cloudhub-application modify --runtime "$(runtime)" --workers "$(workers)" --workerSize "$(worker_size)" --property "anypoint.platform.platform_base_uri:https://anypoint.mulesoft.com/"   --property "anypoint.platform.client_id:8aacf1bc75bb4b7f846f0f449b49ec88" --property "anypoint.platform.client_secret:61E03EE97ddB43469E078De2D56aca69" $(application_name) $(jar_file_path) 

Finally execute the release pipeline which is created. It should deploy the application to the Sandbox and QA environment. 

Leave a Comment