Git Flow w/ VSTS Build Pipelines

continuous integrationcontinuous-deliverygitflow

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?

Best Answer

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

Related Topic