We are trying get our CI/CD up and running and I was after some feedback on it.

We are using VSTS and building c# api + JavaScript applications.

We want to use VSTS build and Release management. The release management uses the idea of 'promotion' of the same build through the various environments.

Our process

  1. We tend to use feature branches, which are then merged back into develop when good enough. Then our CI, picks up changes to the develop branch, triggers a build and the created artifacts are used for release.
  2. The build happens on our premises build server, using a build agent looking at VSTS.
  3. It is tested etc as it gets promoted through the environments, assuming tests etc pass.
  4. Then when it was final approved to make it to production (by approval), we want it to update source control by merging into master + tag with the version that was deployed to production. So this means that the git merge is handled by a step late on in the release management.

Firstly, is this a decent setup for our start to CI/CD? Any suggestions to improve it? In particular the way the source control part is, but we want to make any aspect of it better.

Should we be merging to master earlier, and then only building our CI/CD from that? And use tags or something to denote releases which made it to production?


Note: Couldn't find a tag for VSTS.

  • If you're using Git, there's little sense in maintaining a dev and master branch. Tags are branches.
    – RubberDuck
    May 15, 2017 at 15:10
  • 1
    @RubberDuck: Are you not confusing Git and SVN? To my knowledge of Git, tags are just labels that have been put on a particular commit. In SVN, tags are actually branches. May 16, 2017 at 6:38
  • @BartvanIngenSchenau in Git, branches are just labels too. Everything is a refspec.
    – RubberDuck
    May 16, 2017 at 9:40
  • In git branches are mobile labels. Tags are labels that tend to stay attached to the same thing permanently.
    – bdsl
    Jun 6, 2017 at 23:22

1 Answer 1


A prerequisite for continuous deployment / delivery is continuous integration - i.e. the whole team merging changes onto a single centralized branch multiple times per day. It looks like this is exactly what you are doing on the develop branch, so the thing that looks odd to me is what is the point of the master branch? The thing that it seems to be doing is:

  • keeping track of what's in production (which you can do with tags)
  • you can branch from master if you need to hotfix production (in git you can branch from any commit / tag)

What you have described of your deploy / test process looks good, so I'd just rename develop to master and delete master.

Your Answer

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

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