TeamCity best practice setup for multiple branches

Question

I'm looking for advice on the best approach to setup TeamCity/Octopus.

Currently I have multiple branches in TFS2015 - dev, main and release (currently we create a release branch for each release).

Our procedure is to develop in dev and deploy to dev environment. When we are ready for testing we merge from dev to main and deploy to test from main. When happy we create a release branch and deploy to live from the release branch. This is a manual process.

Hotfixes are done on the release branch and deployed to live. We then merge back to main/dev.

I'm totally new to this and so far in a VM playground I've setup TFS2015, TeamCity and Octopus and can check-in to TFS, build/create package on TeamCity and deploy this pack from Octopus. But...

1. I'm unsure how I should setup TeamCity and Octopus to work with multiple branches? Multiple projects for each branch and generate different artifacts?

2. When I do this for real I have a TFS VM, I plan on installing TeamCity and Octopus on this along with the build agent. Is this a bad idea? Should I create a new VM just for TM and Octopus?

Any advice or best practice would be appreciated.

Answer 1

Although your question is good in scope, but a good answer must cover many details to be complete.

Let me try to point out the main areas that you will need to further investigate and configure.

TeamCity

A VCS root can be configured to listen to multiple branches via a branch specification

A VCS root can contain multiple projects/solutions and these can be built in multiple steps within TeamCity.

Given that Team City does not support conditional build steps, you will need a different strategy to allow you to vary build steps (and parameters) per release channels / environments.

My recommend approach is to split up the builds into a build definition per release channel (target environment).

• Dev and Feature branches could share a single build definition.
• Master and Hotfix branches can share a single build definition since they both publish to staging/production environments.
• Release branches will need a separate build definition and publish to QA/Testing environment.

This gives you fine grained control over parameter and configurations of each release channel. build a debug version of your app from Dev branch for example at major version 3, while build a release version from Master branch with major version 2.

Every build definition will have a step to publish its artefacts/packages to Octopus Deploy, and specify the channel of which the artifacts belong to.

Octopus Deploy

In Octopus Deploy, define the channels to reflect the release channels, that also reflect your branching model.

Develop, Test, Release are my standard goto channels

Each channel can enforce a different Lifecycle to limit the environments that a channel can deploy to and how an application progresses through your overall ALM cycle.

I know this is not a complete answer. but it is a good start that I hope can help you refine your question to more specific technical details.

Answer 2

We're having somewhat similar CI setup requirements except TFS. In our case workflow for most projects is: GitHub -> TeamCity -> Octopus Deploy.

1. So I'm not sure about multi-branch setup with TFS, but in case with GitHub repos it's pretty easy to configure in TeamCity. You just have to specify branch-related settings in your VCS root (see Branch configuration). When you have configured that, TeamCity will let you run build's for every specified branch separately and will display build statuses for every branch nicely.

In Octopus we use Channels feature to split workflows of releases coming from different branches. That means we have channel-per-branch convention for the projects, so that TeamCity is pushing packaged releases from particular branch (in our case it's develop and master) into it's respective channel in Octopus (see Channels in Octopus).

2. Probably you can setup all the services on single machine but imho it's not the best practice to do performance-wise and scalability-wise.

Answer 3

Off course I don't know you code etc but I think you should step away from merging from dev to test and then creating a version from test. That way you essentially are building a different application compared to the one you were having on dev. Once you merge from test to production and build your application from there, you are releasing a build you haven't been testing.

You should strive for a flow in which you build once and deploy multiple times. So, build one package which you promote from dev to test to production.

Off course you can have a production branch on which you could fix bugs etc. The Channels feature in Octopus works great for scenario's like that.