Search code examples
version-controlcontinuous-integrationazure-devopsbranching-and-mergingms-release-management

VSTS: Branch and Merge Best approach for Development - QA - Production

I am using VSTS for Source Control, CI and Release Management I am trying to build code only once and not per environment or branch. The release pipeline is: Dev -> QA -> PROD

I have only One Branch or codbase where the team commit the changes. The CI triggers a Build when all the code for a fix is ready. I create a release and promote it through the pipeline until deploying it in the Production.

I need to know if the one Branch will be fine for us, so if we are going to fix some bugs or create a new feature with just create a sub branch and commit the code daily to the Master Branch.

I am trying to avoid using 3 branches one for each environment. I think that CI and Release Management provide us with ability to create releases from previous builds.

So, What is Cons and Pros of both approaches (3 branches or Only One Master Branch) in my case?

Solution

  • Usually, there should be only one branch for one release pipeline. You may have several environments in one pipeline, but the release deployed to them should be the same since the release pipeline reflects a process that how your software been final released after build. For example, the release is deployed to QA environment first for testing and can be only deployed to production server after the testing on QA environment is passed. It does not make sense that QA use the build of one branch and Prod use the build of another branch. You can refer to this link for details: Where to deploy? Environments in Microsoft Release Management.

    And for branch, it is about your development process. Here are some suggestions from MSDN for your reference:

    When should the team add a branch?

    You should create branches in the following situations:

    • When you must release code on a different schedule/cycle than the existing branches.

    • When your code requires a different branch policy. If you create a new branch that has the new policy, you can add strategic value to your project.

    • When functionality is released to a customer and your team plans to make changes that do not affect the planned release cycle.

    You should not create a branching for each user story because it creates a high integration cost. Although Team Foundation Server makes branching easy, the overhead of managing branches can become significant if you have many branches.

    Check this link for details: Branch strategically