Git Flow w/ VSTS Build Pipelines

I am trying to marry the git flow approach (w/ dev, test, uat, staging, prod env) & automated build and releases in Visual Studio Team System (VSTS). Slightly struggling due to VSTS needing a persistent branch to 'anchor' builds on - I am curious what other people do. Our Approach branch newFeature from develop branch. do work, & raise PR for newFeature. Once approved & automated build runs, newFeature is merged in to develop and deleted. This build, is then deployed to development environment, and sense checked. Same [unchanged] build can then be deployed to the test environment, and QA'ed. When testers are happy, release is prepared for UAT. We create a brand new release-x branch from develop, perhaps cherry pick things too.. release-x is then build then deployed to UAT. issues / defects are prioritised and resolved.. some go on backlog, some are made directly to release-x is critical. once all ready release-x is merged to master branch, which triggers a new, 3rd build.. that build is deployed to staging env for final customer checks when all ok, same build is also deployed to production So, to achieve this, we have a couple of build/release pipelines: dev/test - this takes the build produced on feature completion, and makes that same build avail for test staging/prod - this takes the build produced once a release is merge into master, and can also push it to prod don't have anything automated for UAT due to release-x not being permanent The overall question I have here really two-fold: Where / when should take a release branch? when a dev build is done? following an ok'ed test build? something else? How best to avoid the 3 builds that we currently have? :| I think I would like to do the former... but I'm not sure how VSTS CICD can accommodate?

Apr 6, 2025 - 07:31

I am trying to marry the git flow approach (w/ dev, test, uat, staging, prod env) & automated build and releases in Visual Studio Team System (VSTS). Slightly struggling due to VSTS needing a persistent branch to 'anchor' builds on - I am curious what other people do.

Our Approach

branch newFeature from develop branch.
do work, & raise PR for newFeature. Once approved & automated build runs, newFeature is merged in to develop and deleted.
This build, is then deployed to development environment, and sense checked.
Same [unchanged] build can then be deployed to the test environment, and QA'ed.
When testers are happy, release is prepared for UAT. We create a brand new release-x branch from develop, perhaps cherry pick things too..
release-x is then build then deployed to UAT.
issues / defects are prioritised and resolved.. some go on backlog, some are made directly to release-x is critical.
once all ready release-x is merged to master branch, which triggers a new, 3rd build..
that build is deployed to staging env for final customer checks
when all ok, same build is also deployed to production

So, to achieve this, we have a couple of build/release pipelines:

dev/test - this takes the build produced on feature completion, and makes that same build avail for test
staging/prod - this takes the build produced once a release is merge into master, and can also push it to prod
don't have anything automated for UAT due to release-x not being permanent

The overall question I have here really two-fold:

Where / when should take a release branch?
- when a dev build is done?
- following an ok'ed test build?
- something else?
How best to avoid the 3 builds that we currently have? :|

I think I would like to do the former... but I'm not sure how VSTS CICD can accommodate?