Decide on a branching strategy, and branch the code.
This assumes you already have a TFS build set up on your “main” branch

Once the branch is complete, it should be something like:

Branched to:

Then, clone the TFS build definition you currently use for Dev (or whatever your main branch is)
I used TFS Community Build Manager, which speeds this up
This is to change the source control folders to point to our branch:


next, change the MSBuild arguments Octopack command – altering the output path to specific for this branch

Something like:

This will cause Octopack to place our nuget packages (from the build output for this project / solution) in a specific folder
This will be important when configuring Octopus, later.

Octopus Configuration

Here’s the trick – since Octopus doesn’t yet support branching, what I had to do is create a new External Feed library, and point it to the location we set in our previous step, where we edited the Octopack build argument.
So, I create an external feed called “ProjectName – BranchName”, pointing to \\server\\projectname\\BranchName

Next, clone your original deployment project
This can be done in Settings -> Clone
I appended my branch name to my newly cloned project, to make it obvious which one is which.

Back in the Process, I change all my deployment steps to point to my Nuget feed I created in the above step.
This will make sure the deployment step for this project, looks in the location set in the build definition for this branch, for its packages to delpoy.

I make any changes to the deployment proecess needed for this branch (new features, services deployed etc…)

So, to summarise the steps:

  1. Create branch in TFS
  2. Create branch specific build definition
  3. Create branch specific drop location for Octopack
  4. Create branch specific Octopus Deployment Project (by cloning your ‘main’ deployment
  5. Edit the newly cloned deployment, re-point the nuget feed location to your branch specific output location, created in step 3

As part of my effort to allow us to use branches with Octopus deployment, I needed to be able to duplicate our TFS build definitions.
I would then create a branch-specific build definition, called something like MyProject – Branch123

I wanted to set things like a custom drop folder for the branch, and, since we’re using Octopus, set the OctoPackPublishPackageToFileShare folder, specific to this branch.

For example, in our “master” branch, we may have this in the MSBuild Arguments of the build process:

However, for this branch specific build definition, I needed it to be

I came across Community TFS Build Manager, which is a handy Visual Studio Extension.
It installs, and then is available in the Tools menu:


Once open, you can right click on a build definition, and easily Clone:


Then, select the branch you want to create the build definition clone for.

Coming from using Git, I am used to using a stash in this scenario:

Working on a piece of functionality
High priority change comes in on the branch I’m working on that would affect the above work

In this instance, I would tend to stash my changes.

After googling, I discovered the TFS equivalent is Shelving.

So, I shelved my changes, and was horrified to see them still in existence in my source tree…
I’d forgotten to untick the “Preserve pending changes locally” checkbox:

Preserve pending changes locally checkbox

So from here, I have two options:


Shelve the changes again, making sure I untick “Preserve pending changes locally”
Delete the previous shelveset


Simply undo pending changes on the files included in the first shelveset.

GUI Bug on TFS Shelve changes screen

When resizing the screen, you would also expect to see the file list to resize with it?


Apparently not….