Feature Branch plan and Automated Builds

Feb 26, 2013 at 8:17 PM
After studying the branching guide, I've come to the conclusion that the Feature Branch plan would work the best for our team.

I'd like to make this as easy as possible for the devs on my team, so I'm looking for a way to set up a build definition that will build and deploy our web app to a test location for the currently open solution. I seem to be stuck because the build definition requires a solution file in "Projects to Build", and this would be changing for every branch.

Is there any way to configure the build process to build the currently open solution?
Feb 26, 2013 at 9:00 PM
You will want a separate team build definition per branch there, and they may all use the same build process template that does the workflow you describe. I think there is some confusion here as you are not really interested in building a solution that is open on a developer's machine, but rather what is stored in version control (your real "version of the truth").

I think we are headed down the wrong path to worry about what solution is open on a devs machine, etc.
Feb 27, 2013 at 2:15 AM
I'm confused. Spivonious, how many people are on your team? And what do you mean by "currently open solution?"
Feb 27, 2013 at 1:06 PM
Edited Feb 27, 2013 at 1:12 PM
I was hoping to not have to make two new build definitions for each branch, as these branches can and will be very temporary (sometimes only lasting a few days).

Ideally ,our workflow would go like this:
  1. dev team 1 makes a new branch from main and begins work on their feature.
  2. dev team 2 makes a new branch from main and begins work on their feature.
  3. dev team 2 finishes and is ready for testing. They build their branch to a test environment.
  4. dev team 2 testing passes, changes checked into main, main is built to production.
  5. dev team 1 merges main into their branch to get dev team 2's changes.
  6. dev team 1 ready for testing, build their branch to test enviroment.
  7. dev team 1 testing passes, changes checked into main, main is built to production.
I would absolutely love to have a build definition that both dev team 1 and dev team 2 could use to put their branch into a test environment. Something where the teams could choose the solution to build (from source control, not locally) at the time the build is queued. Is this possible without developing a custom add-in?

Oh, and our entire department is six devs, one designer, and two report writers. We have a couple of large projects that routinely have independent changes going on concurrently.
Feb 27, 2013 at 6:43 PM
I'm starting to think that having a build definition on a feature branch isn't worth anything. Test builds can happen from Main, and another branch can be added to handle releases. Main builds to test on check-in and Release builds to prod on check-in. Devs can setup build definitions to Dev if they want to, but it wouldn't be required. If we find that we really need that build to Dev, we could always add another branch in between Main and the features.

Anything I'm missing?
Feb 27, 2013 at 8:05 PM
It depends what your quality bar is for the main branch. If, as in most cases, it contains the latest stable "version of the truth" you need at worst a gated check-in build, or separate the main and feature branches with an integration branch which has a build, or define a build per branch. Personally I prefer to keep main in a known and stable state, defining builds per dev and/or feature branch.
Feb 28, 2013 at 12:35 PM
Yes, we'll need to figure out what "stable" means for us. I'm leaning towards "feature completed and ready for testing". We'd just need to be careful to only merge the changeset from the feature branch into the release branch.

Thanks for the input, everyone.