Scrum FAQ

Team System FAQ

What's New in version 1.2

Upgrade Process to version 1.2

from v1.1

If you are upgrading from v1.1 - we recommend you update the installation of Scrum for Team System to v1.2 as per the steps below, but you do not need to migrate your work items into a new team project as no changes have been made to the process template itself.

To get the latest reports, you will find a "Report Installer" utility that is available on your start menu (in Scrum for Team System > Admin Utilities) after you have installed the Admin Utilities package from within the download.

from v1.0
the upgrade process from v1.0 to version 1.2 of Scrum for Team System is as follows:

Download Scrum for Team System version 1.2 Uninstall v1.0 from the TFS server Install v1.2 on the TFS server Install the v1.2 admin utilities Create new Team Projects Set up Teams and Environments (optional)
Disable the "Scrum Eventing Service" Migrate your data Enable the "Scrum Eventing Service" Migrate Source Control (optional)

Download Scrum for Team System v1.2

You can download v1.2 from www.scrumforteamsystem.com. The download is a zip file containing two installers: the main installer (named ServerComponents) installs the Scrum plugin itself on the server; the AdminUtilities installer installs admin utilities such as the migration utilities.
Back to top

Uninstall v1.0 from the TFS server

Version 1.0 needs to be uninstalled before version 1.2 is installed. Uninstalling version 1.0 does not remove your v1.0 Team Projects: these are completely unaffected apart from the fact that the Sprint and Product Burndown charts will not work again until you install version 1.2 (this is because the uninstall removes the DLL that draws trend lines; the v1.2 install inserts its own version of this DLL but also reinstates the v1.0 version.)

Having logged onto the TFS server as the TFSSetup user, to uninstall v1.0:

Use Add/Remove programs from within Control Panel.

Install v1.2 on the TFS server

Run the main v1.2 installer on the TFS server. The v1.2 installer has exactly the same interface as previous versions of the installer, i.e. the only user input is the option to choose a different location on disk for the plugin.
Back to top

Install the v1.2 admin utilities (optional)

Run the v1.2 AdminUtilities installer to install the utilities on each client-side machine where these are required. The machines used must already have Team Explorer installed.

To use the utilities, you must have a network connection in the same domain as the TFS server and generally be in the Project Administrators role. We recommend only installing these utilities for the TFSSetup user on your TFS Application tier server.

Back to top

Create new Team Projects

Create a new Team Project for each of your existing v1.0 Team Projects. The penultimate step of the Project Creation Wizard asks if you want to use source code control. Switch this on if you want to create a source code control folder for this project. See the Migrate Source Control step for more details.
Back to top

Set up Teams and Environments (optional)

Use the List Manager utility to set up Teams and Environments for each new Team Project. The Team and Environment names for each project should match the existing names (if any) in the v1.0 projects to be migrated.

Where a Product Backlog Item is owned by a Team in a v1.0 project, the PBI will continue to be owned by that Team after the migration provided that the available Team names match. PBIs with unmatched Team names will be not be associated with any Team after the migration.
Back to top

Disable the Scrum Eventing Service

The Scrum Eventing Service is a webservice installed on the TFS application tier server to keep the Work Remaining in sync between Product Backlog Items and Sprint Backlog Items. It must be disabled prior to a migration to avoid unpredicable report results.

To disable the Scrum Eventing Service, open a command prompt and issue the following commands:

c:
cd "\Program Files\Conchango\Scrum for Team System\tools"
EventSubscriber /U /TFSName http://localhost:8080

Migrate your data

For each pair of v1.0 and v1.2 Team Projects, run the Migration Utility.

This allows you to choose a TFS server, and then choose a pair of projects: one from a list of existing projects; one from a list of new, empty projects.

There is also a checkbox to allow you to request a rebuild of the Warehouse at the end. If you are migrating multiple projects, leave this unchecked until you are migrating the last project. There is no harm in having a Rebuild after each project has been migrated, but it saves time to just do it once at the end.
Back to top

Migrate Source Control (optional)

If your v1.0 project used TFVC (Team System's source code control system) and there were any changesets associated with any of its Work Items, then the same changesets will be associated with the same Work Items in your new 1.1 project.

At this point you can consider the migration complete, if you wish, but it is important to understand how TFVC organises source code control:

If you create a Team Project and choose to switch source code control on, TFVC creates a source code control folder based on the Team Project name, e.g if the Team Project is called ABC123, the TFVC folder will be $/ABC123.
If you create a new C# or VB.NET project and then decide to add it to source control (right-click and choose Add Project to Source Code Control), TFVC displays a list of source-code-enabled Team Projects for you to choose from. The resulting folder combines both names, e.g. if you add MyProject to Team Project ABC123, the TFVC folder will be $/ABC123/MyProject.

Suppose you decide to create a new Team Project called DEF456 and migrate all the data from ABC123 across. After the migration, all the changesets in the old project also appear in the new project. However, if you drill down through the changeset links, you find that the TFVC folder is still $/ABC123/MyProject.

There is nothing to stop you leaving it like this: if you make further changes to MyProject and check them in you will create changesets that you can link to Work Items in DEF456.

However, you may decide that you would prefer to have future changes recorded against a TFVC folder called $/DEF456/MyProject. You can set this up as follows:

Select MyProject in Solution Explorer.
From the File menu, select Source Control then Change Source Control (you can also select this directly if you have the Source Control toolbar visible).
Make sure everything is selected and click the Unbind button to disassociate MyProject from ABC123
Go back to MyProject in Solution Explorer, right-click on the project and select Add project to source control then Select different location. Navigate to DEF456 and select it.

As far as Solution Explorer is concerned, performing this process effectively resets source control history: if you choose View History for any source file in your C# or VB.NET project, you will only see history for updates made since the changeover.

Team Explorer has a different view. As you make new changes, new changesets are created that you can link to your Work Items. If you drill through one of these changesets, you will see source code information from the new source control project. However, if you drill through one of the changesets from before the changeover, the source code information comes from the old source control project.
Back to top

Enable the Scrum Eventing Service

To re-enable the Scrum Eventing Service, open a command prompt and issue the following commands, replacing the items in BOLD with those specific to your environment:

c:
cd "\Program Files\Conchango\Scrum for Team System\tools"
EventSubscriber.exe "/I" "/TFSName" "http://SERVERNAME:8080" "/UserCredentials" "DOMAIN\TFSSETUP" "/EventType" "WorkItemChangedEvent" "/SoapEndPoint" "http://SERVERNAME/Scrum.Eventing.Service/SprintBacklogItemChanged.asmx" "/FilterFilePath" "FilterExpression.txt".

Related Links