1. From the TFS Application tier box, go to Start -> Administrative Tools -> Local Security Policy
2. Click on the Security Settings -> Local Policies -> User Rights Assignment node
3. Right-click the Log on as service right and select Properties
4. Click the Add User or Group button
5. Add the TfsService account

It should look something like this when you’re done.

Branch By Release 

In the first on a series of posts regarding branching strategies, I’m going to start off with the ’super’ pattern (why I call it a ’super’ pattern is discussed at the end of the post) – Branch By Release. What does the Branch by Release pattern look like and why use it? The figure below shows the pattern and maps out the usage for it (double-click the image to enlarge it).

Figure 1 – Branch by Release, basic pattern

This pattern is most useful when you are supporting a single version of an application (say a website for example). It can also be used for multiple version support but that can get fairly complicated when you get into branching for isolation, and long running features that may take several versions to implement.

The basic structure as shown in the figure is to build and when you are ready for test, create a new active branch for development and release the code on the “parent” branch (I put parent in quotes because even though it is the parent, branch relationships are generally bi-directional and so this designation is for a frame of reference only). While code is in production you can make fixes to it even while the next version is under development. When the fix has been implemented, simply merge down from production to the active branch.

This is perhaps the simplest of all branching and merge patterns. The reason why this is frequently unsuitable for complex branching and merging, as noted above, are when frequent, temporary branches or long term branches are needed that may span releases. While you can use this pattern for those types of requirements, by itself, it does not offer support for complex scenarios without a lot of extra work.

Dealing with Bugs 

Now that you’ve seen the basics, how do you deal with bugs? There are two scenarios for fixing bugs – when one occurs in code under test and when one occurs in code in production. These two scenarios are represented in Figures 2 and 3 respectively.

Figure 2  - Bug in Test                        Figure 3 – Bug in Prod

A bug that is found in Test is the simplest example because you can simply make the fix in test and merge it down to the active branch for the next release and then the fix is in both versions.

A bug found in Production is a little bit more involved – but not much more. If at all possible, see if the users can wait until the next release is out – that way you don’t have to mess with Production and you can follow the pattern for fixing the bug in test. If the users absolutely need it now (or the code under test is due to be released too far in the future) you can fix and test the bug using the code in production and merge the changes down to the code that is under test and then to the active dev branch.

The next question to be addressed is what to do with the test environments. If you have the luxury of multiple test environments, you can simply test the production changes in a separate test environment. If you only have one test environment, you must stop the current round of tests (for Release 2 in Figure 3 above), release the code fixes for production into test and then release to production. At that point you need to merge the changes from production (Rel 1) down into Release 2. Then re-release the code from the Release 2 branch into the Test environment. Once those tests have passed, merge the changes from the Release 2 branch down to the active development branch for the next release.

Common Code 

 The last item to consider is common code. There are two options for dealing with common code. The first is to have the common code on its’ own branch and to simply reference the project containing the common code (i.e. never deal with the branch directly, just code on your local machine that you retrieved from this branch). This presents LOTS of problems. The biggest is that the common code can change from under you – maybe even daily. And if you manage to overcome this problem you have to deal with synchronizing releases which can also be problematic. So you might be thinking, “Jeff, why don’t I just reference the dll’s from the most current release of the common code?” Well, you can do that under a certain circumstance. That is – the dll’s must also be in version control (i.e. please don’t reference the common code by using a dll found on a server share somewhere – you are just asking for pain when that dll gets “suddenly” updated out from under you). The other issue is that you cannot really update the common code, if needed, without seriously ticking off the people who own that code – maybe they’re more friendly in your organization when you introduce code changes that they weren’t aware of…

But what if you are going to need the latest release of the common code and YOU want to choose when to get a new version? That leads to the second option – branch the common code into your active dev branch (Figure 4).

Figure 4 – Common Code

This allows you to do two things: 1) You can actually change the common code without screwing up the common code project (don’t do this unless you plan out with the common code owners how to version this and get your changes back into the main common code branch) and 2) You can perform updates on the branched common code (i.e. merge down from the common code dev branch (or, preferrably the QA branch) to your active dev branch) when you feel like the common code is stable enough for you to use. This elimintes the problem of the code changing out from under you. There is one drawback to this approach – once you do the first branch from the common code to your branch and then you branch from say Release 1 to Release 2 there is no longer a relationship between your branch of the common code and the main branch. In TFS you can solve this problem by performing a baseless merge between your new branch of common code and the main branch of common code which will create a relationship between the branches.

Pros and Cons

So when should you use this pattern and when should you avoid it? 

Pros 

• This is the simplest model to use
• It’s a great choice for single release web applications
• You use the same structure for hot fixes and maintenance releases
• There is a minimal amount of branching

Cons

• Not as flexible as other patterns
• More difficult to manage multiple releases (more merges are required depending on how many versions you support and they get more difficult as you move along)
• Because file history needs to be traced back to the previous branch, it takes more work to trace

Final Thoughts

At the beginning of this post I mentioned that I classified this as a super pattern. There are many several other major patterns available – branch by quality (Prod/QA/Dev), feature branches, and release by manifest. The reason why this particular pattern gets the designation of a super pattern is because it can be the top level when used in combination with other branching patterns (yes, you can combine patterns which will be discussed in a later post – but it can get very, very complicated). So, for example, you may use this branch by release strategy and for each release you may have a series of features that are broken up into their own branches. You may decide for each feature to have a Dev and QA branch (the ‘Prod’ branch in this case would be the main branch for the entire release). However, I can’t think of a good situation in which you would ever use this as a sub-pattern for one of the other major patterns.

By the way, this works for all IT Pro, Developer and Microsoft Dynamics certifications exams, but expires January 30, 2008, so hurry!

We are providing this tool as a service to the community, and will happily take comments and recommendations for future improvements. It is currently in production use at several companies, so it’s had some testing outside of our test environments. We are releasing the source code for the tool as well. I haven’t thought of what licensing model we should us, but consider it released under the most permissive one you can find. (Does someone have a good recommendation?) In other words, you can use it, modify it, resell it, print it out and use it to start your campfires… whatever you’d like.

Enjoy!  If you enjoy it, or have recommendations, please leave a comment!

Download: Get Latest Before Check-in Policy

1. In general, Microsoft exams do not test your knowledge of the UI. Thus studying up on what menu items are available is generally a waste of time.
2. Understand the command line. Partially because of 1), but also because the questions can be written more clearly, there is a tendency to lean on the command line for answers. You don’t need to be a command line genius, but you do need to understand the basics and understand the features available.
3. Don’t believe that you can pass the test simply because you are an expert TFS user. The test is a Technical Specialist exam, which means that it does not test you on best practice type questions, but rather on questions that test your ability to perform particular tasks related to administering TFS and Team Projects.
4. The answers for the test are specific to TFS 2005 SP1. That means that you will need to study up on some features which are available only in SP1, such as custom controls and the like.
5. When the question says only 2 answers are correct, and you think 3 are correct, think very, very carefully. You are wrong, and there is a something you’re missing.* (see Disclosure 2 below)

Study materials:

• You can’t go wrong with Pro Visual Studio Team System with Team Edition for Database Professionals by Jeff Levinson and David Nelson.
• Consider buying an exam prep. The test is difficult, and an exam prep may help you learn those rather obscure points you’ll need to be proficient at to pass the exam.

Full Disclosure:

1. Jeff Levinson is a coworker. But my recommendation of his book is based on the large trove of useful information contained inside of it.
2. I was involved in the creation and technical review of 70-150. Thus, I’m bound by NDA to not disclose particular features of the test, or things that other people may be able to talk about. (So, if you’ve successfully passed this test, feel free to comment on this post, and let others know your recommendations!) PS. If you have complaints about the test, I’m not WHOLLY responsible…

Thanks to Steve Shippee for recommending this FUQ!

UPDATE:  Don’t forget to register for a free Second Shot, just in case you fail the exam the first time!