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.
- do work, & raise PR for
newFeature. Once approved & automated build runs,
newFeatureis merged in to
- 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
develop, perhaps cherry pick things too..
release-xis then build then deployed to UAT.
- issues / defects are prioritised and resolved.. some go on backlog, some are made directly to
- once all ready
release-xis merged to
masterbranch, 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-xnot 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?