{"id":161456,"date":"2023-11-26T14:20:00","date_gmt":"2023-11-26T13:20:00","guid":{"rendered":"https:\/\/www.devoteam.com\/ebook\/mulesoft-continuous-integration-and-delivery\/"},"modified":"2023-11-26T14:20:00","modified_gmt":"2023-11-26T13:20:00","slug":"mulesoft-continuous-integration-and-delivery","status":"publish","type":"book","link":"https:\/\/devoteam.info\/uk\/ebook\/mulesoft-continuous-integration-and-delivery\/","title":{"rendered":"MuleSoft \u2013 Continuous Integration and Delivery"},"content":{"rendered":"\n<div class=\"wp-block-group alignfull has-gray-light-background-color has-background has-global-padding is-layout-constrained wp-container-core-group-is-layout-921a10a8 wp-block-group-is-layout-constrained\" style=\"margin-top:0px;margin-bottom:0px;padding-top:0;padding-right:0;padding-bottom:0;padding-left:0\">\n<div class=\"wp-block-columns alignfull is-layout-flex wp-container-core-columns-is-layout-a5e3bee9 wp-block-columns-is-layout-flex\" style=\"margin-top:0px;margin-bottom:0px\">\n<div class=\"wp-block-column is-vertically-aligned-center is-layout-flow wp-block-column-is-layout-flow\" style=\"padding-top:var(--wp--preset--spacing--x-large);padding-right:var(--wp--preset--spacing--x-large);padding-bottom:var(--wp--preset--spacing--x-large);padding-left:var(--wp--preset--spacing--x-large);flex-basis:50%\"><div class=\"breadcrumbs align wp-block-bcn-breadcrumb-trail has-text-color has-background\" vocab=\"https:\/\/schema.org\/\" typeof=\"BreadcrumbList\">\n\t<span><\/span>\n\t<span property=\"itemListElement\" typeof=\"ListItem\"><a property=\"item\" typeof=\"WebPage\" title=\"Go to Devoteam.\" href=\"https:\/\/devoteam.info\/uk\/\" class=\"home\" ><span property=\"name\">Devoteam<\/span><\/a><meta property=\"position\" content=\"1\"><\/span><span class=\"separator\"><\/span><span property=\"itemListElement\" typeof=\"ListItem\"><a property=\"item\" typeof=\"WebPage\" title=\"Go to Insights.\" href=\"https:\/\/devoteam.info\/uk\/insights\/\" class=\"post-root post post-post\" aria-current=\"page\"><span property=\"name\">Insights<\/span><\/a><meta property=\"position\" content=\"2\"><\/span><\/div>\n\n\n\n<figure class=\"wp-block-image size-large is-resized\"><img loading=\"lazy\" decoding=\"async\" width=\"1123\" height=\"333\" src=\"https:\/\/devoteam.info\/wp-content\/uploads\/2024\/10\/MuleSoft_logo.svg\" alt=\"\" class=\"wp-image-11346\" style=\"width:250px\"\/><\/figure>\n\n\n\n<h1 class=\"wp-block-heading\" id=\"h-mulesoft-continuous-integration-and-delivery\">MuleSoft \u2013 Continuous Integration and Delivery<\/h1>\n\n\n\n<p class=\"has-base-font-size wp-block-paragraph\">Making technical changes to app or website code at any stage of development can be a tricky business! That\u2019s why effective Continuous Integration and Continuous Delivery (CI\/CD) is essential for successfully building and maintaining any application, website, or piece of software.<\/p>\n\n\n\n<p class=\"has-link-color wp-elements-1 wp-block-paragraph\">But what exactly is efficient CI and CD? And what are the best GitHub Branching Strategies for supporting them?&nbsp;<a href=\"https:\/\/www.linkedin.com\/in\/ACoAABd7FJcBrcB17Gd1ADDRl_jlz6Mq5ZPlFRg\">Pavan Kumar<\/a>&nbsp;will be answering those very questions (plus more) in our new&nbsp;<a href=\"https:\/\/www.linkedin.com\/company\/mulesoft\/\">MuleSoft<\/a>&nbsp;CI\/CD blog series.<\/p>\n\n\n\n<p class=\"has-link-color has-base-font-size wp-elements-2 wp-block-paragraph\">* After reading our eBook you will know:<br>\u2013 The basics of Continuous Integration and Delivery, and why they are important.<br>\u2013 The foundations of different branching strategies and version control systems.<br>\u2013 The best GitHub branching strategies for different objectives and outcomes.<\/p>\n\n\n\n<div class=\"wp-block-buttons is-layout-flex wp-block-buttons-is-layout-flex\">\n<div class=\"wp-block-button\"><a class=\"wp-block-button__link wp-element-button\" href=\"#introduction\">Start reading<\/a><\/div>\n<\/div>\n<\/div>\n\n\n\n<div class=\"wp-block-column is-vertically-aligned-stretch is-layout-flow wp-block-column-is-layout-flow\" style=\"flex-basis:50%\"><figure class=\"wp-block-post-featured-image\"><img loading=\"lazy\" decoding=\"async\" width=\"1920\" height=\"1280\" src=\"https:\/\/devoteam.info\/wp-content\/uploads\/2024\/11\/MuleSoft-\u2013-Continuous-Integration-and-Delivery.jpg\" class=\"attachment-post-thumbnail size-post-thumbnail wp-post-image\" alt=\"\" style=\"aspect-ratio:4\/3;width:100%;height:100%;width:100%;object-fit:cover;\" srcset=\"https:\/\/devoteam.info\/wp-content\/uploads\/2024\/11\/MuleSoft-\u2013-Continuous-Integration-and-Delivery.jpg 1920w, https:\/\/devoteam.info\/wp-content\/uploads\/2024\/11\/MuleSoft-\u2013-Continuous-Integration-and-Delivery-300x200.jpg 300w, https:\/\/devoteam.info\/wp-content\/uploads\/2024\/11\/MuleSoft-\u2013-Continuous-Integration-and-Delivery-1024x683.jpg 1024w, https:\/\/devoteam.info\/wp-content\/uploads\/2024\/11\/MuleSoft-\u2013-Continuous-Integration-and-Delivery-768x512.jpg 768w, https:\/\/devoteam.info\/wp-content\/uploads\/2024\/11\/MuleSoft-\u2013-Continuous-Integration-and-Delivery-1536x1024.jpg 1536w\" sizes=\"auto, (max-width: 1920px) 100vw, 1920px\" \/><\/figure><\/div>\n<\/div>\n<\/div>\n\n\n\n<div class=\"wp-block-group alignwide has-global-padding is-layout-constrained wp-block-group-is-layout-constrained\" style=\"padding-top:var(--wp--preset--spacing--large);padding-bottom:var(--wp--preset--spacing--large)\">\n<div class=\"wp-block-columns alignwide is-layout-flex wp-container-core-columns-is-layout-8d39b2df wp-block-columns-is-layout-flex\">\n<div class=\"wp-block-column is-layout-flow wp-block-column-is-layout-flow\" style=\"flex-basis:20%\">\n<div class=\"wp-block-group is-vertical is-layout-flex wp-container-core-group-is-layout-3e4c80ef wp-block-group-is-layout-flex wp-container-1 is-position-sticky\">\n<p class=\"wp-block-paragraph\"><strong>Author<\/strong><\/p>\n\n\n\n<figure class=\"wp-block-image size-full is-resized is-style-rounded\"><img loading=\"lazy\" decoding=\"async\" width=\"234\" height=\"234\" src=\"https:\/\/devoteam.info\/wp-content\/uploads\/2024\/11\/Pavan_HeadShot-234x234-1.jpg\" alt=\"\" class=\"wp-image-161317\" style=\"object-fit:cover;width:80px;height:80px\" srcset=\"https:\/\/devoteam.info\/wp-content\/uploads\/2024\/11\/Pavan_HeadShot-234x234-1.jpg 234w, https:\/\/devoteam.info\/wp-content\/uploads\/2024\/11\/Pavan_HeadShot-234x234-1-150x150.jpg 150w\" sizes=\"auto, (max-width: 234px) 100vw, 234px\" \/><\/figure>\n\n\n\n<p class=\"has-small-font-size wp-block-paragraph\"><strong>Pavan Nagineni<br><\/strong>Senior MuleSoft Consultant<\/p>\n\n\n\n<hr class=\"wp-block-separator has-text-color has-gray-color has-alpha-channel-opacity has-gray-background-color has-background is-style-default\" style=\"margin-top:var(--wp--preset--spacing--medium);margin-bottom:var(--wp--preset--spacing--medium)\"\/>\n\n\n\n<div class=\"wp-block-group has-gray-light-background-color has-background has-global-padding is-layout-constrained wp-container-core-group-is-layout-5d9a58c0 wp-block-group-is-layout-constrained\" style=\"padding-top:var(--wp--preset--spacing--small);padding-right:var(--wp--preset--spacing--small);padding-bottom:var(--wp--preset--spacing--small);padding-left:var(--wp--preset--spacing--small)\">\n<p class=\"has-small-font-size wp-block-paragraph\">If you would like to discuss CI\/CD further and learn how to implement GitHub Actions, then&nbsp;get in touch&nbsp;with one of our experts.<\/p>\n<\/div>\n\n\n\n<div class=\"wp-block-buttons is-layout-flex wp-block-buttons-is-layout-flex\">\n<div class=\"wp-block-button\"><a class=\"wp-block-button__link wp-element-button\" href=\"https:\/\/devoteam.info\/uk\/get-in-touch\/\">Get in touch<\/a><\/div>\n<\/div>\n\n\n\n\t<div class=\"wp-block-acf-social-buttons align\">\n\n\t\n\t\t\t<ul>\n\t\t\t<li><a href=\"https:\/\/www.linkedin.com\/\" target=\"_blank\" rel=\"noopener noreferrer\" class=\"social-buttons__link social-buttons__link--linkedin\"><svg xmlns=\"http:\/\/www.w3.org\/2000\/svg\" viewBox=\"0 0 448 512\"><path d=\"M100.3 448H7.4V148.9h92.9zM53.8 108.1C24.1 108.1 0 83.5 0 53.8a53.8 53.8 0 0 1 107.6 0c0 29.7-24.1 54.3-53.8 54.3zM447.9 448h-92.7V302.4c0-34.7-.7-79.2-48.3-79.2-48.3 0-55.7 37.7-55.7 76.7V448h-92.8V148.9h89.1v40.8h1.3c12.4-23.5 42.7-48.3 87.9-48.3 94 0 111.3 61.9 111.3 142.3V448z\"\/><\/svg><\/a><\/li>\t\t\t<li><a href=\"https:\/\/x.com\/\" target=\"_blank\" rel=\"noopener noreferrer\" class=\"social-buttons__link social-buttons__link--x\"><svg xmlns=\"http:\/\/www.w3.org\/2000\/svg\" viewBox=\"0 0 512 512\"><path d=\"M389.2 48h70.6L305.6 224.2 487 464H345L233.7 318.6 106.5 464H35.8L200.7 275.5 26.8 48H172.4L272.9 180.9 389.2 48zM364.4 421.8h39.1L151.1 88h-42L364.4 421.8z\"\/><\/svg><\/a><\/li>\t\t\t<li><a href=\"mailto:franck@lepulsar.com\" target=\"_blank\" rel=\"noopener noreferrer\" class=\"social-buttons__link social-buttons__link--email\"><svg xmlns=\"http:\/\/www.w3.org\/2000\/svg\" viewBox=\"0 0 512 512\"><path d=\"M64 112c-8.8 0-16 7.2-16 16l0 22.1L220.5 291.7c20.7 17 50.4 17 71.1 0L464 150.1l0-22.1c0-8.8-7.2-16-16-16L64 112zM48 212.2L48 384c0 8.8 7.2 16 16 16l384 0c8.8 0 16-7.2 16-16l0-171.8L322 328.8c-38.4 31.5-93.7 31.5-132 0L48 212.2zM0 128C0 92.7 28.7 64 64 64l384 0c35.3 0 64 28.7 64 64l0 256c0 35.3-28.7 64-64 64L64 448c-35.3 0-64-28.7-64-64L0 128z\"\/><\/svg><\/a><\/li>\t\t<\/ul>\n\t\n\t\n\t<\/div>\n\n<\/div>\n<\/div>\n\n\n\n<div class=\"wp-block-column is-layout-flow wp-block-column-is-layout-flow\" style=\"flex-basis:80%\">\n<main class=\"wp-block-group has-global-padding is-layout-constrained wp-block-group-is-layout-constrained\">\n<div id=\"google-cloud\" class=\"wp-block-group has-global-padding is-layout-constrained wp-block-group-is-layout-constrained\">\n<h2 class=\"wp-block-heading introduction\" id=\"chapter1\">Git Branching Strategy<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">Continuous Integration and Continuous Delivery\/Deployment is commonly called CI\/CD \u2013 a standard software build and delivery practice.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Most MuleSoft CI\/CD blogs only talk about how to compile\/ build\/ test\/ deploy your MuleSoft applications to any of the runtimes, and that\u2019s all. It\u2019s hard to find a blog on the best way to tag\/ release applications and how to take these released versions and deploy them to User Accepted Testing (UAT)\/ Production environments as we would to follow organisation standards.&nbsp;<\/p>\n\n\n\n<p class=\"wp-block-paragraph\"><strong>So, I have developed this series of three chapters&nbsp;<\/strong>discussing the following concepts:<\/p>\n\n\n\n<p class=\"wp-block-paragraph\"><strong>What is CI\/CD &amp; Git Branching Strategy?&nbsp;<\/strong><\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>What is CI\/CD<\/li>\n\n\n\n<li>Branching strategies and best practices.<\/li>\n<\/ul>\n\n\n\n<p class=\"wp-block-paragraph\"><strong>Continuous Integration<\/strong><\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>The CI tasks of CI\/CD, compile\/ test\/ build\/ development environment deployment.&nbsp;<\/li>\n\n\n\n<li>An example of CI in action with the help of an API in GitHub Actions.&nbsp;<\/li>\n<\/ul>\n\n\n\n<p class=\"wp-block-paragraph\"><strong>Continuous Delivery\/Deployment<\/strong><\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Achieving CD, the SIT\/ environment deployments.&nbsp;<\/li>\n\n\n\n<li>How to release an application with the correct versioning and tagging by using maven on PR merges to a certain integration branch.&nbsp;<\/li>\n\n\n\n<li>See a plan to deploy the released tags to UAT\/Production deployments.&nbsp;<\/li>\n<\/ul>\n\n\n\n<p class=\"wp-block-paragraph\"><strong>This is part one of the series<\/strong>&nbsp;in which we are going to discuss the concepts below:&nbsp;<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What is CI\/CD?&nbsp;<\/strong><\/li>\n\n\n\n<li><strong>Git Branching Strategy and Best Practices&nbsp;<\/strong><\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\" id=\"h-what-is-ci-cd-nbsp\"><strong>What is CI\/CD?&nbsp;<\/strong><\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>The \u201cCI\u201d in CI\/CD refers to Continuous Integration, an automation process for developers to continuously build the application for any changes.&nbsp;<\/li>\n\n\n\n<li>Successful CI means new code changes to an app are regularly tested, built, and merged into a shared repository.<\/li>\n\n\n\n<li>The \u201cCD\u201d in CI\/CD refers to Continuous Delivery\/Deployment, related concepts that sometimes get used interchangeably.&nbsp;<\/li>\n\n\n\n<li>Continuous Delivery usually means a developer\u2019s changes to an application are automatically bug-tested, and the source code is bundled to the release candidate and uploaded to a repository (like GitHub or a container registry), where they can be deployed to further environments.&nbsp;<\/li>\n\n\n\n<li>The most common tasks of CI\/CD that organisations follow would look like below:&nbsp;<\/li>\n<\/ul>\n\n\n\n<figure class=\"wp-block-image size-large\"><img decoding=\"async\" src=\"https:\/\/devoteam.info\/wp-content\/uploads\/2024\/11\/CICD-1024x185.png\" alt=\"\" class=\"wp-image-160935\"\/><\/figure>\n\n\n\n<h3 class=\"wp-block-heading\" id=\"h-git-branching-strategy-and-best-practices-nbsp\"><strong>Git Branching Strategy and Best Practices&nbsp;<\/strong><\/h3>\n\n\n\n<p class=\"wp-block-paragraph\"><strong>Distributed versioning control systems<\/strong>&nbsp;like Git\/Atlassian Bitbucket\/Azure Repos give you the flexibility of version controlling your source code and consistently sharing the code with your team.&nbsp;<\/p>\n\n\n\n<p class=\"wp-block-paragraph\"><strong>Branching strategies are patterns or approaches that technology teams use to organise &amp; manage their source code through different branches in a version control system.&nbsp;<\/strong><\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Below are the different branching strategies that we can use:&nbsp;<\/p>\n\n\n\n<ol class=\"wp-block-list\">\n<li>Trunk-based branching strategy<\/li>\n\n\n\n<li>GitHub Flow\/Feature branching strategy<\/li>\n\n\n\n<li>Personal branching strategy<\/li>\n\n\n\n<li>GitFlow branching strategy<\/li>\n\n\n\n<li>GitLab Flow branching strategy<\/li>\n\n\n\n<li>Custom Release branching strategy (that I have used in the past)<\/li>\n<\/ol>\n\n\n\n<p class=\"wp-block-paragraph\"><strong>Trunk-based branching strategy:&nbsp;<\/strong><\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>A trunk-based branching strategy encourages developers to make minor updates to the master branch frequently.<\/li>\n\n\n\n<li>Developers are going to work with short-lived branches.<\/li>\n\n\n\n<li><strong>Advantages<\/strong>:\n<ul class=\"wp-block-list\">\n<li>This reduces the merge conflicts and challenges that developers face in other branching strategies.<\/li>\n<\/ul>\n<\/li>\n\n\n\n<li><strong>Disadvantages<\/strong>:\n<ul class=\"wp-block-list\">\n<li>The main problem with this is that there are high chances of having the code in the master branch, which is not yet promoted to Production.<\/li>\n\n\n\n<li>There is a high chance of having bugs in the main branch since the feature code is directly getting merged into the master branch. We need strong code reviews and test strategies to address this.<\/li>\n<\/ul>\n<\/li>\n<\/ul>\n\n\n\n<figure class=\"wp-block-image size-large\"><img decoding=\"async\" src=\"https:\/\/devoteam.info\/wp-content\/uploads\/2024\/11\/master-829x1024.png\" alt=\"\" class=\"wp-image-160954\"\/><\/figure>\n\n\n\n<p class=\"wp-block-paragraph\"><strong>GitHub Flow\/Feature branching strategy:&nbsp;<\/strong><\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Every feature gets its branch from the master branch.<\/li>\n\n\n\n<li>Once we finish our changes, we will merge the changes to the master branch using pull requests.<\/li>\n\n\n\n<li>Teams of any size can adopt this strategy after they\u2019ve familiarised themselves with Git and used this centralised workflow.&nbsp;<\/li>\n\n\n\n<li><strong>Advantages<\/strong>:\n<ul class=\"wp-block-list\">\n<li>This is a relatively simple branching workflow to follow.&nbsp;<\/li>\n\n\n\n<li>Hardly any branching management is needed than clearing up feature branches once they are released.&nbsp;<\/li>\n<\/ul>\n<\/li>\n\n\n\n<li><strong>Disadvantages:<\/strong>\n<ul class=\"wp-block-list\">\n<li>This requires some solid automation testing framework to ensure the features\/bugs we release to the master branch are well tested.&nbsp;<\/li>\n\n\n\n<li>This strategy is unable to support multiple versions of the code in Production at the same time.&nbsp;<\/li>\n<\/ul>\n<\/li>\n<\/ul>\n\n\n\n<figure class=\"wp-block-image size-large\"><img decoding=\"async\" src=\"https:\/\/devoteam.info\/wp-content\/uploads\/2024\/11\/branching-strategy-1024x977.png\" alt=\"\" class=\"wp-image-160974\"\/><\/figure>\n\n\n\n<p class=\"wp-block-paragraph\"><strong>Personal branching strategy:&nbsp;<\/strong><\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>This will be similar to feature branching, except it does not have a separate branch for per feature, but per developer.<\/li>\n\n\n\n<li>This can work if people are working on different bugs\/features.<\/li>\n\n\n\n<li><strong>Advantages<\/strong>:\n<ul class=\"wp-block-list\">\n<li>This strategy has the same advantage as Feature branching in having a separate branch to work with and when ready to merge the changes to the master branch.<\/li>\n\n\n\n<li>Branch management is easier since only a few branches are involved.<\/li>\n<\/ul>\n<\/li>\n\n\n\n<li><strong>Disadvantages<\/strong>:\n<ul class=\"wp-block-list\">\n<li>It is hard for two developers to work on the same feature.<\/li>\n\n\n\n<li>Also, If we are working on feature A and you get another one B as well, there is no easy way to merge back feature A without polluting the master branch.<\/li>\n\n\n\n<li>This strategy is unable to support multiple versions of the code in Production at the same time.&nbsp;<\/li>\n<\/ul>\n<\/li>\n<\/ul>\n\n\n\n<figure class=\"wp-block-image size-large\"><img decoding=\"async\" src=\"https:\/\/devoteam.info\/wp-content\/uploads\/2024\/11\/personal-branching-800x1024.png\" alt=\"\" class=\"wp-image-160993\"\/><\/figure>\n\n\n\n<p class=\"wp-block-paragraph\"><strong>GitFlow branching strategy:&nbsp;<\/strong><\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Gitflow is a branching model for Git, created by<a href=\"http:\/\/datasift.github.io\/gitflow\/IntroducingGitFlow.html\">&nbsp;Vincent Driessen<\/a>. It has attracted much attention because it is very well suited to collaboration and scaling the development team.<\/li>\n\n\n\n<li><strong>Branching workflow:&nbsp;<\/strong>\n<ul class=\"wp-block-list\">\n<li>New developments (new features, non-emergency bug fixes) are built-in feature branches.<\/li>\n\n\n\n<li>Feature branches are branched from the develop branch, and once the changes are ready, feature branches will be merged to develop branches with pull requests.<\/li>\n\n\n\n<li>When it is time to make a release, a release branch is created off the develop branch.<\/li>\n\n\n\n<li>The code in the release branch is deployed to higher test environments and tested, and any problems are fixed directly in the release branch. This deploy -&gt; test -&gt; fix -&gt; redeploy -&gt; retest cycle continues until you\u2019re happy that the release is good enough to release to customers.<\/li>\n\n\n\n<li>When the release is finished, the release branch is merged into the master and into develop to ensure that any changes made in the release branch aren\u2019t accidentally lost by new development.<\/li>\n\n\n\n<li>Hotfix branches are used to create emergency fixes.<\/li>\n\n\n\n<li>They are branched directly from a tagged release in the master branch and when finished, are merged back into both master and develop to make sure that the hotfix isn\u2019t accidentally lost when the next regular release occurs.<\/li>\n<\/ul>\n<\/li>\n\n\n\n<li><strong>Advantages:<\/strong>\n<ul class=\"wp-block-list\">\n<li>Parallel Development<\/li>\n\n\n\n<li>Collaboration<\/li>\n\n\n\n<li>Release Staging Area<\/li>\n\n\n\n<li>Support For Emergency Fixes<\/li>\n<\/ul>\n<\/li>\n\n\n\n<li><strong>Disadvantages:<\/strong>\n<ul class=\"wp-block-list\">\n<li>There are too many branches to track, and complicated for teams to follow. It can be easy to miss small changes, resulting in git conflicts.<\/li>\n\n\n\n<li>There is a need to educate the team and any new members on how the branching strategy works to avoid conflicts with the ways of working.<\/li>\n<\/ul>\n<\/li>\n<\/ul>\n\n\n\n<figure class=\"wp-block-image size-full\"><img decoding=\"async\" src=\"https:\/\/devoteam.info\/wp-content\/uploads\/2024\/11\/gitflow-branching-strategy.png\" alt=\"\" class=\"wp-image-161012\"\/><\/figure>\n\n\n\n<p class=\"wp-block-paragraph\">(Image from:&nbsp;<a href=\"http:\/\/datasift.github.io\/gitflow\/IntroducingGitFlow.html\">GitFlow branching Explanation<\/a>)<\/p>\n\n\n\n<p class=\"wp-block-paragraph\"><strong>GitLab Flow branching strategy:&nbsp;<\/strong><\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>The GitLab Flow branching strategy is similar to the Github Flow branching strategy. The main difference is that GitLab flow will have additional environment branches like PROD, release, etc, depending on the organisation\u2019s standards.&nbsp;<\/li>\n\n\n\n<li>Let\u2019s take the below branching workflow to explain how this flow works:\n<ul class=\"wp-block-list\">\n<li>feature\/*** \u2013 feature branch&nbsp;<\/li>\n\n\n\n<li>master \u2013 master branch&nbsp;<\/li>\n\n\n\n<li>PROD \u2013 production branch&nbsp;<\/li>\n\n\n\n<li>Hotfix- hotfix branch&nbsp;<\/li>\n<\/ul>\n<\/li>\n\n\n\n<li><strong>Branching workflow:&nbsp;<\/strong>\n<ul class=\"wp-block-list\">\n<li>New developments (new features, non-emergency bug fixes) are built-in feature branches.<\/li>\n\n\n\n<li>Feature branches are branched from the master branch, and once the changes are ready, feature branches will be merged into master branches with pull requests.<\/li>\n\n\n\n<li>When it is time to make a release, the master branch source code will be merged into the PROD branch.&nbsp;<\/li>\n\n\n\n<li>PROD branch serves here as the source of truth for Production deployment-ready code.&nbsp;<\/li>\n\n\n\n<li>Hotfix branches are used to create emergency fixes.<\/li>\n\n\n\n<li>They are branched directly from a tagged release in the master branch and when finished, are merged back into both master and PROD to make sure that the hotfix isn\u2019t accidentally lost when the next regular release occurs.<\/li>\n<\/ul>\n<\/li>\n\n\n\n<li><strong>Advantages:<\/strong>\n<ul class=\"wp-block-list\">\n<li>Comparing this to the GitFlow strategy, this is more simple.&nbsp;<\/li>\n\n\n\n<li>This also has the same benefits as the GitFlow strategy regarding Parallel Development, Collaboration, and support for Emergency fixes.&nbsp;&nbsp;<\/li>\n<\/ul>\n<\/li>\n\n\n\n<li><strong>Disadvantages:<\/strong>\n<ul class=\"wp-block-list\">\n<li>If organisations customise it by enabling more environmental branches like QA\/SIT and QA\/UAT, then this kind of modification results in high chances of merge conflicts between the branch merges.&nbsp;<\/li>\n<\/ul>\n<\/li>\n<\/ul>\n\n\n\n<figure class=\"wp-block-image size-large\"><img decoding=\"async\" src=\"https:\/\/devoteam.info\/wp-content\/uploads\/2024\/11\/GitLab-Flow-branching-strategy-1024x973.png\" alt=\"\" class=\"wp-image-161031\"\/><\/figure>\n\n\n\n<p class=\"wp-block-paragraph\"><strong>Custom Release branching strategy (that I have used in the past):&nbsp;<\/strong><\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>In this Custom-release branching strategy, we had the following branches:\n<ul class=\"wp-block-list\">\n<li>master \u2013 production code<\/li>\n\n\n\n<li>qa \u2013 release branch<\/li>\n\n\n\n<li>develop \u2013 integration branch<\/li>\n\n\n\n<li>feature\/**** \u2013 feature branches<\/li>\n<\/ul>\n<\/li>\n\n\n\n<li><strong>Branching workflow:&nbsp;<\/strong>\n<ul class=\"wp-block-list\">\n<li>The developers first check the code from the develop branch to work on any features\/bugs<\/li>\n\n\n\n<li>Once the developer completes the changes, They will push the code to his feature branch \u2013 which will compile\/test\/build the source code and deploy the change to the Dev environment.<\/li>\n\n\n\n<li>If the tests are good in the Dev environment, the Developer now raises a PR(pull request) from the feature\/**** branch to the develop branch and merges the changes in the develop branch. This will also compile\/test\/build the source code and deploy the change to the Sit\/Integration environment.<\/li>\n\n\n\n<li>The testers do the integration end-to-end tests \u2013\n<ul class=\"wp-block-list\">\n<li>If they find any issues:\n<ul class=\"wp-block-list\">\n<li>The developer will make the changes in the same feature branch.<\/li>\n\n\n\n<li>Once the change is deployed to the Dev environment (on push to his feature branch), they must raise a PR to the develop branch.<\/li>\n<\/ul>\n<\/li>\n\n\n\n<li>Note: here, it is the developer\u2019s responsibility to check and pull any changes in the develop branch made by anyone else within this time:\n<ul class=\"wp-block-list\">\n<li>Once the additional changes have been merged to the develop branch, the difference will automatically deploy to the Sit environment.<\/li>\n\n\n\n<li>The testing team will redo the testing on the same feature. If any bugs are found, the same process will repeat for any required changes. Otherwise, the feature will get sign-off to higher environments.<\/li>\n<\/ul>\n<\/li>\n\n\n\n<li>If none, the feature will get sign-off to higher environments.<\/li>\n<\/ul>\n<\/li>\n\n\n\n<li>To promote the change to higher environments (Uat\/PreProd) \u2013\n<ul class=\"wp-block-list\">\n<li>The Developer raises a PR from the develop branch to the QA branch<strong>.<\/strong><\/li>\n\n\n\n<li>The PR will get merged once the team members review it.<\/li>\n\n\n\n<li>As soon as this merges into the QA branch<strong>,&nbsp;<\/strong>the<strong>&nbsp;<\/strong>release must happen for the API\/application, and the git tag will be created.<\/li>\n<\/ul>\n<\/li>\n\n\n\n<li>At the time of the deployment to Production, the git version will be merged to the master branch, which will be production-based code.<\/li>\n<\/ul>\n<\/li>\n\n\n\n<li><strong>Advantages:<\/strong>\n<ul class=\"wp-block-list\">\n<li>This also has the same benefits as the GitFlow strategy in terms of Parallel Development, Collaboration, and support for Emergency fixes.&nbsp;&nbsp;<\/li>\n\n\n\n<li>Since this strategy does not have the release and environmental branches, it is easy for team members to track the changes.&nbsp; Also, it is simple for teams to educate any new team members.&nbsp;<\/li>\n<\/ul>\n<\/li>\n\n\n\n<li><strong>Disadvantages:<\/strong>\n<ul class=\"wp-block-list\">\n<li>If organisations customise it by enabling more environmental branches like QA\/SIT and QA\/UAT, then this kind of modification results in high chances of merge conflicts between the branch merges.&nbsp;<\/li>\n\n\n\n<li>This also has four branches to track the changes.&nbsp;<\/li>\n<\/ul>\n<\/li>\n\n\n\n<li><strong>Note<\/strong>: We can even customise this Custom branching strategy to remove the QA branch and do the tag\/release on the develop branch. However, having an intermediate branch after the develop stage<strong>&nbsp;<\/strong>(Sit deployment) gives more robustness to the releases that we are doing on this branch.&nbsp;<\/li>\n<\/ul>\n\n\n\n<figure class=\"wp-block-image size-large\"><img decoding=\"async\" src=\"https:\/\/devoteam.info\/wp-content\/uploads\/2024\/11\/custom-release-branching-strategy-1024x902.png\" alt=\"\" class=\"wp-image-161050\"\/><\/figure>\n\n\n\n<h2 class=\"wp-block-heading\"><strong>Conclusion:&nbsp;<\/strong><\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">CI\/CD is a key tool in today\u2019s software development world. It helps making and sharing software more efficient. While many articles discuss the basic steps like building and testing software, there\u2019s more to the story. This includes correctly labelling and releasing software. This part of the three-part blog series, covers the basics of CI\/CD and the use of Git Branching Strategy.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">CI\/CD is a two-part system. The CI part, or Continuous Integration, is about constantly adding and checking new software changes to ensure everything works well together. The CD part, which stands for Continuous Delivery\/Deployment, is about getting those changes ready and out to users smoothly.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Git, helps teams manage their software projects. Instead of mixing all the code, Git uses \u201cbranches\u201d to keep things organised. We discussed several ways to use these branches, each with its own set of rules and benefits. For example, one method is to create a separate branch for each new feature. Another approach is to have a branch for each developer. I also shared a custom method I\u2019ve used before, which combines elements from other strategies.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">In conclusion, selecting the right branching strategy to build robust CI\/CD pipelines in the organisation is essential. It involves testing and organising new code in a way that makes sense. This blog offered insights into how to do that more effectively.&nbsp;<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">In my opinion, the branching strategy need not be as complicated as GitFlow. And ideally, it should also not be like the Feature\/Personal branching example provided. Instead, we need to set the minimum viable branching strategy like the custom strategy we have discussed.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">If you want to discuss CI\/CD further and learn how to better implement a Git Branching Strategy for your company. Get in touch with one of our experts here.<\/p>\n\n\n\n<div class=\"wp-block-group has-gray-light-background-color has-background has-global-padding is-layout-constrained wp-container-core-group-is-layout-5d9a58c0 wp-block-group-is-layout-constrained\" style=\"padding-top:var(--wp--preset--spacing--small);padding-right:var(--wp--preset--spacing--small);padding-bottom:var(--wp--preset--spacing--small);padding-left:var(--wp--preset--spacing--small)\">\n<p class=\"wp-block-paragraph\"><strong>References:&nbsp;<\/strong><\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li><a href=\"https:\/\/splatform.devoteam.com\/expert-view\/your-winning-ci-cd-strategy-for-mulesoft-apis\/\">https:\/\/splatform.devoteam.com\/expert-view\/your-winning-ci-cd-strategy-for-mulesoft-apis\/<\/a><\/li>\n\n\n\n<li><a href=\"https:\/\/splatform.devoteam.com\/expert-view\/ci-cd-in-the-mulesoft-world-with-github-actions\/\">https:\/\/splatform.devoteam.com\/expert-view\/ci-cd-in-the-mulesoft-world-with-github-actions\/<\/a><\/li>\n\n\n\n<li><a href=\"https:\/\/www.atlassian.com\/git\/tutorials\/comparing-workflows\/gitflow-workflow\">https:\/\/www.atlassian.com\/git\/tutorials\/comparing-workflows\/gitflow-workflow<\/a><\/li>\n\n\n\n<li><a href=\"https:\/\/nvie.com\/posts\/a-successful-git-branching-model\/\">https:\/\/nvie.com\/posts\/a-successful-git-branching-model\/<\/a><\/li>\n<\/ul>\n<\/div>\n<\/div>\n\n\n\n<hr class=\"wp-block-separator has-text-color has-gray-color has-alpha-channel-opacity has-gray-background-color has-background is-style-default\" style=\"margin-top:var(--wp--preset--spacing--x-large);margin-bottom:var(--wp--preset--spacing--x-large)\"\/>\n\n\n\n<div id=\"chapter-3\" class=\"wp-block-group has-global-padding is-layout-constrained wp-block-group-is-layout-constrained\">\n<h2 class=\"wp-block-heading\" id=\"chapter2\">Continuous Integration&nbsp;<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">This is part two of our series on MuleSoft CI\/CD. In the previous chapter, we discussed the introduction of&nbsp;<strong>MuleSoft CI\/CD&nbsp;<\/strong>and Git Branching Strategies.&nbsp;<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">In this chapter, we will discuss the following topics.&nbsp;<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Recap on part one and Custom Branching Strategy Release Plan&nbsp;<\/li>\n\n\n\n<li>What is Continuous Integration?&nbsp;<\/li>\n\n\n\n<li>MuleSoft Continuous Integration(CI) implementation in GitHub Actions&nbsp;<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\"><strong>Recap on part one and Custom Branching Strategy Release Plan:&nbsp;<\/strong><\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>In part one of the blog, we discussed CI\/CD and Git Branching strategies.&nbsp;<\/li>\n\n\n\n<li>Let\u2019s now look at the Custom Branching strategy and try to implement the entire build\/release and deploy components of it using GitHub Actions.&nbsp;<\/li>\n\n\n\n<li>As we have already discussed the Custom Branching Strategy in the last blog, let\u2019s break down the CI\/CD pipeline workflows that we need to implement:\n<ol class=\"wp-block-list\">\n<li>A workflow that compiles and tests the Project and deploys it to the Dev environment when any changes happen to the feature\/* branches.\n<ul class=\"wp-block-list\">\n<li>The developer does the dev tests, and once the developer is happy, they will merge the feature to develop the branch. The source code from the develop branch needs to be deployed to the SIT environment. This allows us to build the following workflow.&nbsp;<\/li>\n<\/ul>\n<\/li>\n\n\n\n<li>A workflow that compiles\/tests the Project and deploys it to the SIT environment when any changes happen to the develop branch.\n<ul class=\"wp-block-list\">\n<li>Testers do the end-to-end integration testing in the SIT environment and sign off on the feature.&nbsp;<\/li>\n\n\n\n<li>The developer needs to merge the develop branch to a branch where the release happens for the source code.&nbsp;<\/li>\n\n\n\n<li>This is the place where we need a workflow to run the same compile\/build\/unit tests again and do the release on the Project. Preparing the release means removing the artefact SNAPSHOT version and creating a tag with the release version.&nbsp;<\/li>\n<\/ul>\n<\/li>\n\n\n\n<li>A workflow to compile and test the Project (QA) and then release the Project with their release activities(versioning and tagging) and make the tag available for the next UAT\/Prod deployment.\n<ul class=\"wp-block-list\">\n<li>This workflow will produce the release candidate available for the Operations team to deploy the Project to higher (UAT\/Prod) environments.<\/li>\n\n\n\n<li>So, here, we need a manual trigger-based workflow\/Action to deploy the released tag to higher environments(UAT\/Prod). This also needs to ensure the same QA branch source code change is merged to the master once the Production deployment is completed.&nbsp;<\/li>\n<\/ul>\n<\/li>\n\n\n\n<li>A manual workflow to take the release version\/tag and deploy it to a selected higher environment of choice(UAT\/Prod). Also, this workflow needs to merge the same QA branch change to the master branch once the Production deployment has been completed.&nbsp;<\/li>\n<\/ol>\n<\/li>\n\n\n\n<li>We have a total of four workflows to be built to deliver the entire CI\/CD pipeline.&nbsp;<\/li>\n\n\n\n<li>In this chapter, we will see the first two workflows from the \u201cMuleSoft CI implementation in GitHub Action\u201d section.\n<ol class=\"wp-block-list\">\n<li>The first one is to compile\/test\/run unit tests and deploy the Project in the Dev environment when any change happens to feature\/* branches.&nbsp;<\/li>\n\n\n\n<li>The second one is to compile\/test\/run unit tests and deploy the Project in the SIT environment when any change happens to the develop branch.&nbsp;<\/li>\n<\/ol>\n<\/li>\n\n\n\n<li>The next two workflows(mentioned below) will be discussed in the next blog part of \u201cMuleSoft CI\/CD Part-III Continuous Delivery\/Deployment\u201d.\n<ol class=\"wp-block-list\">\n<li>The third one is to clean\/compile\/test the Project and release the Project with the release activities(<strong>versioning and tagging<\/strong>) and make the tag available for the next UAT\/Prod deployment when any change happens to the QA branch.<\/li>\n\n\n\n<li>The fourth is a manual workflow to take the release version\/tag and deploy it to a selected higher environment of choice(UAT\/Prod) and merge the change from the QA branch to the master branch.&nbsp;<\/li>\n<\/ol>\n<\/li>\n<\/ul>\n\n\n\n<figure class=\"wp-block-image size-large\"><img decoding=\"async\" src=\"https:\/\/devoteam.info\/wp-content\/uploads\/2024\/11\/recap-1024x902.png\" alt=\"\" class=\"wp-image-161090\"\/><\/figure>\n\n\n\n<h3 class=\"wp-block-heading\"><strong>What is Continuous Integration?&nbsp;<\/strong><\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>The \u201cCI\u201d in CI\/CD refers to Continuous Integration (CI), an automation process for developers to build the application for any changes continuously.&nbsp;<\/li>\n\n\n\n<li>Continuous Integration (CI) is a development practice where developers integrate code into a shared repository frequently. &nbsp;Each code integration can then be verified by an automated build and automated tests (not mandatorily auto-tested, but most organisations do follow automated tests).&nbsp;<\/li>\n\n\n\n<li>One of the key benefits of Continuous Integration (CI) is that we can detect defects early and quickly.&nbsp;<\/li>\n\n\n\n<li>As each change is typically small, pinpointing the specific change that introduced the defect can be done quickly.&nbsp;<\/li>\n\n\n\n<li>Usually, Continuous Integration (CI) has the following tasks:\n<ul class=\"wp-block-list\">\n<li>Checkout source code of the Project&nbsp;<\/li>\n\n\n\n<li>Compile the Project&nbsp;<\/li>\n\n\n\n<li>Run the unit tests<\/li>\n\n\n\n<li>Deploy the Project to the Dev environment<\/li>\n<\/ul>\n<\/li>\n\n\n\n<li>We will see these tasks or CI steps in the next section, where we implement these steps for the MuleSoft API in GitHub Actions.&nbsp;<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\"><strong>MuleSoft Continuous Integration(CI) implementation in GitHub Actions<\/strong><\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">We will implement the first GitHub Actions Workflow to compile\/test and deploy the Project in the Dev environment when any change happens to feature\/* branches.&nbsp;<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">We will set up the GitHub Action by following the below steps:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Setup your Repository<\/li>\n\n\n\n<li>Setup the environments on the Repository&nbsp;<\/li>\n\n\n\n<li>Setup the environment variables on the Repository&nbsp;<\/li>\n\n\n\n<li>Run the pipeline&nbsp;<\/li>\n<\/ul>\n\n\n\n<p class=\"wp-block-paragraph\"><strong>Note:&nbsp;<\/strong>We are not storing the artifacts by building them separately for deploying them to environments instead, We are building and deploying in one step.&nbsp;<\/p>\n\n\n\n<p class=\"wp-block-paragraph\"><strong>Setup your Repository:&nbsp;<\/strong><\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>We won\u2019t go into the details of setting up the repository here. You can take a look at the&nbsp;<a href=\"https:\/\/github.com\/naginenipavan\/mule4-hello-world-impl\/tree\/master\">mule4-hello-world-impl<\/a>&nbsp;repo, which we will be using here for our CI implementation.&nbsp;<\/li>\n\n\n\n<li>Once you have the GitHub repository, Create a folder called&nbsp;<strong>.github<\/strong>&nbsp;and inside it another folder called&nbsp;<strong>workflows.&nbsp;<\/strong>Here, We will create&nbsp;<strong>dev-deploy.yaml and&nbsp;<\/strong>add the following content.&nbsp;<\/li>\n<\/ul>\n\n\n\n<p class=\"wp-block-paragraph\">name: Dev Deploy<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">run-name: Dev Build and Deployment<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">on:<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">&nbsp;&nbsp;push:<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">&nbsp;&nbsp;&nbsp;&nbsp;branches: [ feature\/* ]&nbsp;<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">jobs:<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">&nbsp;&nbsp;build-dev:<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">&nbsp;&nbsp;&nbsp;&nbsp;environment: dev<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">&nbsp;&nbsp;&nbsp;&nbsp;runs-on: ubuntu-latest<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">&nbsp;&nbsp;&nbsp;&nbsp;steps:<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;\u2013 name: Checkout this repo<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;uses: actions\/checkout@v4<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;\u2013 name: Cache dependencies<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;uses: actions\/cache@v3.3.2<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;with:<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;path: ~\/.m2\/repository<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;key: ${{ runner.os }}-maven<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;restore-keys: |<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;${{ runner.os }}-maven-<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;\u2013 name: Set up JDK 1.8<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;uses: actions\/setup-java@v3<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;with:<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;distribution: \u2018zulu\u2019<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;java-version: 8<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;\u2013 name: Clean with Maven<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;run: mvn clean compile&nbsp;<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;\u2013 name: Run Munit tests&nbsp;<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;run: mvn test<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;\u2013 name: Deploy to Dev environment&nbsp;<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;env:<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;ENV: ${{ vars.env }}<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;USERNAME: ${{ secrets.anypoint_username }}<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;PASSWORD: ${{ secrets.anypoint_password }}<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;ANYPOINT_USERNAME: ${{ secrets.anypoint_platform_username }}<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;ANYPOINT_PASSWORD: ${{ secrets.anypoint_platform_password }}<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;run: |<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;artifactName=$(ls *.jar | head -1)<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;mvn deploy -s .maven\/settings.xml -f pom.xml -DmuleDeploy \\<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;-Denv=$ENV \\<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;-Dmule.artifact=$artifactName \\<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;-Danypoint.username=\u201d$USERNAME\u201d \\<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;-Danypoint.password=\u201d$PASSWORD\u201d \\<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;-Danypoint_platform_username=\u201d$ANYPOINT_USERNAME\u201d \\<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;-Danypoint_platform_password=\u201d$ANYPOINT_PASSWORD\u201d&nbsp;<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>This file explains the CI steps to be performed on the MuleSoft API repository once any commit goes into the branches whose names start with feature\/*.&nbsp;<\/li>\n\n\n\n<li>Content of the file:\n<ul class=\"wp-block-list\">\n<li>The&nbsp;<strong>name<\/strong>&nbsp;field holds the name of the GitHub Action, which will appear in the UI under the Actions tab.&nbsp;<\/li>\n\n\n\n<li>The&nbsp;<strong>on<\/strong>&nbsp;field tells when a GitHub Action runs. For this Action, We have set it up to run when any commit happens on the branches whose name starts with the&nbsp;<strong>feature<\/strong>.&nbsp;<\/li>\n\n\n\n<li>A GitHub Action workflow is made up of jobs. Jobs will always run in parallel unless we mention any particular job with the&nbsp;<strong>needs<\/strong>&nbsp;keyword. A Job can have multiple steps to run in the workflow.&nbsp;<\/li>\n\n\n\n<li>For more information on GitHub Actions, you can refer to GitHub<a href=\"https:\/\/docs.github.com\/en\/actions\/quickstart\">&nbsp;Actions.&nbsp;<\/a><\/li>\n<\/ul>\n<\/li>\n\n\n\n<li>The first step is to check out the repository.<\/li>\n<\/ul>\n\n\n\n<p class=\"wp-block-paragraph\">&nbsp; &nbsp; &nbsp; \u2013 name: Checkout this repo<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;uses: actions\/checkout@v4<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>The second step caches the maven dependencies to make the subsequent runs to use the cached dependencies.&nbsp;<\/li>\n<\/ul>\n\n\n\n<p class=\"wp-block-paragraph\">&nbsp; &nbsp; &nbsp; \u2013 name: Cache dependencies<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;uses: actions\/cache@v3.3.2<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;with:<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;path: ~\/.m2\/repository<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;key: ${{ runner.os }}-maven<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>The third step sets the JDK version in the container where Github runs this GitHub Action.&nbsp;<\/li>\n<\/ul>\n\n\n\n<p class=\"wp-block-paragraph\">&nbsp; &nbsp; &nbsp; \u2013 name: Set up JDK 1.8<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;uses: actions\/setup-java@v3<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;with:<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;distribution: \u2018zulu\u2019<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;java-version: 8<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>The fourth step runs clean and compiles the Project using the maven lifecycle and phase.&nbsp;<\/li>\n<\/ul>\n\n\n\n<p class=\"wp-block-paragraph\">&nbsp; &nbsp; &nbsp; \u2013 name: Clean with Maven<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;run: mvn clean compile&nbsp;<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>The fifth step runs the unit tests(Munits) of the Project.&nbsp;<\/li>\n<\/ul>\n\n\n\n<p class=\"wp-block-paragraph\">&nbsp; &nbsp; &nbsp; \u2013 name: Run Munit tests&nbsp;<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;run: mvn test -Denv=dev<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>The last step builds the project and deploys the built jar file to CloudHub.&nbsp;<\/li>\n<\/ul>\n\n\n\n<p class=\"wp-block-paragraph\">\u2013 name: Deploy to Dev environment&nbsp;<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;env:<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;ENV: ${{ vars.env }}<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;USERNAME: ${{ secrets.anypoint_username }}<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;PASSWORD: ${{ secrets.anypoint_password }}<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;ANYPOINT_USERNAME: ${{ secrets.anypoint_platform_username }}<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;ANYPOINT_PASSWORD: ${{ secrets.anypoint_platform_password }}<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;run: |<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;artifactName=$(ls *.jar | head -1)<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;mvn deploy -s .maven\/settings.xml -f pom.xml -DmuleDeploy \\<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;-Denv=$ENV \\<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;-Dmule.artifact=$artifactName \\<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;-Danypoint.username=\u201d$USERNAME\u201d \\<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;-Danypoint.password=\u201d$PASSWORD\u201d \\<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;-Danypoint_platform_username=\u201d$ANYPOINT_USERNAME\u201d \\<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;-Danypoint_platform_password=\u201d$ANYPOINT_PASSWORD\u201d&nbsp;<\/p>\n\n\n\n<p class=\"wp-block-paragraph\"><strong>Setup the environments on Repository:&nbsp;<\/strong><\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>We can set up multiple environments on the GitHub Repository to deploy the project to multiple environments.&nbsp;<\/li>\n\n\n\n<li>For this, We need to go to the Project Settings and Environments section and add the environments.&nbsp;<\/li>\n<\/ul>\n\n\n\n<figure class=\"wp-block-image size-large\"><img loading=\"lazy\" decoding=\"async\" width=\"1024\" height=\"618\" src=\"https:\/\/devoteam.info\/wp-content\/uploads\/2024\/11\/environments-on-repository-1024x618.png\" alt=\"\" class=\"wp-image-161110\" srcset=\"https:\/\/devoteam.info\/wp-content\/uploads\/2024\/11\/environments-on-repository-1024x618.png 1024w, https:\/\/devoteam.info\/wp-content\/uploads\/2024\/11\/environments-on-repository-300x181.png 300w, https:\/\/devoteam.info\/wp-content\/uploads\/2024\/11\/environments-on-repository-768x463.png 768w, https:\/\/devoteam.info\/wp-content\/uploads\/2024\/11\/environments-on-repository.png 1382w\" sizes=\"auto, (max-width: 1024px) 100vw, 1024px\" \/><\/figure>\n\n\n\n<p class=\"wp-block-paragraph\"><strong>Setup the environment variables on Repository:<\/strong><\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>After creating the environment variables, it\u2019s time to create the required environment variables that are used by the GitHub Action.&nbsp;<\/li>\n\n\n\n<li>Create the below environment variables in&nbsp;<strong>dev<\/strong>&nbsp;environment\n<ul class=\"wp-block-list\">\n<li>ENV: dev<\/li>\n\n\n\n<li>APP_NAME: mule4-hello-world-impl-pavann-dev<\/li>\n\n\n\n<li>Secrets:\n<ul class=\"wp-block-list\">\n<li>ANYPOINT_USERNAME<\/li>\n\n\n\n<li>ANYPOINT_PASSWORD<\/li>\n\n\n\n<li>ANYPOINT_PLATFORM_USERNAME<\/li>\n\n\n\n<li>ANYPOINT_PLATFORM_PASSWORD<\/li>\n\n\n\n<li>Here, the first username and password are the Anypoint Platform access credentials to deploy the API, and the last two usernames and passwords are the dev environment API Manager connectivity platform credentials.&nbsp;<\/li>\n<\/ul>\n<\/li>\n<\/ul>\n<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\"><strong>Run the pipeline:&nbsp;<\/strong><\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>With this setup on the API Github repository, any changes to the repository in the feature\/* branches can trigger this GitHub Action automatically.&nbsp;<\/li>\n\n\n\n<li>You can go into the&nbsp;<strong>Actions<\/strong>&nbsp;tab to see the workflows. We can also click on the job to see the logs of each step included in the job, which will help debug the GitHub Action.<\/li>\n<\/ul>\n\n\n\n<figure class=\"wp-block-image size-large\"><img loading=\"lazy\" decoding=\"async\" width=\"1024\" height=\"618\" src=\"https:\/\/devoteam.info\/wp-content\/uploads\/2024\/11\/run-pipeline-1024x618.png\" alt=\"\" class=\"wp-image-161130\" srcset=\"https:\/\/devoteam.info\/wp-content\/uploads\/2024\/11\/run-pipeline-1024x618.png 1024w, https:\/\/devoteam.info\/wp-content\/uploads\/2024\/11\/run-pipeline-300x181.png 300w, https:\/\/devoteam.info\/wp-content\/uploads\/2024\/11\/run-pipeline-768x463.png 768w, https:\/\/devoteam.info\/wp-content\/uploads\/2024\/11\/run-pipeline.png 1382w\" sizes=\"auto, (max-width: 1024px) 100vw, 1024px\" \/><\/figure>\n\n\n\n<p class=\"wp-block-paragraph\">The second workflow we discussed to \u201ccompile\/test\/run unit tests and deploy the Project in SIT environment when any change happens to develop branch\u201d also looks like the same as the first GitHub workflow we developed above other than the environment change. We will just change the environment and environment variables to deploy. Below is the GitHub Workflow(Action) for the same:&nbsp;<\/p>\n\n\n\n<p class=\"has-link-color wp-elements-3 wp-block-paragraph\"><a href=\"https:\/\/github.com\/naginenipavan\/mule4-hello-world-impl\/blob\/master\/.github\/workflows\/sit-deploy.yaml\">https:\/\/github.com\/naginenipavan\/mule4-hello-world-impl\/blob\/master\/.github\/workflows\/sit-deploy.yaml<\/a><\/p>\n\n\n\n<h3 class=\"wp-block-heading\"><strong>Conclusion:&nbsp;<\/strong><\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">In this chapter, we delved deeper into the intricacies of Continuous Integration (CI) and its implementation using GitHub Actions.&nbsp;<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">CI, a cornerstone of modern software development, is where developers frequently merge code changes into a shared repository. This continuous merging allows for swift detection of defects, as each change is usually small and can be quickly verified through automated builds and tests.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">We discussed the importance of a structured CI\/CD release plan, particularly in MuleSoft API. By leveraging a custom branching strategy, developers can streamline the process of building, testing, and deploying their projects. The blog outlines four distinct workflows, each catering to different stages of the development lifecycle, from initial feature development to final production deployment.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">We looked at the practical implementation of these workflows using GitHub Actions and guided you in setting up repositories, defining environment variables, and crafting workflows to automate the CI process.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">In summary, this blog is a comprehensive guide for those looking to harness the power of CI and GitHub Actions in their MuleSoft API projects. By breaking down the CI\/CD release plan into manageable workflows, developers can ensure a smooth and efficient development process, from code integration to deployment.<\/p>\n\n\n\n<p class=\"has-link-color wp-elements-4 wp-block-paragraph\">If you want to discuss CI\/CD further and learn how to better implement GitHub Actions.&nbsp;<a href=\"https:\/\/devoteam.info\/uk\/get-in-touch\/\">Get in touch<\/a>&nbsp;with one of our experts here.<\/p>\n<\/div>\n\n\n\n<hr class=\"wp-block-separator has-text-color has-gray-color has-alpha-channel-opacity has-gray-background-color has-background is-style-default\" style=\"margin-top:var(--wp--preset--spacing--x-large);margin-bottom:var(--wp--preset--spacing--x-large)\"\/>\n\n\n\n<div id=\"chapter-3\" class=\"wp-block-group has-global-padding is-layout-constrained wp-block-group-is-layout-constrained\">\n<h2 class=\"wp-block-heading\" id=\"chapter3\">Continuous Deployment<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">This is part three of our series on MuleSoft CI\/CD.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">In this chapter, we will discuss the following topics.&nbsp;<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>A recap on part two and GitHub Actions\/Workflows we have built.<\/li>\n\n\n\n<li>What Continuous Delivery\/Deployment is?&nbsp;<\/li>\n\n\n\n<li>MuleSoft Continuous Delivery\/Deployment(CD) implementation in GitHub Actions.<\/li>\n<\/ul>\n\n\n\n<p class=\"wp-block-paragraph\"><strong>Recap on part two and GitHub Actions\/Workflows we have built for this chapter.<\/strong><\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>In part two, we discussed the Continuous Integration(CI) concept and broke down the release CI\/CD activities of the Custom branching strategy.&nbsp;<\/li>\n\n\n\n<li>We have also built the two GitHubActions part of the release plan:\n<ul class=\"wp-block-list\">\n<li>Workflow is used to compile\/test\/run unit tests and deploy the project in the dev environment when any change happens to feature\/* branches.&nbsp;<\/li>\n\n\n\n<li>Workflow to compile\/test and deploy the Project in the SIT environment when any change happens to the develop branch.&nbsp;<\/li>\n<\/ul>\n<\/li>\n\n\n\n<li>We must build the following GitHubActions part of this Continuous Delivery\/Deployment (CD) blog. First, we will discuss \u201cWhat is Continuous Delivery\/Deployment?\u201d\n<ul class=\"wp-block-list\">\n<li>Workflow to clean\/compile\/test the Project and release the Project with the release activities(versioning and tagging). Make the tag available for the next UAT\/Prod deployment when any change happens to the QA branch.&nbsp;<\/li>\n\n\n\n<li>A manual workflow to take the release version\/tag, deploy it to a selected higher environment of choice(UAT\/Prod), and merge the change from the QA branch to the master branch.&nbsp;<\/li>\n<\/ul>\n<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\" id=\"h-what-is-continuous-delivery-deploymen\"><strong>What is Continuous Delivery\/Deploymen<\/strong>?<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>The \u201cCD\u201d in CI\/CD refers to Continuous Delivery\/Deployment, related concepts that sometimes get used interchangeably.&nbsp;<\/li>\n\n\n\n<li>Continuous Delivery usually means a developer\u2019s changes to an application are automatically bug-tested, and the source code is bundled to the release candidate and uploaded to a repository (like GitHub or a container registry), where they can be deployed to further environments.&nbsp;<\/li>\n\n\n\n<li>Put simply, Continuous Delivery is a software development practice where code changes are automatically prepared for a production release.<\/li>\n\n\n\n<li>When properly implemented, developers will always have a deployment-ready build artefact that has passed a standardised test process.<\/li>\n\n\n\n<li>Continuous Deployment involves deploying every change to the configured environments from the respective branch where the change happened. As there is no human intervention, the pipeline execution is not held up for approval. This is the best practice for Dev\/SIT environments but not for UAT and Production.&nbsp;<\/li>\n\n\n\n<li>Continuous Delivery, on the other hand, prepares the release artefacts, allowing IT teams to deploy changes quickly with the push of a button (Manual Workflows).<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\" id=\"h-mulesoft-continuous-delivery-deployment-cd-implementation-in-github-actions\">MuleSoft Continuous Delivery\/Deployment (CD) implementation in GitHub Actions:<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>We will start implementing the&nbsp;<strong>GitHub workflow\/Action<\/strong>&nbsp;\u201cto clean\/compile\/test the Project and release the Project with the release activities(versioning and tagging) and make the tag available for the next UAT\/Prod deployment when any change happens to the QA branch\u201d.\n<ul class=\"wp-block-list\">\n<li>We will set up the GitHub Action by following the below steps:\n<ul class=\"wp-block-list\">\n<li>Set up your Repository and GitHub Workflow\/Action.<\/li>\n\n\n\n<li>Make some changes to the QA branch to verify the release.&nbsp;<\/li>\n<\/ul>\n<\/li>\n\n\n\n<li>We have already been using&nbsp;&nbsp;<a href=\"https:\/\/github.com\/naginenipavan\/mule4-hello-world-impl\/tree\/master\">mule4-hello-world-impl<\/a>&nbsp;repo, so we will continue to use the same here as well.<\/li>\n\n\n\n<li>In the same&nbsp;<strong>.github\/workflows<\/strong>&nbsp;folder, we will create&nbsp;<strong>qa-release.yaml<\/strong>&nbsp;and add the following content.&nbsp;<\/li>\n<\/ul>\n<\/li>\n<\/ul>\n\n\n\n<p class=\"wp-block-paragraph\">name: Qa Release<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">run-name: Qa Release and Tagging<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">on:<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">&nbsp;&nbsp;push:<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">&nbsp;&nbsp;&nbsp;&nbsp;branches: [ qa ]&nbsp;<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">jobs:<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">&nbsp;&nbsp;build-release-qa:<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">&nbsp;&nbsp;&nbsp;&nbsp;runs-on: ubuntu-latest<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">&nbsp;&nbsp;&nbsp;&nbsp;steps:<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;\u2013 name: Checkout this repo<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;uses: actions\/checkout@v4<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;\u2013 name: Cache dependencies<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;uses: actions\/cache@v3.3.2<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;with:<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;path: ~\/.m2\/repository<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;key: ${{ runner.os }}-maven<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;restore-keys: |<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;${{ runner.os }}-maven<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;\u2013 name: Set up JDK 1.8<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;uses: actions\/setup-java@v3<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;with:<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;distribution: \u2018zulu\u2019<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;java-version: 8<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;\u2013 name: Clean and Compile with Maven<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;run: mvn clean compile&nbsp;<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;\u2013 name: Remove SNAPSHOT and prepare release<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;run: mvn versions:set -DremoveSnapshot<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;\u2013 name: Compile and Test the project&nbsp;<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;run: |<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;mvn clean compile -U<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;mvn test -Denv=sit&nbsp;<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;\u2013 name: Extract the POM version<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;id: retrieve-pom-version<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;run: |<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;echo \u201cPOM_VERSION=$(mvn help:evaluate -Dexpression=project.version -q -DforceStdout)\u201d &gt;&gt; $GITHUB_OUTPUT&nbsp;&nbsp;<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;\u2013 name: Tag the release and commit\/push changes to remote repository<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;env:&nbsp;<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;POM_VERSION: ${{ steps.retrieve-pom-version.outputs.POM_VERSION }}<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;run: |<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;echo \u201c$POM_VERSION\u201d<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;git add pom.xml&nbsp;<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;git config \u2013global user.email \u201cnaginenipavan@outlook.com\u201d<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;git config \u2013global user.name \u201cPavan Nagineni\u201d<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;git commit -m \u201cRelease $POM_VERSION\u201d<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;git tag \u201c$POM_VERSION\u201d<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;echo \u201cReleased to $POM_VERSION version.\u201d<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;git push origin qa \u201c$POM_VERSION\u201d<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;\u2013 name: Checkout the Develop branch and Merge the Qa Release change<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;env:&nbsp;<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;POM_VERSION: ${{ steps.retrieve-pom-version.outputs.POM_VERSION }}<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;run: |<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;git remote update \u2013prune<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;git checkout origin\/develop \u2013force<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;git reset \u2013hard origin\/qa<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;\u2013 name: Prepare the next development version in develop branch&nbsp;<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;run: |<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;mvn build-helper:parse-version versions:set -DnewVersion=\u2019${parsedVersion.majorVersion}.${parsedVersion.minorVersion}.${parsedVersion.nextIncrementalVersion}-SNAPSHOT\u2019<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;mvn versions:commit<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;git add pom.xml&nbsp;<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;git config \u2013global user.email \u2018naginenipavan@outlook.com\u2019<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;git config \u2013global user.name \u201cPavan Nagineni\u201d&nbsp;<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;echo \u201cincremented to next $(mvn help:evaluate -Dexpression=project.version -q -DforceStdout) version.\u201d<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;git commit -m \u201cincremented to next $(mvn help:evaluate -Dexpression=project.version -q -DforceStdout) version\u201d<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;git push -f -u origin HEAD:develop&nbsp;<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>As we have already discussed the \u201c<strong>name\u201d<\/strong>&nbsp;and \u201c<strong>on\u201d<\/strong>&nbsp;sections in the Part-II blog, we will discuss the steps of the&nbsp;<strong>build-release-qa<\/strong>&nbsp;job.&nbsp;<\/li>\n\n\n\n<li>The first step is to check out the repository.<\/li>\n<\/ul>\n\n\n\n<p class=\"wp-block-paragraph\">&nbsp; &nbsp; &nbsp; \u2013 name: Checkout this repo<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;uses: actions\/checkout@v4<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>The second step caches the maven dependencies to make the subsequent runs to use the cached dependencies.&nbsp;<\/li>\n<\/ul>\n\n\n\n<p class=\"wp-block-paragraph\">&nbsp; &nbsp; &nbsp; \u2013 name: Cache dependencies<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;uses: actions\/cache@v3.3.2<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;with:<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;path: ~\/.m2\/repository<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;key: ${{ runner.os }}-maven<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>The third step sets the JDK version in the container where Github runs this GitHub Action.&nbsp;<\/li>\n<\/ul>\n\n\n\n<p class=\"wp-block-paragraph\">&nbsp; &nbsp; &nbsp; \u2013 name: Set up JDK 1.8<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;uses: actions\/setup-java@v3<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;with:<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;distribution: \u2018zulu\u2019<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;java-version: 8<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>The fourth step runs clean and compiles the Project using the maven lifecycle and phase.&nbsp;<\/li>\n<\/ul>\n\n\n\n<p class=\"wp-block-paragraph\">&nbsp; &nbsp; &nbsp; \u2013 name: Clean with Maven<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;run: mvn clean compile&nbsp;<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>The fifth step is to remove the artefact SNAPSHOT version and prepare the project for release.&nbsp;<\/li>\n<\/ul>\n\n\n\n<p class=\"wp-block-paragraph\">&nbsp; &nbsp; &nbsp; \u2013 name: Remove SNAPSHOT and prepare release<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;run: mvn versions:set -DremoveSnapshot<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>The sixth step runs the project\u2019s unit tests again to ensure the above change did not affect the Project.<\/li>\n<\/ul>\n\n\n\n<p class=\"wp-block-paragraph\">&nbsp; \u2013 name: Compile and Test the project&nbsp;<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;run: |<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;mvn clean compile -U<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;mvn test -Denv=sit&nbsp;<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>The seventh step is to extract the POM version, which is the release version that will be useful in the next step to create the tag. The next step will use this step output.&nbsp;<\/li>\n<\/ul>\n\n\n\n<p class=\"wp-block-paragraph\">&nbsp; &nbsp; &nbsp; \u2013 name: Extract the POM version<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;id: retrieve-pom-version<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;run: |<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;echo \u201cPOM_VERSION=$(mvn help:evaluate -Dexpression=project.version -q -DforceStdout)\u201d &gt;&gt; $GITHUB_OUTPUT&nbsp;&nbsp;<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>The eighth step is the main step, where we do the actual release by committing the above artefact SNAPSHOT version removal change and creating the git tag. This step uses the last step output to save the POM version in a variable.&nbsp;<\/li>\n<\/ul>\n\n\n\n<p class=\"wp-block-paragraph\">&nbsp; &nbsp; &nbsp; \u2013 name: Tag the release and commit\/push changes to remote repository<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;env:&nbsp;<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;POM_VERSION: ${{ steps.retrieve-pom-version.outputs.POM_VERSION }}<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;run: |<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;echo \u201c$POM_VERSION\u201d<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;git add pom.xml&nbsp;<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;git config \u2013global user.email \u201cnaginenipavan@outlook.com\u201d<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;git config \u2013global user.name \u201cPavan Nagineni\u201d<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;git commit -m \u201cRelease $POM_VERSION\u201d<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;git tag \u201c$POM_VERSION\u201d<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;echo \u201cReleased to $POM_VERSION version.\u201d<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;git push origin qa \u201c$POM_VERSION\u201d<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>&nbsp;At this point, the QA branch has the release version and the release tag as well. Now it\u2019s time to check out the develop branch and merge the same release change. This is the tenth step of the job.&nbsp;<\/li>\n<\/ul>\n\n\n\n<p class=\"wp-block-paragraph\">&nbsp; &nbsp; &nbsp; \u2013 name: Checkout the Develop branch and Merge the Qa Release change<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;env:&nbsp;<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;POM_VERSION: ${{ steps.retrieve-pom-version.outputs.POM_VERSION }}<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;run: |<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;git remote update \u2013prune<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;git checkout origin\/develop \u2013force<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;git reset \u2013hard origin\/qa<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>The last and final step is to increment the develop branch POM version to the next SNAPSHOT and make this branch readily available for the next developments.&nbsp;<\/li>\n<\/ul>\n\n\n\n<p class=\"wp-block-paragraph\">&nbsp; &nbsp; &nbsp; \u2013 name: Prepare the next development version in develop branch&nbsp;<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;run: |<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;mvn build-helper:parse-version versions:set -DnewVersion=\u2019${parsedVersion.majorVersion}.${parsedVersion.minorVersion}.${parsedVersion.nextIncrementalVersion}-SNAPSHOT\u2019<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;mvn versions:commit<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;git add pom.xml&nbsp;<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;git config \u2013global user.email \u2018naginenipavan@outlook.com\u2019<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;git config \u2013global user.name \u201cPavan Nagineni\u201d&nbsp;<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;echo \u201cincremented to next $(mvn help:evaluate -Dexpression=project.version -q -DforceStdout) version.\u201d<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;git commit -m \u201cincremented to next $(mvn help:evaluate -Dexpression=project.version -q -DforceStdout) version\u201d<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;git push -f -u origin HEAD:develop&nbsp;<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>When we merge a change from the develop branch to the QA branch, the runs and releases the Project with the release version. Below is the screenshot of the&nbsp;<strong>1.0.23 release.<\/strong><strong><br><\/strong><\/li>\n\n\n\n<li>Below are the GitHub Workflow\/Action commits of the release on both the QA and develop branches.<\/li>\n<\/ul>\n\n\n\n<figure class=\"wp-block-image size-large\"><img loading=\"lazy\" decoding=\"async\" width=\"1024\" height=\"244\" src=\"https:\/\/devoteam.info\/wp-content\/uploads\/2024\/11\/github-workflow-action-1024x244.png\" alt=\"\" class=\"wp-image-161153\" srcset=\"https:\/\/devoteam.info\/wp-content\/uploads\/2024\/11\/github-workflow-action-1024x244.png 1024w, https:\/\/devoteam.info\/wp-content\/uploads\/2024\/11\/github-workflow-action-300x72.png 300w, https:\/\/devoteam.info\/wp-content\/uploads\/2024\/11\/github-workflow-action-768x183.png 768w, https:\/\/devoteam.info\/wp-content\/uploads\/2024\/11\/github-workflow-action.png 1504w\" sizes=\"auto, (max-width: 1024px) 100vw, 1024px\" \/><\/figure>\n\n\n\n<figure class=\"wp-block-image size-large\"><img loading=\"lazy\" decoding=\"async\" width=\"1024\" height=\"278\" src=\"https:\/\/devoteam.info\/wp-content\/uploads\/2024\/11\/github-workflow-action-2-1024x278.png\" alt=\"\" class=\"wp-image-161172\" srcset=\"https:\/\/devoteam.info\/wp-content\/uploads\/2024\/11\/github-workflow-action-2-1024x278.png 1024w, https:\/\/devoteam.info\/wp-content\/uploads\/2024\/11\/github-workflow-action-2-300x81.png 300w, https:\/\/devoteam.info\/wp-content\/uploads\/2024\/11\/github-workflow-action-2-768x208.png 768w, https:\/\/devoteam.info\/wp-content\/uploads\/2024\/11\/github-workflow-action-2.png 1498w\" sizes=\"auto, (max-width: 1024px) 100vw, 1024px\" \/><\/figure>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Next<\/strong>, we will implement the&nbsp;<strong>manual<\/strong><strong>GitHub workflow\/Action<\/strong>&nbsp;\u201cto take the release version\/tag and deploy it to a selected higher environment of choice (UAT\/Prod) and merge the change from the QA branch to the master branch\u201d.\n<ul class=\"wp-block-list\">\n<li>We will set up the GitHub Action by following the below steps:\n<ul class=\"wp-block-list\">\n<li>Set up your Repository and GitHub Workflow\/Action.<\/li>\n\n\n\n<li>Make some changes to the QA branch to verify the release.&nbsp;<\/li>\n<\/ul>\n<\/li>\n\n\n\n<li>We have already been using&nbsp;&nbsp;<a href=\"https:\/\/github.com\/naginenipavan\/mule4-hello-world-impl\/tree\/master\">mule4-hello-world-impl<\/a>&nbsp;repo, so we will continue to use the same here as well.<\/li>\n\n\n\n<li>In the same&nbsp;<strong>.github\/workflows<\/strong>&nbsp;folder, we will create&nbsp;<strong>qa-release.yaml<\/strong>&nbsp;and add the following content.<\/li>\n<\/ul>\n<\/li>\n<\/ul>\n\n\n\n<p class=\"wp-block-paragraph\">name: Release<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">run-name: Release Deployment<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">on:<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">&nbsp;&nbsp;workflow_dispatch:&nbsp;<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">&nbsp;&nbsp;&nbsp;&nbsp;inputs:&nbsp;<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;tag:&nbsp;<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;description: Tag Version in form of MAJOR.MINOR.VERSION like 1.0.0<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;required: true<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;env:&nbsp;<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;description: environment to deploy uat or prod&nbsp;<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;required: true<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">jobs:&nbsp;<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">&nbsp;&nbsp;release-deploy:<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">&nbsp;&nbsp;&nbsp;&nbsp;runs-on: ubuntu-latest<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">&nbsp;&nbsp;&nbsp;&nbsp;if:&nbsp; ${{ inputs.tag }}&nbsp;<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">&nbsp;&nbsp;&nbsp;&nbsp;environment: ${{ inputs.env }}<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">&nbsp;&nbsp;&nbsp;&nbsp;steps:<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;\u2013 name: Checkout this repo<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;uses: actions\/checkout@v4<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;\u2013 name: Cache dependencies<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;uses: actions\/cache@v3.3.2<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;with:<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;path: ~\/.m2\/repository<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;key: ${{ runner.os }}-maven<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;restore-keys: |<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;${{ runner.os }}-maven<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;\u2013 name: Set up JDK 1.8<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;uses: actions\/setup-java@v3<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;with:<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;distribution: \u2018zulu\u2019<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;java-version: 8<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;\u2013 name: Clean and Compile with Maven<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;env:&nbsp;<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;ENV: ${{ inputs.env }}<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;TAG_VERSION: ${{ inputs.tag }}<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;run: |<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;echo \u201cDeploying the $TAG_VERSION to environment: $ENV\u201d<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;git remote update \u2013prune<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;git checkout tags\/\u201d$TAG_VERSION\u201d<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;\u2013 name: Clean with Maven<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;run: mvn clean compile&nbsp;<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;\u2013 name: Run Munit tests&nbsp;<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;run: mvn test -Denv=sit<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;\u2013 name: Deploy to Release environment<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;env:<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;ENV: ${{ inputs.env }}<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;USERNAME: ${{ secrets.anypoint_username }}<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;PASSWORD: ${{ secrets.anypoint_password }}<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;ANYPOINT_USERNAME: ${{ secrets.anypoint_platform_username }}<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;ANYPOINT_PASSWORD: ${{ secrets.anypoint_platform_password }}<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;run: |<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;artifactName=$(ls *.jar | head -1)<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;mvn deploy -s .maven\/settings.xml -f pom.xml -DmuleDeploy \\<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;-Denv=$ENV \\<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;-Dmule.artifact=$artifactName \\<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;-Danypoint.username=\u201d$USERNAME\u201d \\<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;-Danypoint.password=\u201d$PASSWORD\u201d \\<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;-Danypoint_platform_username=\u201d$ANYPOINT_USERNAME\u201d \\<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;-Danypoint_platform_password=\u201d$ANYPOINT_PASSWORD\u201d&nbsp;<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;\u2013 name: Checkout the master branch and Merge the Tag<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">&nbsp;&nbsp;&nbsp;&nbsp;if:&nbsp; ${{ inputs.env == \u2018prod\u2019 }}<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;env:&nbsp;<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;TAG_VERSION: ${{ inputs.tag }}<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;run: |<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;git remote update \u2013prune<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;git checkout origin\/master \u2013force<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;git reset \u2013hard tags\/\u201d$TAG_VERSION\u201d&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>The&nbsp;<strong>name<\/strong>&nbsp;field holds the name of the GitHub Action, which will appear in the UI under the Actions tab.&nbsp;<\/li>\n\n\n\n<li>The&nbsp;<strong>on<\/strong>&nbsp;field tells when a GitHub Action runs. For this Action, we have set it up with a manual trigger by providing the deployable tag(released tag) and the environment to deploy the project(uat\/prod). These two inputs are mandatory for this workflow.&nbsp;<\/li>\n\n\n\n<li>Next, we will jump in to discuss the steps of the&nbsp;<strong>release-deploy<\/strong>&nbsp;job. The first 3 steps are the same as the previous workflow, So we are leaving it out to discuss them explicitly here, But they are part of this workflow as well.&nbsp;<\/li>\n\n\n\n<li>The fourth step is to clean and compile the Project with the help of the tag version provided in the inputs.&nbsp;<\/li>\n<\/ul>\n\n\n\n<p class=\"wp-block-paragraph\">&nbsp; &nbsp; &nbsp; \u2013 name: Clean and Compile with Maven<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;env:&nbsp;<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;ENV: ${{ inputs.env }}<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;TAG_VERSION: ${{ inputs.tag }}<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;run: |<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;echo \u201cDeploying the $TAG_VERSION to environment: $ENV\u201d<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;git remote update \u2013prune<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;git checkout tags\/\u201d$TAG_VERSION\u201d<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>The fifth step runs the unit tests of the Project.&nbsp;<\/li>\n<\/ul>\n\n\n\n<p class=\"wp-block-paragraph\">&nbsp; &nbsp; &nbsp; &nbsp; \u2013 name: Run Munit tests&nbsp;<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;run: mvn test -Denv=sit<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>After unit tests, it\u2019s time to deploy the project by building it, and this sixth step does the same.&nbsp;<\/li>\n<\/ul>\n\n\n\n<p class=\"wp-block-paragraph\">&nbsp; &nbsp; &nbsp; \u2013 name: Deploy to Release environment<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;env:<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;ENV: ${{ inputs.env }}<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;USERNAME: ${{ secrets.anypoint_username }}<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;PASSWORD: ${{ secrets.anypoint_password }}<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;ANYPOINT_USERNAME: ${{ secrets.anypoint_platform_username }}<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;ANYPOINT_PASSWORD: ${{ secrets.anypoint_platform_password }}<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;run: |<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;artifactName=$(ls *.jar | head -1)<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;mvn deploy -s .maven\/settings.xml -f pom.xml -DmuleDeploy \\<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;-Denv=$ENV \\<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;-Dmule.artifact=$artifactName \\<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;-Danypoint.username=\u201d$USERNAME\u201d \\<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;-Danypoint.password=\u201d$PASSWORD\u201d \\<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;-Danypoint_platform_username=\u201d$ANYPOINT_USERNAME\u201d \\<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;-Danypoint_platform_password=\u201d$ANYPOINT_PASSWORD\u201d&nbsp;<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Note:&nbsp;&nbsp;<\/strong>We need to set the environments (uat\/prod) and environment variables as we have set for the first two GitHub workflows\/Actions in the Part-II blog.&nbsp;<\/li>\n\n\n\n<li>After successful Production deployment, we need to ensure we are merging the same release to the master branch as well. So, we will be making the master branch HEAD to point to the released tag. This is the last step of the CI\/CD pipeline.<\/li>\n\n\n\n<li>This last and final step runs only if the given environment variable \u201cenv\u201d matches to \u201cprod\u201d only.&nbsp;<\/li>\n<\/ul>\n\n\n\n<p class=\"wp-block-paragraph\">&nbsp; &nbsp; &nbsp; \u2013 name: Checkout the master branch and Merge the Tag (only after prod deployment)<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;if:&nbsp; ${{ inputs.env == \u2018prod\u2019 }}<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;env:&nbsp;<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;TAG_VERSION: ${{ inputs.tag }}<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;run: |<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;git remote update \u2013prune<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;git checkout origin\/master \u2013force<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;git reset \u2013hard tags\/\u201d$TAG_VERSION\u201d&nbsp;&nbsp;<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>When we run a manual deployment to UAT and Production, both of the runs look like the below:&nbsp;<\/li>\n<\/ul>\n\n\n\n<figure class=\"wp-block-image size-large\"><img loading=\"lazy\" decoding=\"async\" width=\"1024\" height=\"570\" src=\"https:\/\/devoteam.info\/wp-content\/uploads\/2024\/11\/manual-deployment-1024x570.png\" alt=\"\" class=\"wp-image-161192\" srcset=\"https:\/\/devoteam.info\/wp-content\/uploads\/2024\/11\/manual-deployment-1024x570.png 1024w, https:\/\/devoteam.info\/wp-content\/uploads\/2024\/11\/manual-deployment-300x167.png 300w, https:\/\/devoteam.info\/wp-content\/uploads\/2024\/11\/manual-deployment-768x428.png 768w, https:\/\/devoteam.info\/wp-content\/uploads\/2024\/11\/manual-deployment.png 1377w\" sizes=\"auto, (max-width: 1024px) 100vw, 1024px\" \/><\/figure>\n\n\n\n<figure class=\"wp-block-image size-large\"><img loading=\"lazy\" decoding=\"async\" width=\"1024\" height=\"579\" src=\"https:\/\/devoteam.info\/wp-content\/uploads\/2024\/11\/manu-depoylent-2-1024x579.png\" alt=\"\" class=\"wp-image-161211\" srcset=\"https:\/\/devoteam.info\/wp-content\/uploads\/2024\/11\/manu-depoylent-2-1024x579.png 1024w, https:\/\/devoteam.info\/wp-content\/uploads\/2024\/11\/manu-depoylent-2-300x170.png 300w, https:\/\/devoteam.info\/wp-content\/uploads\/2024\/11\/manu-depoylent-2-768x434.png 768w, https:\/\/devoteam.info\/wp-content\/uploads\/2024\/11\/manu-depoylent-2.png 1390w\" sizes=\"auto, (max-width: 1024px) 100vw, 1024px\" \/><\/figure>\n\n\n\n<p class=\"wp-block-paragraph\">Below are the commits of the GitHub Workflow\/Action part of the Production deployment on the master branch.<\/p>\n\n\n\n<figure class=\"wp-block-image size-large\"><img loading=\"lazy\" decoding=\"async\" width=\"1024\" height=\"237\" src=\"https:\/\/devoteam.info\/wp-content\/uploads\/2024\/11\/commits-1024x237.png\" alt=\"\" class=\"wp-image-161230\" srcset=\"https:\/\/devoteam.info\/wp-content\/uploads\/2024\/11\/commits-1024x237.png 1024w, https:\/\/devoteam.info\/wp-content\/uploads\/2024\/11\/commits-300x69.png 300w, https:\/\/devoteam.info\/wp-content\/uploads\/2024\/11\/commits-768x178.png 768w, https:\/\/devoteam.info\/wp-content\/uploads\/2024\/11\/commits-1536x355.png 1536w, https:\/\/devoteam.info\/wp-content\/uploads\/2024\/11\/commits.png 1552w\" sizes=\"auto, (max-width: 1024px) 100vw, 1024px\" \/><\/figure>\n\n\n\n<p class=\"wp-block-paragraph\">The API works on UAT and Production:<\/p>\n\n\n\n<figure class=\"wp-block-image size-large\"><img loading=\"lazy\" decoding=\"async\" width=\"1024\" height=\"270\" src=\"https:\/\/devoteam.info\/wp-content\/uploads\/2024\/11\/api-1024x270.png\" alt=\"\" class=\"wp-image-161249\" srcset=\"https:\/\/devoteam.info\/wp-content\/uploads\/2024\/11\/api-1024x270.png 1024w, https:\/\/devoteam.info\/wp-content\/uploads\/2024\/11\/api-300x79.png 300w, https:\/\/devoteam.info\/wp-content\/uploads\/2024\/11\/api-768x202.png 768w, https:\/\/devoteam.info\/wp-content\/uploads\/2024\/11\/api.png 1530w\" sizes=\"auto, (max-width: 1024px) 100vw, 1024px\" \/><\/figure>\n\n\n\n<figure class=\"wp-block-image size-large\"><img loading=\"lazy\" decoding=\"async\" width=\"1024\" height=\"270\" src=\"https:\/\/devoteam.info\/wp-content\/uploads\/2024\/11\/api-2-1024x270.png\" alt=\"\" class=\"wp-image-161268\" srcset=\"https:\/\/devoteam.info\/wp-content\/uploads\/2024\/11\/api-2-1024x270.png 1024w, https:\/\/devoteam.info\/wp-content\/uploads\/2024\/11\/api-2-300x79.png 300w, https:\/\/devoteam.info\/wp-content\/uploads\/2024\/11\/api-2-768x202.png 768w, https:\/\/devoteam.info\/wp-content\/uploads\/2024\/11\/api-2.png 1530w\" sizes=\"auto, (max-width: 1024px) 100vw, 1024px\" \/><\/figure>\n\n\n\n<p class=\"wp-block-paragraph\">In this comprehensive three-part series on MuleSoft CI\/CD, we\u2019ve delved into the intricacies of Continuous Integration (CI), Continuous Delivery\/Deployment (CD), and Git Branching Strategies, providing a detailed guide on their implementation using GitHub Actions.&nbsp;<\/p>\n\n\n\n<h3 class=\"wp-block-heading\"><strong>Conclusion:<\/strong><\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">The series begins with exploring Git Branching Strategy, laying the foundation for an effective CI\/CD pipeline. It then progresses to Continuous Integration, discussing the creation of workflows for compiling, testing, and deploying projects in development and SIT environments.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">The third part, which is the focus of this blog, centres on Continuous Delivery\/Deployment. It clarifies the distinction between the two: Continuous Delivery automates the process up to the production release, while Continuous Deployment goes a step further by deploying every change to the respective environments without human intervention.&nbsp;<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">This blog outlines the steps to implement CD in GitHub Actions, including setting up workflows for releasing and tagging in the QA branch and deploying to higher environments like UAT or Production.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">The approach we\u2019ve used for our CI\/CD pipeline can also be applied to other technologies. Most of the steps are consistent, with the only variations being the specific maven plugins and commands we employ to build, test, and deploy for each technology.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">If you would like to discuss CI\/CD further and learn how to implement GitHub Actions, then&nbsp;<a href=\"https:\/\/devoteam.info\/uk\/get-in-touch\/\">get in touch<\/a>&nbsp;with one of our experts here.<\/p>\n<\/div>\n<\/main>\n<\/div>\n<\/div>\n<\/div>\n\n\n\n<p class=\"wp-block-paragraph\"><\/p>\n","protected":false},"excerpt":{"rendered":"<p>MuleSoft \u2013 Continuous Integration and Delivery Making technical changes to app or website code at any stage of development can be a tricky business! That\u2019s why effective Continuous Integration and Continuous Delivery (CI\/CD) is essential for successfully building and maintaining any application, website, or piece of software. But what exactly is efficient CI and CD? [&hellip;]<\/p>\n","protected":false},"featured_media":161088,"template":"","categories":[752,761],"tags":[],"industry":[],"class_list":["post-161456","book","type-book","status-publish","has-post-thumbnail","hentry","category-business-platforms","category-mulesoft"],"acf":[],"cards":"\n\t<div class=\"single-post-card\">\n\n\t\t<figure class=\"wp-block-post-featured-image\"><a href=\"https:\/\/devoteam.info\/uk\/ebook\/mulesoft-continuous-integration-and-delivery\/\" target=\"_self\" ><img width=\"1920\" height=\"1280\" src=\"https:\/\/devoteam.info\/wp-content\/uploads\/2024\/11\/MuleSoft-\u2013-Continuous-Integration-and-Delivery.jpg\" class=\"attachment-post-thumbnail size-post-thumbnail wp-post-image\" alt=\"MuleSoft \u2013 Continuous Integration and Delivery\" style=\"aspect-ratio:4\/3;width:100%;object-fit:cover;\" decoding=\"async\" loading=\"lazy\" srcset=\"https:\/\/devoteam.info\/wp-content\/uploads\/2024\/11\/MuleSoft-\u2013-Continuous-Integration-and-Delivery.jpg 1920w, https:\/\/devoteam.info\/wp-content\/uploads\/2024\/11\/MuleSoft-\u2013-Continuous-Integration-and-Delivery-300x200.jpg 300w, https:\/\/devoteam.info\/wp-content\/uploads\/2024\/11\/MuleSoft-\u2013-Continuous-Integration-and-Delivery-1024x683.jpg 1024w, https:\/\/devoteam.info\/wp-content\/uploads\/2024\/11\/MuleSoft-\u2013-Continuous-Integration-and-Delivery-768x512.jpg 768w, https:\/\/devoteam.info\/wp-content\/uploads\/2024\/11\/MuleSoft-\u2013-Continuous-Integration-and-Delivery-1536x1024.jpg 1536w\" sizes=\"auto, (max-width: 1920px) 100vw, 1920px\" \/><\/a><\/figure>\n\n\t\t\n\t\t<div class=\"wp-block-group is-vertical is-layout-flex wp-container-core-group-is-layout-43282307 wp-block-group-is-layout-flex\">\n\t<p style=\"font-style:normal;font-weight:700\" class=\"has-link-color wp-elements-9 wp-block-lp-post-type has-text-color has-primary-color has-small-font-size\">E-book<\/p>\n\n\t\t\n\t\t<h3 style=\"font-style:normal;font-weight:400\" class=\"wp-block-post-title has-base-font-size\"><a href=\"https:\/\/devoteam.info\/uk\/ebook\/mulesoft-continuous-integration-and-delivery\/\" target=\"_self\" >MuleSoft \u2013 Continuous Integration and Delivery<\/a><\/h3><\/div>\n\t\t\n\t<\/div>\n\n","yoast_head":"<!-- This site is optimized with the Yoast SEO Premium plugin v28.4 (Yoast SEO v28.4) - https:\/\/yoast.com\/product\/yoast-seo-premium-wordpress\/ -->\n<title>MuleSoft \u2013 Continuous Integration and Delivery | Devoteam<\/title>\n<meta name=\"robots\" content=\"index, follow, max-snippet:-1, max-image-preview:large, max-video-preview:-1\" \/>\n<link rel=\"canonical\" href=\"https:\/\/devoteam.info\/uk\/ebook\/mulesoft-continuous-integration-and-delivery\/\" \/>\n<meta property=\"og:locale\" content=\"en_GB\" \/>\n<meta property=\"og:type\" content=\"article\" \/>\n<meta property=\"og:title\" content=\"MuleSoft \u2013 Continuous Integration and Delivery\" \/>\n<meta property=\"og:description\" content=\"MuleSoft \u2013 Continuous Integration and Delivery Making technical changes to app or website code at any stage of development can be a tricky business! That\u2019s why effective Continuous Integration and Continuous Delivery (CI\/CD) is essential for successfully building and maintaining any application, website, or piece of software. But what exactly is efficient CI and CD? [&hellip;]\" \/>\n<meta property=\"og:url\" content=\"https:\/\/devoteam.info\/uk\/ebook\/mulesoft-continuous-integration-and-delivery\/\" \/>\n<meta property=\"og:site_name\" content=\"Devoteam\" \/>\n<meta name=\"twitter:card\" content=\"summary_large_image\" \/>\n<meta name=\"twitter:label1\" content=\"Estimated reading time\" \/>\n\t<meta name=\"twitter:data1\" content=\"46 minutes\" \/>\n<script type=\"application\/ld+json\" class=\"yoast-schema-graph\">{\"@context\":\"https:\\\/\\\/schema.org\",\"@graph\":[{\"@type\":\"WebPage\",\"@id\":\"https:\\\/\\\/devoteam.info\\\/uk\\\/ebook\\\/mulesoft-continuous-integration-and-delivery\\\/\",\"url\":\"https:\\\/\\\/devoteam.info\\\/uk\\\/ebook\\\/mulesoft-continuous-integration-and-delivery\\\/\",\"name\":\"MuleSoft \u2013 Continuous Integration and Delivery | Devoteam\",\"isPartOf\":{\"@id\":\"https:\\\/\\\/devoteam.info\\\/uk\\\/#website\"},\"primaryImageOfPage\":{\"@id\":\"https:\\\/\\\/devoteam.info\\\/uk\\\/ebook\\\/mulesoft-continuous-integration-and-delivery\\\/#primaryimage\"},\"image\":{\"@id\":\"https:\\\/\\\/devoteam.info\\\/uk\\\/ebook\\\/mulesoft-continuous-integration-and-delivery\\\/#primaryimage\"},\"thumbnailUrl\":\"https:\\\/\\\/devoteam.info\\\/wp-content\\\/uploads\\\/2024\\\/11\\\/MuleSoft-\u2013-Continuous-Integration-and-Delivery.jpg\",\"datePublished\":\"2023-11-26T13:20:00+00:00\",\"breadcrumb\":{\"@id\":\"https:\\\/\\\/devoteam.info\\\/uk\\\/ebook\\\/mulesoft-continuous-integration-and-delivery\\\/#breadcrumb\"},\"inLanguage\":\"en-GB\",\"potentialAction\":[{\"@type\":\"ReadAction\",\"target\":[\"https:\\\/\\\/devoteam.info\\\/uk\\\/ebook\\\/mulesoft-continuous-integration-and-delivery\\\/\"]}]},{\"@type\":\"ImageObject\",\"inLanguage\":\"en-GB\",\"@id\":\"https:\\\/\\\/devoteam.info\\\/uk\\\/ebook\\\/mulesoft-continuous-integration-and-delivery\\\/#primaryimage\",\"url\":\"https:\\\/\\\/devoteam.info\\\/wp-content\\\/uploads\\\/2024\\\/11\\\/MuleSoft-\u2013-Continuous-Integration-and-Delivery.jpg\",\"contentUrl\":\"https:\\\/\\\/devoteam.info\\\/wp-content\\\/uploads\\\/2024\\\/11\\\/MuleSoft-\u2013-Continuous-Integration-and-Delivery.jpg\",\"width\":1920,\"height\":1280},{\"@type\":\"BreadcrumbList\",\"@id\":\"https:\\\/\\\/devoteam.info\\\/uk\\\/ebook\\\/mulesoft-continuous-integration-and-delivery\\\/#breadcrumb\",\"itemListElement\":[{\"@type\":\"ListItem\",\"position\":1,\"name\":\"Home\",\"item\":\"https:\\\/\\\/devoteam.info\\\/uk\\\/\"},{\"@type\":\"ListItem\",\"position\":2,\"name\":\"E-book\",\"item\":\"https:\\\/\\\/devoteam.info\\\/uk\\\/ebook\\\/\"},{\"@type\":\"ListItem\",\"position\":3,\"name\":\"MuleSoft \u2013 Continuous Integration and Delivery\"}]},{\"@type\":\"WebSite\",\"@id\":\"https:\\\/\\\/devoteam.info\\\/uk\\\/#website\",\"url\":\"https:\\\/\\\/devoteam.info\\\/uk\\\/\",\"name\":\"Devoteam\",\"description\":\"\",\"potentialAction\":[{\"@type\":\"SearchAction\",\"target\":{\"@type\":\"EntryPoint\",\"urlTemplate\":\"https:\\\/\\\/devoteam.info\\\/uk\\\/?s={search_term_string}\"},\"query-input\":{\"@type\":\"PropertyValueSpecification\",\"valueRequired\":true,\"valueName\":\"search_term_string\"}}],\"inLanguage\":\"en-GB\"}]}<\/script>\n<!-- \/ Yoast SEO Premium plugin. -->","yoast_head_json":{"title":"MuleSoft \u2013 Continuous Integration and Delivery | Devoteam","robots":{"index":"index","follow":"follow","max-snippet":"max-snippet:-1","max-image-preview":"max-image-preview:large","max-video-preview":"max-video-preview:-1"},"canonical":"https:\/\/devoteam.info\/uk\/ebook\/mulesoft-continuous-integration-and-delivery\/","og_locale":"en_GB","og_type":"article","og_title":"MuleSoft \u2013 Continuous Integration and Delivery","og_description":"MuleSoft \u2013 Continuous Integration and Delivery Making technical changes to app or website code at any stage of development can be a tricky business! That\u2019s why effective Continuous Integration and Continuous Delivery (CI\/CD) is essential for successfully building and maintaining any application, website, or piece of software. But what exactly is efficient CI and CD? [&hellip;]","og_url":"https:\/\/devoteam.info\/uk\/ebook\/mulesoft-continuous-integration-and-delivery\/","og_site_name":"Devoteam","twitter_card":"summary_large_image","twitter_misc":{"Estimated reading time":"46 minutes"},"schema":{"@context":"https:\/\/schema.org","@graph":[{"@type":"WebPage","@id":"https:\/\/devoteam.info\/uk\/ebook\/mulesoft-continuous-integration-and-delivery\/","url":"https:\/\/devoteam.info\/uk\/ebook\/mulesoft-continuous-integration-and-delivery\/","name":"MuleSoft \u2013 Continuous Integration and Delivery | Devoteam","isPartOf":{"@id":"https:\/\/devoteam.info\/uk\/#website"},"primaryImageOfPage":{"@id":"https:\/\/devoteam.info\/uk\/ebook\/mulesoft-continuous-integration-and-delivery\/#primaryimage"},"image":{"@id":"https:\/\/devoteam.info\/uk\/ebook\/mulesoft-continuous-integration-and-delivery\/#primaryimage"},"thumbnailUrl":"https:\/\/devoteam.info\/wp-content\/uploads\/2024\/11\/MuleSoft-\u2013-Continuous-Integration-and-Delivery.jpg","datePublished":"2023-11-26T13:20:00+00:00","breadcrumb":{"@id":"https:\/\/devoteam.info\/uk\/ebook\/mulesoft-continuous-integration-and-delivery\/#breadcrumb"},"inLanguage":"en-GB","potentialAction":[{"@type":"ReadAction","target":["https:\/\/devoteam.info\/uk\/ebook\/mulesoft-continuous-integration-and-delivery\/"]}]},{"@type":"ImageObject","inLanguage":"en-GB","@id":"https:\/\/devoteam.info\/uk\/ebook\/mulesoft-continuous-integration-and-delivery\/#primaryimage","url":"https:\/\/devoteam.info\/wp-content\/uploads\/2024\/11\/MuleSoft-\u2013-Continuous-Integration-and-Delivery.jpg","contentUrl":"https:\/\/devoteam.info\/wp-content\/uploads\/2024\/11\/MuleSoft-\u2013-Continuous-Integration-and-Delivery.jpg","width":1920,"height":1280},{"@type":"BreadcrumbList","@id":"https:\/\/devoteam.info\/uk\/ebook\/mulesoft-continuous-integration-and-delivery\/#breadcrumb","itemListElement":[{"@type":"ListItem","position":1,"name":"Home","item":"https:\/\/devoteam.info\/uk\/"},{"@type":"ListItem","position":2,"name":"E-book","item":"https:\/\/devoteam.info\/uk\/ebook\/"},{"@type":"ListItem","position":3,"name":"MuleSoft \u2013 Continuous Integration and Delivery"}]},{"@type":"WebSite","@id":"https:\/\/devoteam.info\/uk\/#website","url":"https:\/\/devoteam.info\/uk\/","name":"Devoteam","description":"","potentialAction":[{"@type":"SearchAction","target":{"@type":"EntryPoint","urlTemplate":"https:\/\/devoteam.info\/uk\/?s={search_term_string}"},"query-input":{"@type":"PropertyValueSpecification","valueRequired":true,"valueName":"search_term_string"}}],"inLanguage":"en-GB"}]}},"uagb_featured_image_src":{"full":["https:\/\/devoteam.info\/wp-content\/uploads\/2024\/11\/MuleSoft-\u2013-Continuous-Integration-and-Delivery.jpg",1920,1280,false],"thumbnail":["https:\/\/devoteam.info\/wp-content\/uploads\/2024\/11\/MuleSoft-\u2013-Continuous-Integration-and-Delivery-150x150.jpg",150,150,true],"medium":["https:\/\/devoteam.info\/wp-content\/uploads\/2024\/11\/MuleSoft-\u2013-Continuous-Integration-and-Delivery-300x200.jpg",300,200,true],"medium_large":["https:\/\/devoteam.info\/wp-content\/uploads\/2024\/11\/MuleSoft-\u2013-Continuous-Integration-and-Delivery-768x512.jpg",768,512,true],"large":["https:\/\/devoteam.info\/wp-content\/uploads\/2024\/11\/MuleSoft-\u2013-Continuous-Integration-and-Delivery-1024x683.jpg",1024,683,true],"1536x1536":["https:\/\/devoteam.info\/wp-content\/uploads\/2024\/11\/MuleSoft-\u2013-Continuous-Integration-and-Delivery-1536x1024.jpg",1536,1024,true],"2048x2048":["https:\/\/devoteam.info\/wp-content\/uploads\/2024\/11\/MuleSoft-\u2013-Continuous-Integration-and-Delivery.jpg",1920,1280,false]},"uagb_author_info":{"display_name":"Julien Pawlowski","author_link":"https:\/\/devoteam.info\/uk\/author\/"},"uagb_comment_info":0,"uagb_excerpt":"MuleSoft \u2013 Continuous Integration and Delivery Making technical changes to app or website code at any stage of development can be a tricky business! That\u2019s why effective Continuous Integration and Continuous Delivery (CI\/CD) is essential for successfully building and maintaining any application, website, or piece of software. But what exactly is efficient CI and CD?&hellip;","_links":{"self":[{"href":"https:\/\/devoteam.info\/uk\/wp-json\/wp\/v2\/book\/161456","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/devoteam.info\/uk\/wp-json\/wp\/v2\/book"}],"about":[{"href":"https:\/\/devoteam.info\/uk\/wp-json\/wp\/v2\/types\/book"}],"version-history":[{"count":0,"href":"https:\/\/devoteam.info\/uk\/wp-json\/wp\/v2\/book\/161456\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/devoteam.info\/uk\/wp-json\/wp\/v2\/media\/161088"}],"wp:attachment":[{"href":"https:\/\/devoteam.info\/uk\/wp-json\/wp\/v2\/media?parent=161456"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/devoteam.info\/uk\/wp-json\/wp\/v2\/categories?post=161456"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/devoteam.info\/uk\/wp-json\/wp\/v2\/tags?post=161456"},{"taxonomy":"industry","embeddable":true,"href":"https:\/\/devoteam.info\/uk\/wp-json\/wp\/v2\/industry?post=161456"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}