Creating a New Version of an Existing Application | Professional Team Foundation Server

The completion of the entire development lifecycle will often spawn into a new project. How do you deal with setting up a version 2.0 and what are some of the best practices for Team System? Here is a little bit of guidance:

Create a New Team Project

The logical place to start is creating a new team project. This will allow you to designate new work items for your project (thus isolating them from the previous project). You can also assign new team members and a new workflow based on process improvement strategies outlined in this book.

There may be some circumstances where you will want to start development of your new version of an existing project within an existing team project. The main determination of whether a new team project is warranted should be based on factors such as the following:

Team members - If the personnel will remain relatively the same on both projects, then you can have the choice of either starting a new team project or sticking to the existing one. If you are starting with a considerably different team, then we would recommend starting a new team project.
Process - If your new project is substantially different from original one (for example, you are creating a Web-based version of a WinForms application), then creating a new team project makes sense. If you want to build the new application using a process that differs from the original project (for example, you used Extreme Programming on the first project and now you want to implement Scrum on the derivative project), then a new team project is of course warranted.
Version control and workflow isolation - One of the advantages of starting a new team project is to isolate a new project. For example, a new project will contain new iterations and features; when combined with an existing project it may add up to a lot of assets to manage.
Complexity - If you have a huge number of work items, or your version control tree for the existing project has grown, adding yet another project on top of it may make it hard to manage. Creating a new team project will allow you to simplify the process. In the case of source code, a single branch will be created using your stable release from the previous project. From a work item perspective, all the new work items will be scoped within the new project, allowing you to isolate them effectively.

There are other considerations, but this list should get you in the right mindset. The main argument for wanting to start over with a new team project is process improvement. You can apply the outcomes and action items from the postmortem investigation to the new project, and benefit from lessons learned.

In approaching a new team project, you should keep in mind the Team System's application. limits. For example, Team Foundation Version Control can maintain 10GB of source code, with a theoretical limit of 250GB. For a complete list of features and theoretical limits, please refer to the MSDN Web site (http://msdn2.microsoft.com) and this blog post by Brian Harry: http://blogs.msdn.com/bharry/archive/2005/11/28/497666.aspx.

You may want to continue a project within an existing team project if you are working with the same development team using the same process, and complexity is not an issue.

Implement Version Control Migration

When you run the New Team Project Wizard, it provides the option of copying an existing branch as the basis for your new project. This is the perfect launch pad for a V2 because your production code is ostensibly very mature. Figure 17-6 shows the dialog in question, where a project called CreditCardV2 is created based on a branch called CreditCardV1.

image from book
Figure 17-6

You may refer to Chapter 12 for more information about how to set up and manage Team Foundation Version Control.

Migrate Workflow

Team System enables you to transfer work items one-by-one by right-clicking each one and then using the Create Copy of Work Item option. (You can obtain it by right-clicking on a work item from a query result.) Of course, if you have more than 50 work items (which is likely in any active project) the one-work-item-at-a-time approach will not scale. The main strategy for migrating your work items en masse is creating a custom application using the extensibility API. Eric Lee has created a project on GotDotNet.com called the Team Foundation Server Work Item Utility. You can download the source code and the functional application at the following link: gotdotnet.com/codegallery/codegallery.aspx?id=.

Bulk Migration of Work Items

When we say migrating work items, we mean to copy them over from one project to another. Team System does not allow you to delete work items from a team project per se (for auditing purposes). Another strategy for moving your work items from one project is to use an Excel spreadsheet. Here is an overview of the process:

Create two spreadsheets: one for your existing team project (Project A) and one for your new team project (Project B
For the Project A spreadsheet, connect to Team Foundation Server (using the New List option (Team⇨New List), then select the All Work Items query to get all the work items from Project A.
For the Project B spreadsheet, connect to Team Foundation Server and select the Input List option, which creates a blank spreadsheet ready for new work items.
Select and copy the work items in Project A you want to copy over to Project B.
Paste the work items from Project A into Project B.
Click Publish in the Project B spreadsheet.

You may receive validation errors, especially if the status of some work items is set to Resolved. The reason being is that new work items can only start with the Active status. Also, keep in mind that you can transfer only those work item types that are supported in both projects. For example, you can't transfer an MSF for CMMI Process Improvement Review work item to an MSF for Agile Software Development project (which doesn't contain that work item type).

You can use Microsoft Project to do a work item migration. We recommend you look at the post by Yogita Manghnani on the Microsoft Forums at http://forums.microsoft.com/msdn/showpost.aspx?postid=273633 to associate an .mpp file from one Team Project to another:

If you are working on an especially complex migration (for example, a half-million to millions of work items), we would highly recommend you contact a Team System consultant or specialist to assist.

Migrating Other Assets

You might also opt to migrate assets, such as check-in policies, project alerts, and other extensibility changes you made to the original project.

Of course, you must, do all the normal setup tasks within your project such as setting up your permissions, setting up your new feature areas, and so forth.