TFS Best Practice

Tue, 26 Aug 2008 13:22:13 Z

Could somebody let me know if what I want to do is possible.

My current client creates line of business apps most of which take between 1 and 6 months to write. I am trying to work out how we should work with TFS and have come to a standstill on a couple of points.

We have lots of little applications most of which rely on certain 'common layers/frameworks'. I had come to the conclussion that it would be better to store all software solutions under one TFS prject.

$TFSProj

Main

Source

Common

Project1 References Common1

Project2 References Common1

Project3 No references

TFSBuildTypes

Project1 Build Type

Project2 Build Type

Project3 Build Type

When we check in code that resolves a bug in one of these pieces of software a work item is always associated and resolved.

My problem is that from a Change Management/Config perspective the build report that outlines the associated 'Change Sets' and 'Work Items' would seem meaningless. If I make a change to Project1 and check in against work item 123 and then run Project1 Build Type, Project2 Build Type, Project3 Build Type each one reports that it is associated with the same 'Change Set' and 'Work Items'. Surely the build knows what files are included in the build and therefore what work items to include.

This means I cannot tell what 'Work Items' relate to a build and therefore can not easily (automaticallly) create a release note of the 'Work Items' included.

I can get the granularity I want by creating a TFS Project for each piece of software but this then seems a big pain to handle references to common frameworks (branching in form other tfs projects) and building.

Is there a way arround my issue or should I bite the bullet and create a project per application ?

I have been reading the TFS best practice guide from the Patterns & Practices team but this does not seem to cover my scenario.

Regards

Ben

TFS Best Practice

Thu, 28 Aug 2008 03:18:45 Z

Hello Ben,

I am not sure I catch the problem, it there is any misunderstanding, please let me know.

Based on my understanding,

1. Changesets are added to source codes tree. They don't care for which team build type builds them. From the detail of a Changeset, there is no link to team build types or team build results.

That is each team build can contain same changesets.

It is reasonable. Let's look at one example scenario:

1. We fixed one bug at the common project, check in one changeset with ID ***.

2. We start Build Type1 to build Project1 which refers the common project.

Because the common project has been revised, so the revision (changeset ***) should be included at

team build result (build report) to reflect the souce codes' changes.

3. We start Build Type2 to build Project2 which also refers the common project.

It is the same as the Project1 that team build result should include the changeset ***.

Another issue is how we define the work items related to the changeset ***.

If it is a bug item, we need to make it clear that it is as a common bug which influences codes both at Project1 and Project2 folders.

Then both builds include it to let us know the build has already taken the bug and the bug fix to the build process.

Thanks.

TFS Best Practice

Thu, 28 Aug 2008 09:34:36 Z

My problem relates more to how we should structure out TFS projects.

As our applications are discreet tools that may or may not rely on common frameworks should we store each one in its own TFS proejct ? The problem I have at the moment is this :

I store project1 and project2 (unrelated applications that rely on a common framework) in the same TFS project along with the common frameworks.

I fix a bug with project1 check in the code and resolve a work item.

I run project1 tfs build.

I fix a bug with project2 check in the code and resolve a work item

I run project2 tfs build.

The build report for project2 tfs build contains the work items fixed and associated with project1

My question is, should I be storing project1 and project2 in seperate TFS projects and branching in the common code from another TFS project to both.

Regards & Thanks

Ben.

TFS Best Practice

Thu, 28 Aug 2008 18:24:24 Z

I think your strategy is sound -- just need to fix the build report. You might post in the Team Build and/or Reporting forums for more targeted answers.

TFS Best Practice

Fri, 29 Aug 2008 09:49:25 Z

So would your suggestion be to keep everything in the one project and change the build report?

Regards

Ben

TFS Best Practice

Sat, 30 Aug 2008 19:42:43 Z

Hi !

I might be interrupting into some chain of thought here, apologize for that , but I would like to add some "comments" to this from the starting post. Btw, "comments" are possibly not the right word here, apologize for making rather a long post, but your question and problem is in fact rather interesting and deserves some thought. There is guidelines for this on codeplex, see http://www.codeplex.com/TFSGuide/Release/ProjectReleases.aspx?ReleaseId=6280 but I feel the guidelines there on source code structure is somewhat lacking, althought not in any way wrong, but I would like to add from my own experience, take this for what is it - good intentions .

A) A decision to use one or multiple TFS Projects should be based on other criteria, like teams, rights management, etc, and not on the problem you have. So, I would agree that you can keep everything in one project, if that's the best for you managementwise.

B) The reason you get the behaviour you describe first, is that both your builds "points", so to speak, at the level above your projects, that is the node called 'source'. It is this that determines what is shown in the build report. And no, you should not change anything in the build report. At this level, you probably have two solutions, one called Project1 and one called Project2 (?), or if you have the solutions down at the level of the Project1 and Project2, you have still your workspace for the build at the level of the 'source'.

So in order to get the behaviour you want, you have some options. Which to choose depends a bit on the size of your projects, including common, and the stability of the 'common' framework, your team sizes, how much isolation between them you want etc etc.

I'll outline these options below:

Solution 1. Multiple build workspacemappings: Choose this if:

Your projects are small,

common is small,

your teams are small,

or the same team works on all projects including common,

and/or 'common' is not very stable, meaning it's as likely to change as your projects.

Setup:

Keep your source structure exactly as you have outlined.

Move (if they are not already there, by default they should) your solution files (sln) down to each project, this is essential.

Use project references between each project and common, exactly as you have outlines. Ignore the warning from Visual Studio you may get above referring above your root. You know what you're doing.

Now the change from what you have today:

In the workspacemapping of your build (See Edit Build, 'Workspace'), make -2- mappings, one goes to Project1, and the other goes to Common.

Do the same for Project2.

If you now change something in Project1, and on that checkin associates this with a workitem,both the workitem and the changeset will only show up in the build report for Project1, and nothing will show int the build report for Project2.

Advantages: Simple to do

Disadvantages: A developer may not always get the latest source down, if they are unaware of the dependency on Common. If Common is a very long path-way away from your project, more levels than what you have shown above, this problem is much more likely to happen, in that case got to solution 2 or 3.

Solution 2. Source code branching: Choose this if:

Your projects are a bit larger,

a separate team is or has been working with Common

you need isolation between projects, meaning Project2 will not be bothered by requests from Project1 to change something in Common.

You have a more complex source code structure.

Setup:

Change your source code structure below Project1 and Project2 to include a branch FROM Common. that is, make it look like:

Code Snippet

Source

Common

Project1

CommonBranched

Project2

CommonBranched

Then of course create the branches from Common to the two respective CommonBranched.

It is probably wise in this setup to have a separate solution for Common alone, and its own CI build to make sure it is correct before merging changes over to the Branches.

The solutions for Project1 and Project2 should be as described in solution 1, no changes there.

Note that one would normally not do any changes in the source in the CommonBranches, one could of course, but that would create a mergin issue later when one merges new or updated code from the Common trunk.

Advantages:

Provides better separation between the projects and common

A developer will always get a buildable solution if he takes get latest from the Project node.

Disadvantages:

Every change in Common must be merged over to the branches. This will give an extra step in the process. For a small 'enterprise' this overhead may not be justified, for a lager one, it may be an advantage - due to the fact that this provides isolation and awareness of changes.

Possible changes to the branched source could make them non-mergeable at a later time.

Solution 3: Binary deployment branching: Choose this if:

You have (a/many) large project(s)

Your common framework is rather stable,

Your common framework is used in many other projects, and you would not take the risk that someone at those projects made changes to the source that would make them non-mergeable at a later time.

Setup:

Change the source code structure as follows:

Code Snippet

Source

Common

Deploy

Project1

CommonBranched (or Libs)

Project2

CommonBranched (or Libs)

In addition to the CI build for Common, you should make what I would call a public build, which you build every time you want a new "release". This build should have an extra step, f.e. using the AfterEndToEndIteration target, that it should check in the resulting 'dll' and 'pdb' file into the Deploy folder. (Use the ***NO_CI*** trick on that checkin to avoid triggering the CI build again.) This build btw, should not be triggered or scheduled. You trigger this build manually whenever you need a new release of the Common library.

Now, when that is done, branch the Deploy folders, which mean that you in fact branch the binaries, into the CommonBranched folders.

Advantages:

The teams working on Project1 and Project2 can't mess up the source code. IF they want a change they must post a workitem to the Common team, and wait for a new release. . This is a good thing !

Good isolation (as in Solution 2), and the framework is very nicelly controlled, but in addition, no possibility for a source code problem with the Common source code branched into the projects.

Disadvantages:

The build scripts must be modified

Binaries must be checked in (not a problem IMHO).

Versioning should be introduced in the build process (not described in this post), may further complicate the build script

Advantage in disadvantage:

When the build script changes have been done, the process is smooooottth .

Regardless of which solution above you prefer to implement, your problem with workitems will be solved. All three solutions will provide the necessary isolation.

The immidiate respons to your question will be soltuion 1, but I feel you should know about the other two alternatives before you make your advice to the client. There is of course even more strategies, like f.e. those in the TFS Guide (link at head of post), but the solutions mentioned in this post are what have worked for our company with our clients.

best regards

Terje

TFS Best Practice

Mon, 08 Sep 2008 09:48:37 Z

Terje

Thanks for the information. All the solutions you have outlined look workable. We will probably use the first option as we are a relatively small team. Sorry I didnt get back to you earlier but I have been away on holiday (first day back booo)

Regards & Thanks

Ben