ALM

Rangers shipped Visual Studio 2010 Database Guide

Martin Hinshelwood — Wed, 25 Aug 2010 13:04:14 GMT

Have you ever struggled with the Database Developer (was DataDude) components of Visual Studio? Well I have…and now the ALM Rangers have released a new guide to help us all get the benefits. There is Guidance as well as Hands-On-Labs and even how to do WIX integration for deployment.

The Visual Studio 2010 Database Guide is available to download from Codeplex and you should try it out and submit some feedback. Wondering what this is all about? Well…

Project Description

Practical guidance for Visual Studio 2010 Database projects, which is focused on 5 topic areas:

Solution and Project Management
Source Code Control and Configuration Management
Integrating External Changes with the Project System
Build and Deployment Automation with Visual Studio Database Projects
Database Testing and Deployment Verification

This release includes common guidance, usage scenarios, hands on labs, and lessons learned from real world engagements and the community discussions.
The goal is to deliver examples that can support you in real world scenarios, instead of an in-depth tour of the product features.

Visual Studio ALM Rangers

This guidance is created by the Visual Studio ALM Rangers, who have the mission to provide out of band solutions for missing features or guidance. This content was created with support from Microsoft Product Group, Microsoft Consulting Services, Microsoft Most Valued Professionals (MVPs) and technical specialists from technology communities around the globe, giving you a real-world view from the field, where the technology has been tested and used.
For more information on the Rangers please visit http://msdn.microsoft.com/en-us/vstudio/ee358786.aspx and for more a list of other Rangers projects please see http://msdn.microsoft.com/en-us/vstudio/ee358787.aspx.

What is in the package?

The content is packaged in 3 separate zip files to give you the choice of selective downloads, but the default download is the first of the listed packages:

Visual Studio Guidance for Database Projects --> Start here
Visual Studio Database Projects Hands-On-Labs document
Hands-On-Labs (HOLs), including:
- Solution and Project Management
  - Refactoring a Visual Studio Database Solution to Leverage Shared Code
- Source Code Control and Configuration Management
  - Single Team Branching Model
  - Multiple Team Branching Model
- Integrating External Changes with the Project System
  - Maintaining Linked Servers in a Visual Studio Database Project
  - Complex data movement
- Build and Deployment Automation
  - WiX-Integration with deployment of databases
  - The Integrate with Team Build Scenario
  - Building and deploying outside team build
- Database Testing and Deployment Verification
  - The “Basic” Create Unit Test Scenario
  - The “Advanced” Create Unit Test Scenario
  - Find Model drifts Scenario

Team

Obviously this type of work would not be possible without many people contributing their free time to make it happen.

Contributors: Shishir Abhyanker (MSFT), Chris Burrows (MSFT), David V Corbin (MVP), Ryan Frazier (MSFT), Larry Guger (MVP), Barclay Hill (MSFT), Bob Leithiser (MSFT), Pablo Rincon (MSFT), Scott Sharpe (MSFT), Jens K. Süßmeyer (MSFT), LeRoy Tuttle (MSFT)
Reviewers: Christian Bitter (MSFT), Regis Gimenis (MSFT), Rob Jarrat (MSFT), Bijan Javidi (MSFT), Mathias Olausson (MVP), Willy-Peter Schaub (MSFT)

Technorati Tags: ALM,TFS 2010,VS 2010,Visual Studio

Commit to Visual Studio ALM on Area51

Martin Hinshelwood — Sun, 15 Aug 2010 10:10:08 GMT

A few weeks ago I proposed a new community for StackExchange and it has been growing at an exponential rate. We are about half way there, but we need your help to make this community a success.

Update 16th August 2010 – The Proposal has now moved from Proposed to the Committed stage and we need your commitment.
http://area51.stackexchange.com/proposals/15894/visual-studio-alm?referrer=vtx1N5_bjYysH8mQCaDCxQ2

Monday 16th August 2010 – Commit to Visual Studio ALM on Area51

If you are not familiar with StackExchange, it has a community driven voting system for creating new sites like Stack Overflow.

Thanks everyone for your efforts and excellent questions. Although we suffered a little from question overload at the Proposal stage I think this is a good omen for the future beta.

We are now in the Commitment stage and need a score of 2000 user points (which gets us to 100%) to proceed to the Beta. This is apparently calculated based on a user’s reputation:

To get a feel for it:

A user with no reputation gets a score of 1

A user with 200 reputation on 1 site gets a score of 1.7

A user with 200 reputation on 3 sites gets a score of 3.1

A user with 10000 reputation on 1 site gets a score of 7.2

A user with 10000 reputation on 3 sites gets a score of 19.6 (these are extremely rare)
Source http://meta.stackoverflow.com/questions/53650/area-51-commit-percent

So if you are interested in Visual Studio ALM or any of its features, be sure to Commit and send this to anyone you know who might be interested.

Commit to Visual Studio ALM

Friday 13th August 2010 – Vote for Visual Studio ALM on Area51

Visual Studio ALM StackExchange Proposal

We have now reached 1 of the three milestones required to get the site to the “commit” stage.

Figure: We have enough followers but not enough votes

We now have question overload and need to concentrate on getting those top 5 On Topic and 5 Off Topic questions to have 20 votes each.

Top 5 On-Topic

What’s a backup and recovery process for Team Foundation Server 2010?
How can I automatically version my assemblies in TFS Build 2010?
How can I sync two Team Foundation Servers?
How do I do branching if I want to be able to create hotfixes?
Default value: Are they assigned only when a work item is created?

Top 5 Off-Topic

Do I need to purchase additional Client access Licenses for TFS 2010?
How do I migrate my TFS content to Visual SourceSafe?
What and who are the ALM Rangers and what role do they play within Microsoft?
How do you install Visual Studio 2003?
How do I debug my WPF application?

If everyone can concentrate their votes in at least the current top 10 we should have enough! If you currently have a vote on a question with fewer than 10 votes it may be worth removing it and adding it to one of the questions higher up.

Visual Studio ALM StackExchange Proposal
You have 5 on-topic and 5 off-topic votes to cast.

Changing the Team Project Collection of the Team Build Controller

Martin Hinshelwood — Mon, 05 Jul 2010 15:57:01 GMT

When you are doing demos or training for Team Foundation Server 2010 (TFS 2010) you may have multiple Team Project Collections (TPC) for different scenarios or process templates. You may even be attaching a pre-built TPC image so you can start from a particular point. If you try to do create a build you will find that it complains about there not being a Team Build Controller (TBC).

One thing you learn very quickly when working with TFS 2010 is that you can only attach ONE Team Build Controller to ONE Team Project Collection. This one-one relationship can cause issues if you have many Team Project Collections because there can only be one Team Project Collection configured per server.

Figure: Two Team Project Collections

This means that if you have 2 Team Project Collection you will need two serve to manage the builds. It can be the same server as your build server, but that depends on your throughput and load.

In the presentation scenario you will need to reconfigure your Team Build Controller on the fly. But how do you do this.

If you open the Team Foundation Server Administration Console you will see a “Build Configuration” node. If you select this it will show all of the configuration options for your build server on that box.

Figure: Team Build Configuration screen shows the Controller and any Agents running on that server

In this case this is our TFS server and we only have the Build Controller running with no Agent. We run all of the agents on another box as it takes lots of processor to do a build and we don’t want that impacting our TFS server.

In order to make the change, we need to alter the options not on the Controller instance itself, but on the Build Service Instance.

Figure: Change the options on the service instance

Select the “Properties” option on the Build service and then stop the service to make the changes.

Figure: The Build Service Properties are only available when the service is stopped

Figure: Select any server and then Project Collection you want to bind to

You need to select the server and then the Team Project Collection that you want to bind to. In fact you could have this Build Service bind to any Team Foundation Server even if the current server hosts TFS. I don’t know why you would want to, but it is possible.

Now that you have the Build Service configured to work against your new Team Project Collection the Build Controller and any Build Agents configured under it will now work for that collection.

You can now go forth and create builds…

Technorati Tags: ALM,TFBS,TFS 2010

Ghost team foundation build controllers

Martin Hinshelwood — Tue, 15 Jun 2010 09:54:36 GMT

Quite often after an upgrade there are things left over. Most of the time they are easy to delete, but sometimes it takes a little effort. Even rarer are those times when something just will not go away no matter how much you try.

We have had a ghost team build controller hanging around for a while now, and it had defeated my best efforts to get rid of it.

The build controller was from our old TFS server from before our TFS 2010 beta 2 upgrade and was really starting to annoy me. Every time I try to delete it I get the message:

Controller cannot be deleted because there are build in progress
-Manage Build Controller dialog

Figure: Deleting a ghost controller does not always work.

I ended up checking all of our 172 Team Projects for the build that was queued, but did not find anything. Jim Lamb pointed me to the “tbl_BuildQueue” table in the team Project Collection database and sure enough there was the nasty little beggar.

Figure: The ghost build was easily spotted

Adam Cogan asked me:

“Why did you suspect this one?”

Well, there are a number of things that led me to suspect it:

QueueId is very low: Look at the other items, they are in the thousands not single digits
ControllerId: I know there is only one legitimate controller, and I am assuming that 6 relates to “zzUnicorn”
DefinitionId: This is a very low number and I looked it up in “tbl_BuildDefinition” and it did not exist
QueueTime: As we did not upgrade to TFS 2010 until late 2009 a date of 2008 for a queued build is very suspect
Status: A status of 2 means that it is still queued

This build must have been queued long ago when we were using TFS 2008, probably a beta, and it never got cleaned up. As controllers are new in TFS 2010 it would have created the “zzUnicorn” controller to handle any build servers that already exist. I had previously deleted the Agent, but leaving the controller just looks untidy.

Now that the ghost build has been identified there are two options:

Delete the row
I would not recommend ever deleting anything from the database to achieve something in TFS. It is really not supported.
Set the Status to cancelled (Recommended)
This is the best option as TFS will then clean it up itself

So I set the Status of this build to 2 (cancelled) and sure enough it disappeared after a couple of minutes and I was then able to then delete the “zzUnicorn” controller.

Figure: Almost completely clean

Now all I have to do is get rid of that untidy “zzBunyip” agent, but that will require rewriting one of our build scripts which will have to wait for now.

Technorati Tags: ALM,TFBS,TFS 2010

Why you need to tag your build servers in TFS

Martin Hinshelwood — Mon, 14 Jun 2010 17:11:55 GMT

At SSW we use gated check-in for all of our projects. The benefits are based on the number of developers you have working on your project.

Lets say you have 30 developers and each developer breaks the build once per month. That could mean that you have a broken build every day! Gated check-ins help, but they have a down side that manifests as queued builds and moaning developers.

The way to combat this is to have more build servers, but with that comes complexity. Inevitably you will need to install components that you would expect to be installed on target computers, but how do you keep track of which build servers have which bits?

What about a geographically diverse team? If you have a centrally controlled infrastructure you might have build servers in multiple regions and you don’t want teams in Sydney copying files from Beijing and vice a versa on a regular basis.

So, what is the answer. Its Tags. You can add a set of Tags to your agents and then set which tags to look for in the build definition.

Figure: Open up your Build Controller Manager

Select “Build | Manage Build Controllers…” to get a list of all of your controllers and he build agents that are associated with them.

Figure: the list of build agents and their controllers

Each of these Agents might be subtly different. For example only one of these agents has FTP software installed. This software is required for only one of the many builds we have set up.

My ethos for build servers is to keep them as clean as possible and not to install anything that is not absolutely necessary. For me that means anything that does not add a *.target file is suspect, and should really be under version control and called via the command line from there.

So, some of the things you may install are:

Silverlight 4 SDK
Visual Studio 2010
Visual Studio 2008
WIX
etc

You should not install things that will not end up on the target users computer. For a website that means something different to a client than to a server, but I am sure you get the idea.

One thing you can do to make things easier is to create a tag for each of the things that you install. that way developers can find the things they need. We may change to using a more generic tagging structure (Like “Web Application” or “WinForms Application”) if this gets too unwieldy, but for now the list of tags is limited.

Figure: Tags associated with one of our build agents

Once you have your Build Agents all tagged up ALL your builds will start to fail

This is because the default setting for a build is to look for an Agent that exactly matches the tags for the build, and we have not added any yet. The quick way to fix this is to change the “Tag Comparison Operator” from “ExactMatch” to “MatchAtLease” to get your build immediately working.

Figure: Tag Comparison Operator changes to MatchAtLeast to get builds to run.

The next thing to do is look for specific tags. You just select from the list of available tags and the controller will make sure you get to a build agent that uses them.

Figure: I want Silverlight, VS2010 and WIX, but do not care about Location.

And there you go, you can now have build agents for different purposes and regions within the same environment.

You can also use name filtering, so if you have a good Agent naming convention you can filter by that for regions. For example, your Agents might be “SYDVMAPTFSBP01” and “SYDVMAPTFSBP02” so a name filter of “SYD*” would target all of the Sydney build agents.

Figure: Agent names can be used for filtering as well

This flexibility will allow you to build better software by reducing the likelihood of not having a certain dependency on the target machines.

Figure: Setting the name filter based on server location

Used in combination there is a lot of power here to coordinate tens of build servers for multiple projects across multiple regions so your developers get the most out of your environment.

Technorati Tags: ALM,TFBS,TFS 2010,TFS Admin

Guidance: How to layout you files for an Ideal Solution

Martin Hinshelwood — Mon, 17 May 2010 10:08:16 GMT

Creating a solution and having it maintainable over time is an art and not a science. I like being pedantic and having a place for everything, no matter how small.

For setting up the Areas to run Multiple projects under one solution see my post on When should I use Areas in TFS instead of Team Projects and for an explanation of branching see Guidance: A Branching strategy for Scrum Teams.

Update 17th May 2010 – We are currently trialling running a single Sprint branch to improve our history.
Update 20th May 2010 – Fixing Images
Updated 4th August 2010 – There is now best practice guidance around this that supersedes this post.
How To: Structure Your Source Control Folders in Team Foundation Server

Whenever I setup a new Team Project I implement the basic version control structure. I put “readme.txt” files in the folder structure explaining the different levels, and a solution file called “[Client].[Product].sln” located at “$/[Client]/[Product]/DEV/Main” within version control.

Developers should add any projects you need to create to that solution in the format “[Client].[Product].[ProductArea].[Assembly]” and they will automatically be picked up and built automatically when you setup Automated Builds using Team Foundation Build.

All test projects need to be done using MSTest to get proper IDE and Team Foundation Build integration out-of-the-box and be named for the assembly that it is testing with a naming convention of “[Client].[Product].[ProductArea].[Assembly].Tests”

Here is a description of the folder layout; this content should be replicated in readme files under version control in the relevant locations so that even developers new to the project can see how to do it.

Figure: The Team Project level - at this level there should be a folder for each the products that you are building if you are using Areas correctly in TFS 2010.

You should try very hard to avoided spaces as these things always end up in a URL eventually e.g. "Code Auditor" should be "CodeAuditor".

Figure: Product Level - At this level there should be only 3 folders (DEV, RELESE and SAFE) all of which should be in capitals.

These folders represent the three stages of your application production line. Each of them may contain multiple branches but this format leaves all of your branches at the same level.

Figure: The DEV folder is where all of the Development branches reside.

The DEV folder will contain the "Main" branch and all feature branches is they are being used. The DEV designation specifies that all code in every branch under this folder has not been released or made ready for release. And feature branches MUST merge (Forward Integrate) from Main and stabilise prior to merging (Reverse Integration) back down into Main and being decommissioned.

Figure: In the Feature branching scenario only merges are allowed onto Main, no development can be done there.

Once we have a mature product it is important that new features being developed in parallel are kept separate. This would most likely be used if we had more than one Scrum team working on a single product.

Figure: when we are ready to do a release of our software we will create a release branch that is then stabilised prior to deployment.

This protects the serviceability of of our released code allowing developers to fix bugs and re-release an existing version.

Figure: All bugs found on a release are fixed on the release.

All bugs found in a release are fixed on the release and a new deployment is created. After the deployment is created the bug fixes are then merged (Reverse Integration) into the Main branch. We do this so that we separate out our development from our production ready code.

Figure: SAFE or RTM is a read only record of what you actually released. Labels are not immutable so are useless in this circumstance.

When we have completed stabilisation of the release branch and we are ready to deploy to production we create a read-only copy of the code for reference. In some cases this could be a regulatory concern, but in most cases it protects the company building the product from legal entanglements based on what you did or did not release.

Figure: This allows us to reference any particular version of our application that was ever shipped.

In addition I am an advocate of having a single solution with all the Project folders directly under the “Trunk”/”Main” folder and using the full name for the project folders..

Figure: The ideal solution

If you must have multiple solutions, because you need to use more than one version of Visual Studio, name the solutions “[Client].[Product][VSVersion].sln” and have it reside in the same folder as the other solution.

This makes it easier for Automated build and improves the discoverability of your code and its dependencies.

Send me your feedback!

Technorati Tags: ALM VS 2010 VS 2008 TFS 2010 TFS 2008 TFBS Scrum Branching TFS

Scrum with Team Foundation Server 2010 Done

Martin Hinshelwood — Sun, 09 May 2010 21:32:39 GMT

Since I have joined SSW as a Solution Architect its Chief Architect, Adam Cogan, has been mentoring me and pushing me to do better. One of the things that I have been wanting to do since the first DDD Scotland was to present a session. For DDD Scotland 2010 Adam suggested that I submit he double session on “Better project Management with Team Foundation Server 2010”.

So, with some apprehension I submitted two session as Part A and Part B.

Download DDD Scotland - Scrum with Team Foundation Server 2010

How surprised was I that after the attendees had finished casting their votes that both sessions would be in the top 20 one in the top 5. I an effort to promote diversity in sessions the DDD committee try to make sure that each presenter only have one session. I would have to compress SSW’s presentation into 1 hour.

Around this time SSW embarked on it continuing adventures with scrum an Microsoft started heavily investing in Scrum for its internal use. I decided to do a slightly different session, but one that would still meet the agenda and goal of the billed session to provide “Better project management with Team Foundation Server 2010”.

And so Scrum with Team Foundation Server 2010 was born. At this stage I really have to thank Aaron Bjork who provided me with many of the slides and animations as I really can’t work Power Point.

On the 27th of April I presented the session for the Aberdeen Partner Group and then on 8th May I presented at DDD Scotland.

Figure: Some of the presenters and organisers of DDD Scotland

I mentioned quite a few of SSW’s Rules to better Scrum Using TFS and I have uploaded my presentation to Skydrive.

Download DDD Scotland - Scrum with Team Foundation Server 2010

Technorati Tags: Scrum TFS 2010 ALM DDD Scot Live SSW SP 2010 SharePoint

Integrate SharePoint 2010 with Team Foundation Server 2010

Martin Hinshelwood — Mon, 03 May 2010 15:47:36 GMT

Our client is using a brand new shiny installation of SharePoint 2010, so we need to integrate our upgraded Team Foundation Server 2010 instance into it. In order to do that you need to run the Team Foundation Server 2010 install on the SharePoint 2010 server and choose to install only the “Extensions for SharePoint Products and Technologies”. We want out upgraded Team Project Collection to create any new portal in this SharePoint 2010 server farm.

Update 4th May 2010

Nilesh Deshpande from LightSpeedIT in Sydney was asking how he configures SharePoint integration when he has TFS installed on Windows 7. The answer is easy, if not one he will like. You can’t. When you install on Windows 7 you can only do a basic install and the Admin options you would need to configure SharePoint are not available. You will need to move you ProjectCollection to a TFS instance running on a Server OS to be able to do this.

There a number of goodies above and beyond a solution file that requires the install, with the main one being the TFS2010 client API. These goodies allow proper integration with the creation and viewing of Work Items from SharePoint a new feature with TFS 2010. This works in both SharePoint 2007 and SharePoint 2010 with the level of integration dependant on the version of SharePoint that you are running. There are three levels of integration with “SharePoint Services 3.0” or “SharePoint Foundation 2010” being the lowest. This level only offers reporting services framed integration for reporting along with Work Item Integration and document management. The highest is Microsoft Office SharePoint Services (MOSS) Enterprise with Excel Services integration providing some lovely dashboards.

Figure: Dashboards take the guessing out of Project Planning and estimation. Plus writing these reports would be boring!

The Extensions that you need are on the same installation media as the main TFS install and the only difference is the options you pick during the install.

Figure: Installing the TFS 2010 Extensions for SharePoint Products and Technologies onto SharePoint 2010

Annoyingly you may need to reboot a couple of times, but on this server the process was MUCH smother than on our internal server. I think this was mostly to do with this being a clean install.

Once it is installed you need to run the configuration. This will add all of the Solution and Templates that are needed for SharePoint to work properly with TFS.

Figure: This is where all the TFS 2010 goodies are added to your SharePoint 2010 server and the TFS 2010 object model is installed.

Figure: All done, you have everything installed, but you still need to configure it

Now that we have the TFS 2010 SharePoint Extensions installed on our SharePoint 2010 server we need to configure them both so that they will talk happily to each other.

Configuring the SharePoint 2010 Managed path for Team Foundation Server 2010

In order for TFS to automatically create your project portals you need a wildcard managed path setup. This is where TFS will create the portal during the creation of a new Team project.

To find the managed paths page for any application you need to first select the “Managed web applications” link from the SharePoint 2010 Central Administration screen.

Figure: Find the “Manage web applications” link under the “Application Management” section.

On you are there you will see that the “Managed Paths” are there, they are just greyed out and selecting one of the applications will enable it to be clicked.

Figure: You need to select an application for the SharePoint 2010 ribbon to activate.

Figure: You need to select an application before you can get to the Managed Paths for that application.

Now we need to add a managed path for TFS 2010 to create its portals under. I have gone for the obvious option of just calling the managed path “TFS02” as the TFS 2010 server is the second TFS server that the client has installed, TFS 2008 being the first. This links the location to the server name, and as you can’t have two projects of the same name in two separate project collections there is unlikely to be any conflicts.

Figure: Add a “tfs02” wildcard inclusion path to your SharePoint site.

Configure the Team Foundation Server 2010 connection to SharePoint 2010

In order to have you new TFS 2010 Server talk to and create sites in SharePoint 2010 you need to tell the TFS server where to put them. As this TFS 2010 server was installed in out-of-the-box mode it has a SharePoint Services 3.0 (the free one) server running on the same box. But we want to change that so we can use the external SharePoint 2010 instance. Just open the “Team Foundation Server Administration Console” and navigate to the “SharePoint Web Applications” section. Here you click “Add” and enter the details for the Managed path we just created.

Figure: If you have special permissions on your SharePoint you may need to add accounts to the “Service Accounts” section.

Before we can se this new SharePoint 2010 instance to be the default for our upgraded Team Project Collection we need to configure SharePoint to take instructions from our TFS server.

Configure SharePoint 2010 to connect to Team Foundation Server 2010

On your SharePoint 2010 server open the Team Foundation Server Administration Console and select the “Extensions for SharePoint Products and Technologies” node. Here we need to “grant access” for our TFS 2010 server to create sites. Click the “Grant access” link and fill out the full URL to the TFS server, for example http://servername.domain.com:8080/tfs, and if need be restrict the path that TFS sites can be created on. Remember that when the users create a new team project they can change the default and point it anywhere they like as long as it is an authorised SharePoint location.

Figure: Grant access for your TFS 2010 server to create sites in SharePoint 2010

Now that we have an authorised location for our team project portals to be created we need to tell our Team Project Collection that this is where it should stick sites by default for any new Team Projects created.

Configure the Team Foundation Server 2010 Team Project Collection to create new sites in SharePoint 2010

Back on out TFS 2010 server we need to setup the defaults for our upgraded Team Project Collection to the new SharePoint 2010 integration we have just set up. On the TFS 2010 server open up the “Team Foundation Server Administration Console” again and navigate to the “Team Project Collections” node. Once you are there you will see a list of all of your TPC’s and in our case we have a DefaultCollection as well as out named and Upgraded collection for TFS 2008.

If you select the “SharePoint Site” tab we can see that it is not currently configured.

Figure: Our new Upgrade TFS2008 Team Project Collection does not have SharePoint configured

Select to “Edit Default Site Location” and select the new integration point that we just set up for SharePoint 2010. Once you have selected the “SharePoint Web Application” (the thing we just configured) then it will give you an example based on that configuration point and the name of the Team Project Collection that we are configuring.

Figure: Set the default location for new Team Project Portals to be created for this Team Project Collection

This is where the reason for configuring the Extensions on the SharePoint 2010 server before doing this last bit becomes apparent. TFS 2010 is going to create a site at our http://sharepointserver/tfs02/ location called http://sharepointserver/tfs02/[TeamProjectCollection], or whatever we had specified, and it would have had difficulty doing this if we had not given it permission first.

Figure: If there is no Team Project Collection site at this location the TFS 2010 server is going to create one

This will create a nice Team Project Collection parent site to contain the Portals for any new Team Projects that are created. It is with noting that it will not create portals for existing Team Projects as this process is run during the Team Project Creation wizard.

Figure: Just a basic parent site to host all of your new Team Project Portals as sub sites

You will need to add all of the users that will be creating Team Projects to be Administrators of this site so that they will not get an error during the Project Creation Wizard. You may also want to customise this as a proper portal to your projects if you are going to be having lots of them, but it is really just a default placeholder so you have a top level site that you can backup and point at.

You have now integrated SharePoint 2010 and team Foundation Server 2010!

You can now go forth and multiple your Team Projects for this Team Project Collection or you can continue to add portals to your other Collections.

Technorati Tags: TFS 2010 SP 2010 ALM MOSS TFS 2008 TFS SharePoint

Upgrading Team Foundation Server 2008 to 2010

Martin Hinshelwood — Mon, 03 May 2010 12:04:01 GMT

I am sure you will have seen my posts on upgrading our internal Team Foundation Server from TFS2008 to TFS2010 Beta 2, RC and RTM, but what about a fresh upgrade of TFS2008 to TFS2010 using the RTM version of TFS. One of our clients is taking the plunge with TFS2010, so I have the job of doing the upgrade.

Update 4th May 2010

John Liu – John can’t find his history after the Upgrade. This is not a feature of the upgrade and indeed all of the history is in tact on the original project. The problem is that you can’t actually change the process template that a project uses. Oh, you can make a really good stab at making it look like it has been upgraded, but under the covers there will be differences from a native project. So the plan is to migrate by creating a new project on the Agile5 template that has a branch of code from the old Conchnago project. This keeps the history in tact, if not in one place. If you look in the history and what you are looking for is before the upgrade data (same as the date of the branch) you need to follow the branch back to the old project and check there. I bet in 6 months you never need to look…
Allan Zhou – I am going to cover the project upgrade process in a future post, but suffice to say you can not remove a template once it has been used. That data will be floating around in the warehouse and cube forever. You can do a certain amount of clean up, but that would require you to “destroy” all of the work item types and projects that use an old template and you would loose history.
Sam Abraham – You can indeed connect just fine from Visual Studio 2010 to a Team Foundation Server 2008.

It is sometimes very useful to have a team member that starts work when most of the Sydney workers are heading home as I can do the upgrade without impacting them. The down side is that if you have any blockers then you can be pretty sure that everyone that can deal with your problem is asleep

I am starting with an existing blank installation of TFS 2010, but Adam Cogan let slip that he was the one that did the install so I thought it prudent to make sure that it was OK.

Verifying Team Foundation Server 2010

We need to check that TFS 2010 has been installed correctly. First, check the Admin console and have a root about for any errors.

Figure: Even the SQL Setup looks good. I don’t know how Adam did it!

Backing up the Team Foundation Server 2008 Databases

As we are moving from one server to another (recommended method) we will be taking a backup of our TFS2008 databases and resorting them to the SQL Server for the new TFS2010 Server. Do not just detach and reattach. This will cause problems with the version of the database. If you are running a test migration you just need to create a backup of the TFS 2008 databases, but if you are doing the live migration then you should stop IIS on the TFS 2008 server before you backup the databases. This will stop any inadvertent check-ins or changes to TFS 2008.

Figure: Stop IIS before you take a backup to prevent any TFS 2008 changes being written to the database.

It is good to leave a little time between taking the TFS 2008 server offline and commencing the upgrade as there is always one developer who has not finished and starts screaming. This time it was John Liu that needed 10 more minutes to make his changes and check-in, so I always give it 30 minutes and see if anyone screams.

John Liu [SSW] said:
are you doing something to TFS :-O
MrHinsh [SSW UK][VS ALM MVP] said:
I have stopped TFS 2008 as per my emails
John Liu [SSW] said:
haven't finish check in @_@
can we have it for 10mins? :)
MrHinsh [SSW UK][VS ALM MVP] said:
TFS 2008 has been started
John Liu [SSW] said:
I love you!

-IM conversation at TFS Upgrade +25 minutes

After John confirmed that he had everything done I turned IIS off again and made a cup of tea. There were no more screams so the upgrade can continue.

Figure: Backup all of the databases for TFS and include the Reporting Services, just in case.

Figure: Check that all the backups have been taken

Once you have your backups, you need to copy them to your new TFS2010 server and restore them. This is a good way to proceed as if we have any problems, or just plain run out of time, then you just turn the TFS 2008 server back on and all you have lost is one upgrade day, and not 10 developer days.

As per the rules, you should record the number of files and the total number of areas and iterations before the upgrade so you have something to compare to:

TFS2008

File count:

Type Count

1 1845

2 15770

Areas & Iterations:

139

You can use this to verify that the upgrade was successful. it should however be noted that the numbers in TFS 2010 will be bigger. This is due to some of the sorting out that TFS does during the upgrade process.

Restore Team Foundation Server 2008 Databases

Restoring the databases is much more time consuming than just attaching them as you need to do them one at a time. But you may be taking a backup of an operational database and need to restore all your databases to a particular point in time instead of to the latest. I am doing latest unless I encounter any problems.

Figure: Restore each of the databases to either a latest or specific point in time.

Figure: Restore all of the required databases

Now that all of your databases are restored you now need to upgrade them to Team Foundation Server 2010.

Upgrade Team Foundation Server 2008 Databases

This is probably the easiest part of the process. You need to call a fire and forget command that will go off to the database specified, find the TFS 2008 databases and upgrade them to 2010. During this process all of the 6 main TFS 2008 databases are merged into the TfsVersionControl database, upgraded and then the database is renamed to TFS_[CollectionName]. The rename is only the database and not the physical files, so it is worth going back and renaming the physical file as well. This keeps everything neat and tidy.

If you plan to keep the old TFS 2008 server around, for example if you are doing a test migration first, then you will need to change the TFS GUID. This GUID is unique to each TFS instance and is preserved when you upgrade. This GUID is used by the clients and they can get a little confused if there are two servers with the same one.

To kick of the upgrade you need to open a command prompt and change the path to “C:\Program Files\Microsoft Team Foundation Server 2010\Tools” and run the “import” command in “tfsconfig”.

TfsConfig import /sqlinstance:<Previous TFS Data Tier>
                 /collectionName:<Collection Name>
                 /confirmed

Imports a TFS 2005 or 2008 data tier as a new project collection.

Important: This command should only be executed after adequate backups have been performed.

After you import, you will need to configure portal and reporting settings via the administration console.

EXAMPLES
--------
TfsConfig import /sqlinstance:tfs2008sql /collectionName:imported /confirmed
TfsConfig import /sqlinstance:tfs2008sql\Instance /collectionName:imported /confirmed

OPTIONS:
--------
sqlinstance         The sql instance of the TFS 2005 or 2008 data tier. The TFS databases at that location will be modified directly and will no longer be usable as previous version databases. Ensure you have back-ups.

collectionName      The name of the new Team Project Collection.

confirmed           Confirm that you have backed-up databases before importing.

This command will automatically look for the TfsIntegration database and verify that all the other required databases exist.

In this case it took around 5 minutes to complete the upgrade as the total database size was under 700MB. This was unlike the upgrade of SSW’s production database with over 17GB of data which took a few hours. At the end of the process you should get no errors and no warnings.

The Upgrade operation on the ApplicationTier feature has completed. There were 0 errors and 0 warnings.

As this is a new server and not a pure upgrade there should not be a problem with the GUID.

If you think at any point you will be doing this more than once, for example doing a test migration, or merging many TFS 2008 instances into a single one, then you should go back and rename the physical TfsVersionControl.mdf file to the same as the new collection. This will avoid confusion later down the line.

To do this, detach the new collection from the server and rename the physical files. Then reattach and change the physical file locations to match the new name.

You can follow http://www.mssqltips.com/tip.asp?tip=1122 for a more detailed explanation of how to do this.

Figure: Stop the collection so TFS does not take a wobbly when we detach the database.

When you try to start the new collection again you will get a conflict with project names and will require to remove the Test Upgrade collection. This is fine and it just needs detached.

Figure: Detaching the test upgrade from the new Team Foundation Server 2010 so we can start the new Collection again.

You will now be able to start the new upgraded collection and you are ready for testing.

Do you remember the stats we took off the TFS 2008 server?

TFS2008

File count:

Type Count

1 1845

2 15770

Areas & Iterations:

139

Well, now we need to compare them to the TFS 2010 stats, remembering that there will probably be more files under source control.

TFS2010

File count:

Type Count

1 19288

Areas & Iterations:

139

Lovely, the number of iterations are the same, and the number of files is bigger. Just what we were looking for.

Testing the upgraded Team Foundation Server 2010 Project Collection

Can we connect to the new collection and project?

Figure: We can connect to the new collection and project.

Figure: make sure you can connect to The upgraded projects and that you can see all of the files.

Figure: Team Web Access is there and working.

Note that for Team Web Access you now use the same port and URL as for TFS 2010. So in this case as I am running on the local box you need to use http://localhost:8080/tfs which will redirect you to http://localhost:8080/tfs/web for the web access.

If you need to connect with a Visual Studio 2008 client you will need to use the full path of the new collection, http://[servername]/tfs/[collectionname] and this will work with all of your collections.

With Visual Studio 2005 you will only be able to connect to the Default collection and in both VS2008 and VS2005 you will need to install the forward compatibility updates.

Visual Studio Team System 2005 Service Pack 1 Forward Compatibility Update for Team Foundation Server 2010
Visual Studio Team System 2008 Service Pack 1 Forward Compatibility Update for Team Foundation Server 2010
To make sure that you have everything up to date, make sure that you run SSW Diagnostics and get all green ticks.

Upgrade Done!

At this point you can send out a notice to everyone that the upgrade is complete and and give them the connection details. You need to remember that at this stage we have 2008 project upgraded to run under TFS 2010 but it is still running under that same process template that it was running before. You can only “enable” 2010 features in a process template you can’t upgrade. So what to do? Well, you need to create a new project and migrate things you want to keep across.

Souse code is easy, you can move or Branch, but Work Items are more difficult as you can’t move them between projects. This instance is complicated more as the old project uses the Conchango/EMC Scrum for Team System template and I will need to write a script/application to get the work items across with their attachments in tact.

That is my next task!

Technorati Tags: TFS 2010 TFS 2008 ALM SSW Scrum VS 2010 VS 2008 SP 2010 TFS SharePoint TFS 2005 VS 2005

Guidance: A Branching strategy for Scrum Teams

Martin Hinshelwood — Wed, 14 Apr 2010 19:11:36 GMT

Having a good branching strategy will save your bacon, or at least your code. Be careful when deviating from your branching strategy because if you do, you may be worse off than when you started!

This is one possible branching strategy for Scrum teams and I will not be going in depth with Scrum but you can find out more about Scrum by reading the Scrum Guide and you can even assess your Scrum knowledge by having a go at the Scrum Open Assessment. You can also read SSW’s Rules to Better Scrum using TFS which have been developed during our own Scrum implementations.

Acknowledgements

Bill Heys – Bill offered some good feedback on this post and helped soften the language.
Note: Bill is a VS ALM Ranger and co-wrote the Branching Guidance for TFS 2010
Willy-Peter Schaub – Willy-Peter is an ex Visual Studio ALM MVP turned blue badge and has been involved in most of the guidance including the Branching Guidance for TFS 2010
Chris Birmele – Chris wrote some of the early TFS Branching and Merging Guidance.
Dr Paul Neumeyer, Ph.D Parallel Processes, ScrumMaster and SSW Solution Architect – Paul wanted to have feature branches coming from the release branch as well. We agreed that this is really a spin-off that needs own project, backlog, budget and Team.
Scenario: A product is developed RTM 1.0 is released and gets great sales. Extra features are demanded but the new version will have double to price to pay to recover costs, work is approved by the guys with budget and a few sprints later RTM 2.0 is released. Sales a very low due to the pricing strategy. There are lots of clients on RTM 1.0 calling out for patches.

As I keep getting Reverse Integration and Forward Integration mixed up and Bill keeps slapping my wrists I thought I should have a reminder:

You still seemed to use reverse and/or forward integration in the wrong context. I would recommend reviewing your document at the end to ensure that it agrees with the common understanding of these terms merge (forward integration) from parent to child (same direction as the branch), and merge (reverse integration) from child to parent (the reverse direction of the branch).
- one of my many slaps on the wrist from Bill Heys.

Updates 15th April 2010

Ian Ceicys – Ian provided some corrections and clarity improvements as well as some good discussion on wither you should delete a sprint once it is complete. This I think is a preference thing as deleting a branch does not remove the history, just the future.

Update 17th May 2010 – We are currently trialling running a single Sprint branch to improve our history.

As I mentioned previously we are using a single feature branching strategy in our current project.

The single biggest mistake developers make is developing against the “Main” or “Trunk” line. This ultimately leads to messy code as things are added and never finished. Your only alternative is to NEVER check in unless your code is 100%, but this does not work in practice, even with a single developer. Your ADD will kick in and your half-finished code will be finished enough to pass the build and the tests. You do use builds don’t you?

Sadly, this is a very common scenario and I have had people argue that branching merely adds complexity. Then again I have seen the other side of the universe ... branching structures from he... We should somehow convince everyone that there is a happy between no-branching and too-much-branching.
- Willy-Peter Schaub, VS ALM Ranger, Microsoft

A key benefit of branching for development is to isolate changes from the stable Main branch. Branching adds sanity more than it adds complexity. We do try to stress in our guidance that it is important to justify a branch, by doing a cost benefit analysis. The primary cost is the effort to do merges and resolve conflicts. A key benefit is that you have a stable code base in Main and accept changes into Main only after they pass quality gates, etc.
- Bill Heys, VS ALM Ranger & TFS Branching Lead, Microsoft

The second biggest mistake developers make is branching anything other than the WHOLE “Main” line. If you branch parts of your code and not others it gets out of sync and can make integration a nightmare. You should have your Source, Assets, Build scripts deployment scripts and dependencies inside the “Main” folder and branch the whole thing. Some departments within MSFT even go as far as to add the environments used to develop the product in there as well; although I would not recommend that unless you have a massive SQL cluster to house your source code.

We tried the “add environment” back in South-Africa and while it was “phenomenal”, especially when having to switch between environments, the disk storage and processing requirements killed us. We opted for virtualization to skin this cat of keeping a ready-to-go environment handy.
- Willy-Peter Schaub, VS ALM Ranger, Microsoft

I think people often think that you should have separate branches for separate environments (e.g. Dev, Test, Integration Test, QA, etc.). I prefer to think of deploying to environments (such as from Main to QA) rather than branching for QA).
- Bill Heys, VS ALM Ranger & TFS Branching Lead, Microsoft

You can read about SSW’s Rules to better Source Control for some additional information on what Source Control to use and how to use it.

There are also a number of branching Anti-Patterns that should be avoided at all costs:

You know you are on the wrong track if you experience one or more of the following symptoms in your development environment:

Merge Paranoia—avoiding merging at all cost, usually because of a fear of the consequences.

Merge Mania—spending too much time merging software assets instead of developing them.

Big Bang Merge—deferring branch merging to the end of the development effort and attempting to merge all branches simultaneously.

Never-Ending Merge—continuous merging activity because there is always more to merge.

Wrong-Way Merge—merging a software asset version with an earlier version.

Branch Mania—creating many branches for no apparent reason.

Cascading Branches—branching but never merging back to the main line.

Mysterious Branches—branching for no apparent reason.

Temporary Branches—branching for changing reasons, so the branch becomes a permanent temporary workspace.

Volatile Branches—branching with unstable software assets shared by other branches or merged into another branch.
Note Branches are volatile most of the time while they exist as independent branches. That is the point of having them. The difference is that you should not share or merge branches while they are in an unstable state.

Development Freeze—stopping all development activities while branching, merging, and building new base lines.

Berlin Wall—using branches to divide the development team members, instead of dividing the work they are performing.

-Branching and Merging Primer by Chris Birmele - Developer Tools Technical Specialist at Microsoft Pty Ltd in Australia

In fact, this can result in a merge exercise no-one wants to be involved in, merging hundreds of thousands of change sets and trying to get a consolidated build. Again, we need to find a happy medium.
- Willy-Peter Schaub on Merge Paranoia

Merge conflicts are generally the result of making changes to the same file in both the target and source branch. If you create merge conflicts, you will eventually need to resolve them. Often the resolution is manual. Merging more frequently allows you to resolve these conflicts close to when they happen, making the resolution clearer. Waiting weeks or months to resolve them, the Big Bang approach, means you are more likely to resolve conflicts incorrectly.
- Bill Heys, VS ALM Ranger & TFS Branching Lead, Microsoft

Figure: Main line, this is where your stable code lives and where any build has known entities, always passes and has a happy test that passes as well?

Many development projects consist of, a single “Main” line of source and artifacts. This is good; at least there is source control . There are however a couple of issues that need to be considered.

What happens if:

you and your team are working on a new set of features and the customer wants a change to his current version?
you are working on two features and the customer decides to abandon one of them?
you have two teams working on different feature sets and their changes start interfering with each other?
I just use labels instead of branches?

That's a lot of “what if’s”, but there is a simple way of preventing this. Branching…

In TFS, labels are not immutable. This does not mean they are not useful. But labels do not provide a very good development isolation mechanism. Branching allows separate code sets to evolve separately (e.g. Current with hotfixes, and vNext with new development). I don’t see how labels work here.
- Bill Heys, VS ALM Ranger & TFS Branching Lead, Microsoft

Figure: Creating a single feature branch means you can isolate the development work on that branch.

Its standard practice for large projects with lots of developers to use Feature branching and you can check the Branching Guidance for the latest recommendations from the Visual Studio ALM Rangers for other methods.

In the diagram above you can see my recommendation for branching when using Scrum development with TFS 2010. It consists of a single Sprint branch to contain all the changes for the current sprint. The main branch has the permissions changes so contributors to the project can only Branch and Merge with “Main”. This will prevent accidental check-ins or checkouts of the “Main” line that would contaminate the code. The developers continue to develop on sprint one until the completion of the sprint.

Note: In the real world, starting a new Greenfield project, this process starts at Sprint 2 as at the start of Sprint 1 you would not have artifacts in version control and no need for isolation.

Figure: Once the sprint is complete the Sprint 1 code can then be merged back into the Main line.

There are always good practices to follow, and one is to always do a Forward Integration from Main into Sprint 1 before you do a Reverse Integration from Sprint 1 back into Main. In this case it may seem superfluous, but this builds good muscle memory into your developer’s work ethic and means that no bad habits are learned that would interfere with additional Scrum Teams being added to the Product.

The process of completing your sprint development:

The Team completes their work according to their definition of done.
Merge from “Main” into “Sprint1” (Forward Integration)
Stabilize your code with any changes coming from other Scrum Teams working on the same product. If you have one Scrum Team this should be quick, but there may have been bug fixes in the Release branches. (we will talk about release branches later)
Merge from “Sprint1” into “Main” to commit your changes. (Reverse Integration)
Check-in
Delete the Sprint1 branch
Note: The Sprint 1 branch is no longer required as its useful life has been concluded.
Note: In TFS deleting the Sprint 1 branch does not remove access to the to the history it just removes a future for that branch.
Note: If you do not like this option you can lock the files on the branch or change it to read only.
Check-in
Done

But you are not yet done with the Sprint. The goal in Scrum is to have a “potentially shippable product” at the end of every Sprint, and we do not have that yet, we only have finished code.

Figure: With Sprint 1 merged you can create a Release branch and run your final packaging and testing

In 99% of all projects I have been involved in or watched, a “shippable product” only happens towards the end of the overall lifecycle, especially when sprints are short. The in-between releases are great demonstration releases, but not shippable. Perhaps it comes from my 80’s brain washing that we only ship when we reach the agreed quality and business feature bar.
- Willy-Peter Schaub, VS ALM Ranger, Microsoft

Although you should have been testing and packaging your code all the way through your Sprint 1 development, preferably using an automated process, you still need to test and package with stable unchanging code. This is where you do what at SSW we call a “Test Please”. This is first an internal test of the product to make sure it meets the needs of the customer and you generally use a resource external to your Team. Then a “Test Please” is conducted with the Product Owner to make sure he is happy with the output.

You can read about how to conduct a Test Please on our Rules to Successful Projects:

Do you conduct an internal "test please" prior to releasing a version to a client?

Figure: If you find a deviation from the expected result you fix it on the Release branch.

If during your final testing or your “Test Please” you find there are issues or bugs then you should fix them on the release branch. If you can’t fix them within the time box of your Sprint, then you will need to create a Bug and put it onto the backlog for prioritization by the Product owner. Make sure you leave plenty of time between your merge from the development branch to find and fix any problems that are uncovered.

This process is commonly called Stabilization and should always be conducted once you have completed all of your User Stories and integrated all of your branches. Even once you have stabilized and released, you should not delete the release branch as you would with the Sprint branch. It has a usefulness for servicing that may extend well beyond the limited life you expect of it.

Note: Don't get forced by the business into adding features into a Release branch instead that indicates the unspoken requirement is that they are asking for a product spin-off. In this case you can create a new Team Project and branch from the required Release branch to create a new Main branch for that product. And you create a whole new backlog to work from.

Figure: When the Team decides it is happy with the product you can create a RTM branch.

Once you have fixed all the bugs you can, and added any you can’t to the Product Backlog, and you Team is happy with the result you can create a Release. This would consist of doing the final Build and Packaging it up ready for your Sprint Review meeting.

You would then create a read-only branch that represents the code you “shipped”, commonly referred to as RTM(Released to Market). This is really an Audit trail branch that is optional, but is good practice.This is really an Audit trail branch that is optional, but is good practice.

You could use a Label, but Labels are not Auditable and if a dispute was raised by the customer you can produce a verifiable version of the source code for an independent party to check. Rare I know, but you do not want to be at the wrong end of a legal battle. Like the Release branch the RTM branch should never be deleted, or only deleted according to your companies legal policy, which in the UK is usually 7 years.

Figure: If you have made any changes in the Release you will need to merge back up to Main in order to finalise the changes.

Nothing is really ever done done until it is in Main. (see common misconceptions of done here and here). You need to do a Reverse Integration merge from the Release Branch into Main to carry the bug fixes over into the next sprint.

Your Sprint is now nearly complete, and you can have a Sprint Review meeting knowing that you have made every effort and taken every precaution to protect your customer’s investment.

Note: In order to really achieve protection for both you and your client you would add Automated Builds, Automated Tests, Automated Acceptance tests, Acceptance test tracking, Unit Tests, Load tests, Web test and all the other good engineering practices that help produce reliable software.

After branching Main to Release, we generally recommend not doing any subsequent merging (FI) from Main into the release branch.

In our guidance we suggest that once you are ready to release your code, you would branch Main to Release (making the vCurrent). This allows you to open Main for vNext development and stabilization.

If you later decide to merge hotfixes or service pack changes from Release to Main, you should be careful how you do this. It would probably NOT be a good idea to follow the same pattern we recommend for development (do one last FI from Main to Dev before doing the RI from Dev to Main). Doing one last FI from Main to Release would risk bringing vNext changes into Release.

Note – vNext might mean sprintNext, but I think the same considerations apply. For vCurrent, especially after doing some hotfixes, the Release branch should be at a higher level of quality and stability than the Main branch. You don’t want to bring vNext code into the vCurrent Release branch any more than you want to bring vNext Feature code from Dev to Main before it passes quality gates in the Feature branch.

- Bill Heys, VS ALM Ranger & TFS Branching Lead, Microsoft

Bill’s comments are quite pertinent here as you may think it is a good idea to do another forward integration to bring new features from Main into an existing Release. You can do it, its not recommended, but be very very careful.

Figure: After the Sprint Planning meeting the process begins again.

Where the Sprint Review and Retrospective meetings mark the end of the Sprint, the Sprint Planning meeting marks the beginning. After you have completed your Sprint Planning and you know what you are trying to achieve in Sprint 2 you can create your new Branch to develop in.

How do we handle a bug(s) in production that can’t wait?

Although in Scrum the only work done should be on the backlog there should be a little buffer added to the Sprint Planning for contingencies. One of these contingencies is a bug in the current release that can’t wait for the Sprint to finish. But how do you handle that?

Willy-Peter Schaub asked an excellent question on the release activities:

In reality Sprint 2 starts when sprint 1 ends + weekend. Should we not cater for a possible parallelism between Sprint 2 and the release activities of sprint 1? It would introduce FI’s from main to sprint 2, I guess. Your “Figure: Merging Sprint 2 back into Main.” covers, what I tend to believe to be reality in most cases.
- Willy-Peter Schaub, VS ALM Ranger, Microsoft

I agree, and if you have a single Scrum team then your resources are limited. The Scrum Team is responsible for packaging and release, so at least one run at stabilization, package and release should be included in the Sprint time box. If more are needed on the current production release during the Sprint 2 time box then resource needs to be pulled from Sprint 2.

The Product Owner and the Team have four choices (in order of disruption/cost):

Backlog: Add the bug to the backlog and fix it in the next Sprint
Buffer Time: Use any buffer time included in the current Sprint to fix the bug quickly
Make time: Remove a Story from the current Sprint that is of equal value to the time lost fixing the bug(s) and releasing.
Note: The Team must agree that it can still meet the Sprint Goal.
Cancel Sprint: Cancel the sprint and concentrate all resource on fixing the bug(s)
Note: This can be a very costly if the current sprint has already had a lot of work completed as it will be lost.

The choice will depend on the complexity and severity of the bug(s) and both the Product Owner and the Team need to agree. In this case we will go with option #2 or #3 as they are uncomplicated but severe bugs.

Figure: Real world issue where a bug needs fixed in the current release.

If the bug(s) is urgent enough then then your only option is to fix it in place. You can edit the release branch to find and fix the bug, hopefully creating a test so it can’t happen again. Follow the prior process and conduct an internal and customer “Test Please” before releasing.

You can read about how to conduct a Test Please on our Rules to Successful Projects:

Do you conduct an internal "test please" prior to releasing a version to a client?

Figure: After you have fixed the bug you need to ship again.

You then need to again create an RTM branch to hold the version of the code you released in escrow.

Figure: Main is now out of sync with your Release.

We now need to get these new changes back up into the Main branch. Do a reverse and then forward merge again to get the new code into Main. But what about the branch, are developers not working on Sprint 2? Does Sprint 2 now have changes that are not in Main and Main now have changes that are not in Sprint 2? Well, yes… and this is part of the hit you take doing branching. But would this scenario even have been possible without branching?

Figure: Getting the changes in Main into Sprint 2 is very important.

The Team now needs to do a Forward Integration merge into their Sprint and resolve any conflicts that occur. Maybe the bug has already been fixed in Sprint 2, maybe the bug no longer exists! This needs to be identified and resolved by the developers before they continue to get further out of Sync with Main.

Note: Avoid the “Big bang merge” at all costs.

Figure: Merging Sprint 2 back into Main, the Forward Integration, and R0 terminates.

Sprint 2 now merges (Reverse Integration) back into Main following the procedures we have already established.

Figure: The logical conclusion.

This then allows the creation of the next release.

By now you should be getting the big picture and hopefully you learned something useful from this post. I know I have enjoyed writing it as I find these exploratory posts coupled with real world experience really help harden my understanding.

Branching is a tool; it is not a silver bullet. Don’t over use it, and avoid “Anti-Patterns” where possible. Although the diagram above looks complicated I hope showing you how it is formed simplifies it as much as possible.

Both branches and workspaces (i.e. single branch) allow you to ‘isolate’ code – a branch isolates code on the ‘server side’, a workspace isolates code on the ‘client side’. Yes it’s true code is isolated only as long s it lives in your workspace, so you might break the build once the code is checked in. But the same is true for branches. A branch is not used by individuals but typically by entire teams so the likelihood of conflicts exists just the same, but now you also have the potential of merge conflicts.

There are good reasons to use branches (for example if you have the need to maintain multiple releases) but in many cases there is no real need. Whether or not you have conflicts has a lot to do with your system architecture or work practices. Changes made to a poorly architected solution will ripple through your solution and affect other team members, no matter how elaborate your branching structure is. If multiple team members modify the same components it inevitable to have lots of broken builds. The solution is not to create a fancy branching structure, but to restructure your team around the components and/or improve the system architecture (if possible of course).

The question should not be “what is the most appropriate branching structure?”, but what is the best way to minimize code conflicts. Branching is ONE option to achieve this.
-Chris Birmele, Visual Studio ALM Ranger, Microsoft

Technorati Tags: Branching Scrum ALM TFS 2010 VS 2010 SSW SP 2010 TFS SharePoint