DevoteamInsightsMuleSoft CI/CD – Part I – Git Branching Strategy 

MuleSoft CI/CD – Part I – Git Branching Strategy 

Author

  • Pavan Nagineni
    MuleSoft Developer

Share

Introduction

Continuous Integration and Continuous Delivery/Deployment is commonly called CI/CD – a standard software build and delivery practice.

Most MuleSoft CI/CD blogs only talk about how to compile/ build/ test/ deploy your MuleSoft applications to any of the runtimes, and that’s all. It’s 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. 

So, I have developed this series of three blogs discussing the following concepts.

What is CI/CD & Git Branching Strategy? 

  • What is CI/CD
  • Branching strategies and best practices.

Continuous Integration

  • The CI tasks of CI/CD, compile/ test/ build/ development environment deployment. 
  • An example of CI in action with the help of an API in GitHub Actions. 

Continuous Delivery/Deployment

  • Achieving CD, the SIT/ environment deployments. 
  • How to release an application with the correct versioning and tagging by using maven on PR merges to a certain integration branch. 
  • See a plan to deploy the released tags to UAT/Production deployments. 

This blog is Part I of the series in which we are going to discuss the concepts below: 

  • What is CI/CD? 
  • Git Branching Strategy and Best Practices 

1. What is CI/CD? 

  • The “CI” in CI/CD refers to Continuous Integration, an automation process for developers to continuously build the application for any changes. 
  • Successful CI means new code changes to an app are regularly tested, built, and merged into a shared repository.
  • The “CD” in CI/CD refers to Continuous Delivery/Deployment, related concepts that sometimes get used interchangeably. 
  • Continuous Delivery usually means a developer’s 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. 
  • The most common tasks of CI/CD that organisations follow would look like below: 

2. Git Branching Strategy and Best Practices 

Distributed versioning control systems like Git/Atlassian Bitbucket/Azure Repos give you the flexibility of version controlling your source code and consistently sharing the code with your team. 

Branching strategies are patterns or approaches that technology teams use to organise & manage their source code through different branches in a version control system. 

Below are the different branching strategies that we can use: 

  1. Trunk-based branching strategy
  2. GitHub Flow/Feature branching strategy
  3. Personal branching strategy
  4. GitFlow branching strategy
  5. GitLab Flow branching strategy
  6. Custom Release branching strategy (that I have used in the past)

Trunk-based branching strategy: 

  • A trunk-based branching strategy encourages developers to make minor updates to the master branch frequently.
  • Developers are going to work with short-lived branches.
  • Advantages:
    • This reduces the merge conflicts and challenges that developers face in other branching strategies.
  • Disadvantages:
    • 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.
    • 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.

GitHub Flow/Feature branching strategy: 

  • Every feature gets its branch from the master branch.
  • Once we finish our changes, we will merge the changes to the master branch using pull requests.
  • Teams of any size can adopt this strategy after they’ve familiarised themselves with Git and used this centralised workflow. 
  • Advantages:
    • This is a relatively simple branching workflow to follow. 
    • Hardly any branching management is needed than clearing up feature branches once they are released. 
  • Disadvantages:
    • This requires some solid automation testing framework to ensure the features/bugs we release to the master branch are well tested. 
    • This strategy is unable to support multiple versions of the code in Production at the same time. 

Personal branching strategy: 

  • This will be similar to feature branching, except it does not have a separate branch for per feature, but per developer.
  • This can work if people are working on different bugs/features.
  • Advantages:
    • 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.
    • Branch management is easier since only a few branches are involved.
  • Disadvantages:
    • It is hard for two developers to work on the same feature.
    • 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.
    • This strategy is unable to support multiple versions of the code in Production at the same time. 

GitFlow branching strategy: 

  • Gitflow is a branching model for Git, created by Vincent Driessen. It has attracted much attention because it is very well suited to collaboration and scaling the development team.
  • Branching workflow: 
    • New developments (new features, non-emergency bug fixes) are built-in feature branches.
    • 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.
    • When it is time to make a release, a release branch is created off the develop branch.
    • 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 -> test -> fix -> redeploy -> retest cycle continues until you’re happy that the release is good enough to release to customers.
    • 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’t accidentally lost by new development.
    • Hotfix branches are used to create emergency fixes.
    • 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’t accidentally lost when the next regular release occurs.
  • Advantages:
    • Parallel Development
    • Collaboration
    • Release Staging Area
    • Support For Emergency Fixes
  • Disadvantages:
    • 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.
    • 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.

(Image from: GitFlow branching Explanation)

GitLab Flow branching strategy: 

  • 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’s standards. 
  • Let’s take the below branching workflow to explain how this flow works:
    • feature/*** – feature branch 
    • master – master branch 
    • PROD – production branch 
    • Hotfix- hotfix branch 
  • Branching workflow: 
    • New developments (new features, non-emergency bug fixes) are built-in feature branches.
    • 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.
    • When it is time to make a release, the master branch source code will be merged into the PROD branch. 
    • PROD branch serves here as the source of truth for Production deployment-ready code. 
    • Hotfix branches are used to create emergency fixes.
    • 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’t accidentally lost when the next regular release occurs.
  • Advantages:
    • Comparing this to the GitFlow strategy, this is more simple. 
    • This also has the same benefits as the GitFlow strategy regarding Parallel Development, Collaboration, and support for Emergency fixes.  
  • Disadvantages:
    • 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. 

Custom Release branching strategy (that I have used in the past): 

  • In this Custom-release branching strategy, we had the following branches:
    • master – production code
    • qa – release branch
    • develop – integration branch
    • feature/**** – feature branches
  • Branching workflow: 
    • The developers first check the code from the develop branch to work on any features/bugs
    • Once the developer completes the changes, They will push the code to his feature branch – which will compile/test/build the source code and deploy the change to the Dev environment.
    • 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.
    • The testers do the integration end-to-end tests –
      • If they find any issues:
        • The developer will make the changes in the same feature branch.
        • Once the change is deployed to the Dev environment (on push to his feature branch), they must raise a PR to the develop branch.
      • Note: here, it is the developer’s responsibility to check and pull any changes in the develop branch made by anyone else within this time:
        • Once the additional changes have been merged to the develop branch, the difference will automatically deploy to the Sit environment.
        • 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.
      • If none, the feature will get sign-off to higher environments.
    • To promote the change to higher environments (Uat/PreProd) –
      • The Developer raises a PR from the develop branch to the QA branch.
      • The PR will get merged once the team members review it.
      • As soon as this merges into the QA branch, the release must happen for the API/application, and the git tag will be created.
    • At the time of the deployment to Production, the git version will be merged to the master branch, which will be production-based code.
  • Advantages:
    • This also has the same benefits as the GitFlow strategy in terms of Parallel Development, Collaboration, and support for Emergency fixes.  
    • Since this strategy does not have the release and environmental branches, it is easy for team members to track the changes.  Also, it is simple for teams to educate any new team members. 
  • Disadvantages:
    • 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. 
    • This also has four branches to track the changes. 
  • Note: 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 (Sit deployment) gives more robustness to the releases that we are doing on this branch. 

Conclusion: 

CI/CD is a key tool in today’s software development world. It helps making and sharing software more efficient. While many articles discuss the basic steps like building and testing software, there’s 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.

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.

Git, helps teams manage their software projects. Instead of mixing all the code, Git uses “branches” 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’ve used before, which combines elements from other strategies.

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. 

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.

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.

References: