6

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

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

  1. Where / when should take a release branch?

    • when a dev build is done?
    • following an ok'ed test build?
    • something else?

  2. 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?

Improve this question
2
  • 1
    To be honest neither your process nor gitflow has to do anything with continuous deployment, sorry
    – Arne Burmeister
    Sep 4, 2018 at 15:31
  • 1
    @ArneBurmeister thank you for your helpful response :rolleyes:
    – m1nkeh
    Sep 4, 2018 at 16:41

1 Answer 1

Reset to default
0

Your life will be easier if you only build from persistent branches. ie develop and master.

You are already doing this with your dev builds, if you follow gitflow you should build from the master branch after merging the release branch. Not the release branch pre merge.

Subsequent changes to the release are done on hotfix branches and again built on master once the hotfix has been merged in.

I would further advise not pushing your dev build further than the dev environment. All proper testing should be done against the same binaries that will be released. Not the same source code.

So I would go

  • finish feature, merge to develop
  • build develop and deploy to DEV env.
  • run dev testing of new features in DEV environment until you are happy that they are complete, all automated tests pass
  • finish more features....
  • create release branch, if required
  • do final changes for release, set version, add docs etc
  • merge release into master
  • build master and push to TEST
  • test release
  • bug fixes in hotfix branches, build from master
  • push the same build to UAT once you have passed test
  • perform UAT, bug fixes in hotfix branches
  • push same build to live

Now obviously the downside of this is if you normally find lots of bugs during testing, your master branch has lots of 'bad' commits

The upside is you test the exact version of the software you deploy.

If you have lots of automated tests and they all pass in DEV then you shouldn't get any bugs in master.

If you are doing manual testing, then you are probably better off pushing the DEV build to TEST and doing your bug fixes as feature branches

Improve this answer
3
  • thanks for the response.. the thing that i take issue with is going from master to the test env. i don't like the smell of that, but will think on it. What i really want to achieve is a balance between the flexibility of gitflow (or similar) but also ensure that we carefully control the builds that get released to each env.. starting to think they may be incompatible(!) :/
    – m1nkeh
    Sep 5, 2018 at 8:18
  • 2
    I think the main question is 'which version(s) do you want to test?' and how many cycles of testing you want to do. You can build and deploy any branch you want, but If you don't test the exact version you are deploying, then there is scope for bugs to be introduced.
    – Ewan
    Sep 5, 2018 at 9:49
  • yeah, good point! Ok, so our QA team want to test the build that is produced from each development pr commit, and one signed off we really want that same build to go to uat for users to test, key part being 'same build'. Obviously as soon as you branch (for release-x) this snaps, and the branch can't have the same build # crucially though, as soon as you merge anything in to master you get a new build again - which is making me thinking my aim is actually not achievable - perhaps should simplify the approach..
    – m1nkeh
    Sep 5, 2018 at 14:26

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.