0

I'm currently using Team Foundation Server 2015 (Update 2) and wanting to use the new build definitions and release management and wondering what the best practice is around creating build definitions when using multiple branches.

We have multiple branches and there will also be multiple solutions in each branch (for this example i'll call them WinApp.sln, WebApp.sln & MobileApp.sln).

Our project branches are something like the following...

Project
    Dev
        Main    *** This is our development branch for new features
        Updates
            1.2 *** This branch is used for any bug fixes for version 1.2
    Main
    Releases
        1.1
        1.2     *** Current release branch that will be deployed to customers

Using the new build definitions in TFS 2015 is it best to create a new build definition for each of the branches or each of the applications in each branch.

For example I create the following build definitions:

AppName.Dev.WinApp
AppName.Dev.WebApp
AppName.Dev.MobileApp
AppName.Updates.1.2.WinApp
AppName.Updates.1.2.WebApp
AppName.Updates.1.2.MobileApp
AppName.Release.1.2.WinApp
AppName.Release.1.2.WebApp
AppName.Release.1.2.MobileApp

And then that would flow through to the release management by having release definitions like the following:

AppName.Dev         
AppName.Updates.1.2
AppName.Release.1.2

Each release definition will have artifacts added for each of the 3 solution builds.

Or would it be better to just have 1 build definition for each branch?

Would be interesting to know what other people are doing in similar situations.

Craig F
  • 165
  • 2
  • 10
  • Do each of the applications build independently? i.e. Would it make sense to build WinApp and WebApp together? – m00nbeam360.0 Apr 12 '16 at 05:23
  • The apps share common dll's. So usually all the apps will be rebuilt when a new version is released. But there will be cases where a bug in a particular app is fixed and just the one app needs updated. – Craig F Apr 12 '16 at 11:36

1 Answers1

0

Previously with the xaml based builds, we had multiple build deifnitions because whenever we released a new build template, we did not want the older release build definitions impacted, hence we maintained multiple build definitions. We also maintained that for the sake of the version the build gets.

But, with the new vNext builds in place there is no way we can have a previous version of a task available to use once we enhance a task and upload it to the TFS all build definitions start using the latest task and there is no way(other than renaming a task) by which we can select a task of older version. So, I think it would be of no use to maintain multiple build definitions, as the build definitions are going to get updated if a task is updated.

There is a case where we require to maintain a version for a specific release and if the number depends on the builds triggered, in that case we'll have maitain different build definitions becuase our patches cannot have the latest version number.

One more reason to maintain different build definition is to escape from the headache of remembering what tasks were used in a specific release previously.

So all in all I'll go with different build definitions to avoid versioning chaos and to maitain integrity of a release build definition.

When it comes to release,we bind a build definition to a release definition. So, again to have a smooth bug fix and update, different release definition for each build definition has to be present.

Dhruv Patel
  • 305
  • 4
  • 11