Washington DC MuleSoft Meetup: CI/CD Pipeline with MuleSoft and Azure DevOps

All contents © MuleSoft, LLC
DC MULESOFT MEETUP
Setting up a CI/CD Pipeline with
MuleSoft and Azure DevOps
Speaker:
CATHERINE WILLS
MuleSoft Consultant | Big Compass, An Argano
Company

DC MULESOFT MEETUP
Meetup Admin Introductions
STEPHANIE LAWRENCE
BEN STONE

Google Slides does not
have an image placeholder
option. Please place an
image over this box
manually
+ First person to call out the correct answer, wins!
+ One answer per person per question
+ If you answer more than 1x per question, you are
ineligible for that question
+ If you’ve already won during today’s Meetup, you
cannot win again
+ Meetup organizers make the final decision on the trivia
winners
DC MULESOFT MEETUP
Trivia Question Rules & Regulations

DC MULESOFT MEETUP SPEAKER
Catherine Wills
+ Lives in New York, originally from
Georgia
+ ~ 2 years of MuleSoft experience
in development and architecture
+ Hobbies - Watching the Dawgs
and the Braves, history museums,
skiing, and golf

CI/CD + DevOps

All contents © MuleSoft, LLC 6
CI/CD is a method designed to frequently deliver applications by automating stages
within the application development lifecycle.
Continuous Integration: Incremental code changes are constantly integrated into a
main branch which is verified by an automated build and automated unit testing.
Continuous Delivery/Deployment: Automates the release of the validated code to
Production.
What is CI/CD?

DevOps integrates the work of software development (Dev) and operations (Ops) by
facilitating team collaboration, shared responsibility, and technology automation which
aid in a holistic style of Agile software development.
What is DevOps?

Advantages
8
CI/CD
● Increased speed gives rapid deliveries
● Greater efficiencies, streamlined process
● Ensured reliability
● Shorter development cycles
● Decreased deployment failures and bugs
● Enhanced quality and security
● Improved communication and collaboration
● Faster innovation
DevOp
s

Common Branching Strategies for DevOps
GitHub Flow
● Utilizes main and feature branches
● Simple workflow for smaller teams
● Easily integrate into CI/CD pipelines
Git Flow
● Uses main, develop, release, hotfix, and
feature branches
● Easier parallel collaboration for larger teams
● Supports multiple versions of production code
Trunk-Based
Development
● Integrates into main branch once a day
● Always in releasable state
● Excellent for CI/CD pipelines

image over this box
manually
A. Constantly Incrementing, Constantly Deploying
B. Continuous Integration, Continuous Delivery
C. Consistently Integrating, Consistently Building
D. Continuous Increments, Constant Deployment
TRIVIA QUESTION #1
What does CI/CD stand for?

CloudHub 1.0, CloudHub 2.0, and Runtime Fabric
Deployment Targets

Highlights
CloudHub 1.0 CloudHub 2.0 Runtime Fabric
● Primary execution container
is AWS EC3 instance
● Pre-determined worker
sizes only
● Global deployment options
● Usage measured in vCores
● Container-based application
deployment
● Can deploy to shared or
private spaces
● Ingress self-service logs
● More granular vCore
allocation options
● Primary execution is
Kubernetes pod
● Granular control over
application resource
allocation
● Subject to customer data
center footprint
● Usage measured in vCores

Azure DevOps

Boards helps teams plan, track, and discuss work
Repos is a set of version control tools used to manage code
Pipelines supports CI/CD to test, build, and deploy code
Pipelines: Used to automatically build and test code projects
Releases: Holds a versioned set of artifacts specified in the CI/CD pipeline
Library: A collection of build and release assets
■ Variable Groups can be used to store values and secrets, such as runtime
properties
■ Secure Files can be used to store secure files such as the settings.xml
Azure DevOps Components

Branch Policies
● Can set policies for a specific branch
namespace (i.e. develop, main) that applies
for all repositories
● Protects a branch from having changes
directly pushed to it
● Requires a pull request for code review
16

Build Pipelines
● Define pipelines using YAML syntax (Fig. A) or Classic Build interface (Fig. B)
● Customizable triggers, conditions, tasks, etc.
● Test coverage and results
● Viewable logs (Fig. C)
17
Fig. A
Fig. C
Fig. B

Build Trigger Variabilities
Built-in functions and predefined variables can be used in expressions to
specify various condition combinations for the Pipelines’ Stages, Jobs, or Steps
18
Trigger Type CI (Continuous Integration) PR (Pull Request) Scheduled
YAML
Version
Uses pushed (target) branch Uses source branch Uses included branch
Triggers
● Branch is specified in trigger
and is pushed to, such as git-
push or completion PR
● Manually run pipeline
● Must have build validation
branch policy
● PR created and active, not
upon PR completion
● Uses cron syntax
Runs source branch when a PR into the main branch is created, if Build Validation branch policy is set on main branch, and is succeeding
Runs main branch on a CI trigger if commit message starts with ‘Merged PR’
*Default merge commit message starts with ‘Merged PR’

Release Pipelines
● Classic-style interface (Fig. A)
● Can rollback by re-deploying a previous release
● Various deployment trigger routes
● Pre and post deployment condition options
● Viewable logs (Fig. B)
19
Fig. A
Fig. B

Release Creation Trigger Options
20
● Continuous Deployment
○ Creates release after successful ‘Individual CI’
build
○ Can include/exclude branches
● Pull Request
○ Creates release upon PR creation after
successful build
○ Must set build validation branch policy
○ Must set target branch and specify in Stage(s)
● Scheduled
Set Release Triggers
● Pre-Deployment Condition Triggers:
○ After Release
○ After Stage
○ Manual Only
● Deployment approvals
● Gates
○ Automatically collects health signals
■ i.e. Invoke REST API
Set Pre/Post Deployment
Conditions per Stage

image over this box
manually
A. Deployment Approval
B. Continuous Integration Trigger
C. Gates
D. Branch Policy
TRIVIA QUESTION #2
What can be used to protect a branch from being
directly pushed to?

CI/CD Pipeline Demo

Tools
● Anypoint Studio v7.14.0
● Mule Runtime v4.4.0
● MUnit Tools v2.3.13
● Mule Maven Plugin v3.8.0
● Apache Maven v3.8.8 (Mule Maven Plugin is not compatible with latest Apache Maven version, v3.9.x)
● Anypoint Exchange v3
● Anypoint Platform: Runtime Manager
● Azure DevOps Free Tier
Utilities
Environments Used for Demo
● Development
● QA
● Production
Files
● azure-pipelines.yml
● nonprod-settings.xml
● prod-settings.xml
● pom.xml
● mule-artifact.json (CH 1.0 Only)

The
Pipeline
Pathway
24

7) Configure mule-
artifact.json (CH
1.0 only)
6) Configure
pom.xml
5) Add New
Release Pipeline
4) Add properties
to Library
3) Configure &
Install
settings.xml
2) Pull in azure-
pipelines.yml and
configure
1) Create a Build
Pipeline
25
Azure CICD Pipeline Set-Up

Configure azure-pipelines.yml
27
CI trigger that allows main branch to run when updated via PR
1
Uses latest ubuntu, a Microsoft-hosted agent
2
Access to properties from default and dev variable groups from Library to use within Stage
3
Runs job if predefined variable, Build.Reason, is either ‘Individual CI’ or ‘Manual’, and has succeeded thus
far
4
Downloads settings.xml for lower environments from Secure Files in Library
5
Publishes Artifact to Exchange (CH 2.0 & RTF Only)
6
Runs MUnit tests, builds, and deploys to DEV environment
7
Gets <artifactId> from pom.xml and sets it as Pipeline variable, $(artifactId)
8
Publishes pipeline build artifact, pom.xml, to Container named ‘drop’
10
Publishes pipeline build artifact, JAR file, to Container named ‘drop’
9

Configure and Install settings.xml
1. Install in Secure files of Library
2. Grant pipelines permission
*One settings.xml file is for the lower
environments, and one is for the Production
environment.
28

1
Add properties in Mule
Maven Plugin Configuration
Configure pom.xml
35
Add MUnit executions
and configurations
2
3 Add Distribution Management (CH2.0, RTF)

Property Differences in pom.xml
36
CloudHub 1.0 CloudHub 2.0
Runtime Fabric

Configure mule-artifact.json (CH 1.0 Only)
37
Add names of secure properties to
the mule-artifact.json file to hide
them in Runtime Manager
Example of hidden properties in
Runtime Manager Settings →

Deployment Target Setup Differences
CloudHub 1.0 CloudHub 2.0 Runtime Fabric
● Hide properties in mule-
artifact.json
● Protect properties in
pom.xml
● Must publish to Exchange
prior to deployment
● Must have Distribution
Management in pom.xml
● Protect properties in
pom.xml
● Must publish to Exchange
prior to deployment
● Must have Distribution
Management in pom.xml
● Uses Runtime Fabric agent

image over this box
manually
A. settings.xml
B. azure-pipelines.yml
C. pom.xml
D. mule-artifact.json
TRIVIA QUESTION #3
Which file can be used to protect secure property
values in Runtime Manager for CH 2.0 & RTF?

Questions?
CONNECT ON LINKEDIN
CATHERINE WILLS
Consultant | Big Compass

image over this box
manually
Share on Social Meetup Feedback
+ Use the hashtags #MuleSoftMeetups &
#DCMuleSoftMeetup
+ Don’t forget to tag @BigCompass
+ Please fill out this 1 minute survey to
provide feedback and topic suggestions

Washington DC MuleSoft Meetup: CI/CD Pipeline with MuleSoft and Azure DevOps

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to Washington DC MuleSoft Meetup: CI/CD Pipeline with MuleSoft and Azure DevOps

Similar to Washington DC MuleSoft Meetup: CI/CD Pipeline with MuleSoft and Azure DevOps (20)

More from Big Compass

More from Big Compass (7)

Recently uploaded

Recently uploaded (20)

Washington DC MuleSoft Meetup: CI/CD Pipeline with MuleSoft and Azure DevOps