Before we go into the details, I would like to quickly clear up the abbreviation CI/CD to make sure we all have the same understanding. Additionally, I also recommend you to check out our interesting demonstration of Using GitHub Actions with MuleSoft.
What is the CI in CI/CD?
“Continuous Integration is a software development practice where members of a team integrate their work frequently,” – Martin Fowler
What is the CD in CI/CD?
“Continuous deployment is a strategy in software development where code changes to an application are released automatically into the production environment.” – IBM
What do we get when we Combine CI & CD?
In practice, we can say: CI/CD is a way to keep our integrated development environment stable and evolving.
CI/CD in the MuleSoft world
Part 1: Maven
Automation for Builds, Tests, Deployments
Mule applications are Maven-based Java applications. Therefore, MuleSoft uses the Mule-Maven plugin to automate the build and deployment process. The Mule-Maven plugin can be used to deploy to a variety of cloud-based and on-premises environments.
The first step is to ensure that the Mule-Maven-plugin is included in the pom.xml
To run Maven properly, the MuleSoft Nexus Enterprise Repository needs to be added to the Maven Settings (settings.xml).
Part 2: MUnit
Advanced Tests for Mule flows and guarantee Expected Level of Testing
MUnit is a Mule testing framework based on JUnit for the Java programming language. It lets you easily automate testing Mule applications and is important in a test-driven development approach. While intended for unit testing, it can be extended to cover some integration testing use cases with additional configuration and setup to ensure that the data integrity and state of the involved systems are not compromised.
Additionally, MUnit calculates the flows and components that are covered by the tests created. This Coverage can be used as one of several measures of development process quality and hence a factor in the decision to accept or reject an application or updates to it.
MUnit – Assert, Mock, and Spy
MUnit – Coverage and Ignore Lists
Part 3: Pipelines – GitHub Actions
Git-based, Automated, workflows
The last component of getting a functioning CI/CD is the actual Pipeline which automates testing, building, releasing, and deploying applications. While several options are available in the market and all can be used with MuleSoft, for our purposes we will use GitHub Actions which achieves this via event-driven triggers. These triggers can range from a simple commit to creating a pull request to building a new brand in a repository.
YAML files placed under the .github/workflows directory of a repository define the events, jobs, steps, and actions. These can contain simple IFTTT-style (if this, then that) logic flows, or more complex use cases.
For more information and an interesting demonstration of Using GitHub Actions with MuleSoft, you can visit our latest event page. If you need additional help, please click the button below to get in touch.