Implementing CI/CD with GitFlow in VSTS

With a few tweaks we can enable the use of GitFlow in our Continuous Integration (CI) and Continuous Deployment (CD) pipelines in Visual Studio Team Services (VSTS).


GitFlow a branching strategy. You can read all about it here.

We are only interested in the develop and release branches

From a CI/CD point of view, we only want to build and deploy the develop and release branches respectively.

The develop branch should be sent to a dev and/or test environments. The release branch ends up in production.

Setting up the Build (Continuous Integration)

To start, get the build working for whatever language / project type you have. In my case I have a Vue app, which looks like this.


The real fun is in the Triggers tab.

  • Click the Triggers tab
  • Enable the checkbox for Continuous Integration
  • In the Branch Filters include release and develop

What this means is we’ll kick off a build if we get a commit to either branch but commits to any other branch will be ignored.

Once done it should look like this:


Setting up the Release (Continuous Deployment)

I’m going to assume I have only two environments, to keep it simple: a dev/test area and production.

  • Create a new, blank release
  • Selected my Wolf Tracker-CI as the artifact
  • Clicked the thunder bolt in the top-right to open the Continuous deployment trigger pane
  • Set the checkbox to Enabled
  • In the Build branch filters create two rows, selecting release and develop


At this point rename the current environment to Dev/Test. click the little thunderbolt / person icon to the left of the environment to bring up the Pre-deployment conditions.

  • Enable Artifact filters
  • Select the develop branch.
    • This means this environment will only use builds that originated from the develop branch.
  • Make sure the trigger is set to After release


Within the environment set whatever tasks you like. Mine are relatively mundane: just copying files.

Now we need to create the Production environment:

  • I started by clicking Clone on the Dev/Test environment.
    • You can click + Add instead.
    • Don’t worry if it appears to the right of (after) the Dev/Test environment
  • Click the Pre-deployment conditions icon as before, to open the pane
  • Click the After release trigger
  • Similar to before, enable the Artifact filters but this time select the release branch

Optional: I’m a bit paranoid about deploying to production so I enabled the Pre-deployment approvers and set myself. This means VSTS will wait until I explictly provide approval before it proceeds with the deployment.



Once you start using it, under the releases tab will look something like this. The release will either go to one of the two environments.

Have noticed how, in the second-to-last row, that there is a little person icon? That means it’s awaiting approval.

2017-12-01_8-03-03.png If you found this post useful let me know in the comments! 🙂


  1. Nice article. My question is how this works. Your build is building from MASTER and results in an artifact used by the Release. That can’t be the intention since you want an artifact from release or develop.


    1. Good question. It is confusing when you first setup the build as you need to explictly choose a branch (the second picture) but if you enable Continuous Integration and then specify what branches it can trigger from (third picture), then it will use those branches. I just tested this again to confirm and it’s all good 🙂


  2. Hi Ben,
    I can’t understand a thing: with GitFlow, there are multiple release branches, one per release (release/1.0.0, release/1.0.1, etc…), but in this guide you assume there is only one release branch. So, I think there’s the need to modify build and release definitions every time a new release branch is created.

    How did you manage this?


    1. You’re right. My blog post did assume a single release branch, which isn’t right. There is a simple fix for this. In the Artifacts filter section, where I selected “release”, you can enter “release/*”


      1. Thanks, Ben,
        great! I verified we can use wildcards also in the branches filter of the build definition (for CI).

        This could work well with only one release deployed at time. I’m not sure this will be the only case using GitFlow, what do you think about it?


      2. What I described in my post would work well for only release but it’s also very simple. Works fine for my side project but at work there’s no way I’d want it going straight into production. We create release branches ahead of time, we have release branches per team, etc.

        What I would suggest, at a minimum, is enabling the feature to require manual approvals for that release step to kick off. Let everything build and deploy to automatically to some environments (i.e. dev). For production and test environments, there should be some control gates. Simpliest way to do that is, in the release pipeline, to enable Pre-deployment approvals.


  3. Hi Ben, looks like you are deploying to prod straight from RELEASE, I thought that with github flow you suppose to merge from RELEASE to MASTER ,tag it and deploy from MASTER when needed. Is the MASTER is used at all in your flow ?
    Thanks Lukasz


    1. This blog post is old but I guess the key thing is that you choose you strategy and the above shows you how you could do it. You could deploy from release straight to master or merge your release into master and then deploy that. Up to you 🙂

      Personally I’d rather deploy from master as master should always be what is in production. Only time I’d deploy a release branch nowdays is to test it in a test environment.


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: