I'm new to FB (day 10 of eval) and trying to figure out the best way to partition FB projects and action lists in our development environment.
We do mostly .NET WinForms applications, and use Perforce for source control. We have multiple applications, and potentially multiple development branches (versions) for each application.
I currently have a single FB project, with a separate action list for each application. I also define a project variable to specify which branch of each application is to be built. This seems to work well, but being new to FB I'm not sure it's optimal.
Also, I wasn't sure if creating a FB project for each branch is better, or using a single FB project in which the Main action list controls how all the branches are built (as I'm currently doing)... or something else altogether.
We’ve been using FB for our build process for a while. We started off with the idea that it’s best to have a generic FB build project and we haven’t found a better way of doing it. In other words, what you have now seems reasonable. You do want to be able to pass in the taskbranch name/path. Depending on what suits your circumstances, if each application build is different enough such that they have to be built in their own unique way, you would have just have a list of separate app builds as you described. If there was a way to generalise your app builds into one 'app build project, that might make sense. In other words, you could have a main project that called the same ‘app build’ sub-project but just passing in different variables.
I agree with Clive - it’s best to have a generic build process and parameterize things like the branch and version to build. Having multiple projects tends to bite you later on when one project has changed over time and the same changes need to be made/merged into another build process.