Saturday, February 25, 2006

Upgrading form VSS to VSTS

VSTS comes with a dedicated utility for migrating VSS database into VSTS Source Control
C:\Program Files\Microsoft Visual Studio 8\Common7\IDE\VSSConverter.exe

There is 2 things you must know before go into migration...

  1. You must have Visual SourceSafe 2005 installed on the machine you're running VSSConverter from. Unfortunately, VSSConverter has some dependencies on DLLs in VSS 2005. You can uninstall VSS 2005 once you're done with the migration, but you must have it installed when running VSSConverter.

  2. You must have SQL Express installed and enabled on the machine you're running VSSConverter from. This isn't exactly obvious from the documentation, but VSSConverter uses the local SQL instance as a scratch database during the conversion. If there's no local scratch database, the migration will bomb with cryptic SQL errors.

VSSConverter have two primary commands: analyze and migrate.

Instead of passing a bunch of cryptic command line switches, you'll pass a bunch of slightly-less-cryptic XML.

VSSConverter analyze settings.xml will start Analysis
Sample of the XML template used for analysis
<?xml version="1.0" encoding="utf-8"?>
<SourceControlConverter>
  <ConverterSpecificSetting>
    <Source name="VSS">
      <VSSDatabase name="d:\vss-test\"></VSSDatabase>
    </Source>
    <ProjectMap>
      <Project Source="$/" ></Project>
    </ProjectMap>
  </ConverterSpecificSetting>
</SourceControlConverter>


Run the VSSConverter for analysis and you'll get the Analysis Report containing how many files analysis done for and list of errors and warnings found during analysis.

After Analysis is complete, and hopefully nothing major is there you can go on to the Migration process...

VSSConverter migrate settings.xml will start Migration
Sample of the XML template used for migration
<?xml version="1.0" encoding="utf-8"?>
<SourceControlConverter>
  <ConverterSpecificSetting>
    <Source name="VSS">
      <VSSDatabase name="d:\vss-test\"></VSSDatabase>
      <UserMap name="UserMap.xml" />
      <!--<SQL Server=".\SQLExpress" /> -->
    </Source>
    <ProjectMap>
      <Project Source="$/" Destination="$/Demo/Main/"></Project>
    </ProjectMap>
  </ConverterSpecificSetting>
  <Settings>
    <TeamFoundationServer name="TeamSystem" port="8080" protocol="http"></TeamFoundationServer>
  </Settings>
</SourceControlConverter>



Make sure the VSTS Destination folder you specify is empty or the Migration will fail, you can specify a folder that doesn't exists and it'll create it for you ...

Run the VSSConverter for migration and you'll get the Migration Report containing how many files migrated and list of errors and warnings found during migration.

Well ... you are migrated now ... however, VSSConverter isn't magic -- it can't convert everything. If you've used branching, sharing, or pinning in Visual SourceSafe, don't expect that to convert well...

  • Sharing is not supported in Team Foundation source control. Shared files are migrated by copying the version of the file at the time sharing began to a destination folder. From then on, the changes made to the shared file are replicated to both copies.

  • Branching a file. Because sharing is a pre-condition of branching, the migration of a shared file results in copying the file to the destination folder. After the branch event, the changes to any branch are migrated to the respective copy in Team Foundation source control.

  • Pinning is not supported in Team Foundation source control. To help you locate items in the Team Foundation source control repository that were once pinned in the SourceSafe database, the converter tool assigns a “PINNED” label to the version that was pinned.

Saturday, February 11, 2006

Work Item Tracking in Microsoft Visual Studio 2005 Team System

Work item tracking (WIT) is a feature included with Microsoft Visual Studio 2005 Team System that helps not only developers, but also project managers, analysts, and testers. As the name implies, work item tracking provides a means of tracking the various items that individuals involved in development projects must work on.

Work items are no different than the task lists that are kept in project plans, bug lists, and feature lists. What is different is how the work item tracking system is integrated with the rest of Visual Studio Team System.

Team Explorer Window
Visual Studio Team Editions (Architect, Developer, Test, and Team Explorer) include the capability to connect to a Team Foundation Server (TFS). Users can add Team Projects to TFS, using their Team Explorer window.

The Team Explorer window allows the user to view and create new work items (see Figure 1). The work item data and the various work item types are defined by your chosen methodology template. When creating a new Team Project, the option is given to select a methodology template to use for the project. For example, selecting MSF for Agile Software Development creates several standard work items as part of the process. In addition, MSF for Agile Software Development makes use of five distinct types of work items: Scenario, Task, Quality of Service Requirement, Bug, and Risk. The Team Explorer window makes up the Team Explorer application, also referred to as the Team Foundation Client.


Figure 1. Add new work items

Project Management with Work Items
Project managers are probably the most familiar with the concept behind work item tracking. A good portion of their job entails creating and managing various tasks. They are usually responsible for mapping out all the tasks that need to be completed on a development project. The work item tracking system in Visual Studio Team System will allow them to take the work they currently do, and interact more efficiently with the rest of the team.
As part of the creation of a new Team Project, the project manger will select the appropriate process template. The process template will provide the definitions for the work item types, the initial work item list for the project, and other supporting information such as document templates and process guidance documentation. The selection is based on the type of project being undertaken. For example, a small informal Intranet Web application may be based on a less formal process, such as MSF for Agile Software development, whereas a more intensive project such as an airplane flight control system will require a more formal process, such as MSF for CMMI Process Improvement. The selection of the process template is important, because it can't be modified during the project. Future versions of the software can be based on different process templates and, of course, the contents of the work item list and document libraries will be modified during the project.

Project managers who install Team Explorer (formerly called Team Foundation Client) will be able to connect to a Team Foundation Server and import, as well as export, work items from either Microsoft Excel or Microsoft Project. Prior to installing Team Explorer on his or her computer, the project manager will want either (or both) Microsoft Excel or Microsoft Project installed with the optional Microsoft .NET interoperability components. Once installed, there will be a new menu option added to either (or both) Project or Excel, called Work Items (see Figure 2 for an example of this). This menu will allow the project manager to connect to a Team Foundation Server and download work items from any project that they have access to on the server. Once they do this, they can add additional items, change resource assignments, and complete the project plan. When they are ready, they can synchronize their changes with the Team Foundation Server using the Publish Changes option. Any assignments they make to individuals who are using the work item tracking system will be seen by those individuals when they run the My Work Items query from within Visual Studio.
As team members complete tasks, they mark those tasks as complete, using Visual Studio or Team Explorer. The project managers will receive this updated status the next time they synchronize with the Team Foundation Server.

Microsoft Project Integration
Installing Visual Studio Team System or the Team Explorer application provides extensions for Microsoft Project and Microsoft Excel. Using Microsoft Project, a project manager can retrieve data from Team Foundation Server, use Microsoft Project to manage and plan work, and then publish the updates back to the work item database for consumption by other team members. Figure 2 shows the Microsoft Project extensions that allow synchronization with work items.
The Microsoft Project file itself will generally be stored in a document library in the project team site. This will allow basic version control of the file, as well as make it available for other users to review.


Figure 2. Work item integration with Microsoft Project

Business Analysis with Work Items
Business analysts can also become more integrated in the development process by having their work managed through the same work item tracking system as the rest of the team. The various types of documents that are produced by business analysts should be stored on the team project portal. For instance, the creation of a requirements document could be a task assigned to a business analyst. Once compete, that document can be stored within WSS, and the business analyst would mark the work item as completed. A new work item can be created to actually implement that requirement, and a link can be set up from the work item to the actual requirements document on the WSS site. This allows the developer assigned the task to quickly navigate to and review the associated documentation. In order for business analysts to interact effectively with the work item system, they will need to install Team Explorer and have a client access license for the Team Foundation Server.

Developers
Developers and testers will be greatly impacted, from a workflow perspective, by the introduction of work item tracking. The system was designed to make the use of work items by developers as seamless as possible. Rather than being notified by e-mail, spending hours in planning and status meetings, or looking at the project plan, the developers will receive their work assignments from within Visual Studio. They will simply use the Team Explorer window to run the My Work Items query (Figure 3).


Figure 3. Work item list in Visual Studio 2005 Team Edition for Software Developers

Developers can begin their day by viewing their work items. As they work on tasks, they can update the status of their work items in two different ways. First, they can edit the work item information directly from within Visual Studio by simply selecting the work item they wish to edit from the list of work items. In this case, they can directly enter data such as status updates, or modify any other field exposed in the work item. Depending on process customizations, individual fields may be protected in such a way that other roles can set the work item field values but development can only read them, as may be the case when a bug work item is prioritized by a project manager or tester. Likewise, some fields may be modifiable by developers and not by other roles. Figure 4 shows a sample work item detail screen including a custom field Start Date added to the default MSF for Agile Software Development process. Additional information on customizing work items in Visual Studio Team System is provided later in this document.


Figure 4. Work item details in Visual Studio 2005 Team Edition for Software Developers

The second way to update the status of a work item is as a side-effect of the check-in process. When combined with Team Foundation Source Control, several powerful capabilities are added. Depending upon the policies defined for the Team Project, the check-in process may allow or require developers to link a work item to a changeset (a collection of files checked in as a group) during the check-in process. As developers complete their coding tasks, they simply associate code check-ins with work items.

For example, imagine that a developer has a coding task called "implement customer feedback form." When the developer completes this task and checks in his or her work, he or she has the option of associating that work item to the checked-in code. All of the different files that are checked in are called a changeset, and the work item will be associated with the changeset, not the individual files. The work items can simply be associated, or marked as resolved. Figure 5 provides a sample of how the work item is associated with the changeset during check-in.


Figure 5. Associating work items at check-in

This is a simple process and allows the work item status to be automatically updated. This updated status can then be used by the project managers when they synchronize their project plan. The associated work items will also be used in build reports that can be automatically generated and distributed as part of an automated build process using Team Build. This will allow testers to know precisely what items they should be testing in a new build.

Work Item Check-in Policy
Work item associations can be implemented and enforced in check-in policies. Check-in policies enforce certain behavior when team members attempt to check items into the source control system. One of the standard policies that can be enabled would require developers to associate a work item with all code check-ins. This ensures that all development efforts are tracked and visible. There is an option of overriding the policy, and notification can be set up to alert the project manager (or someone else) of the override.


Figure 6. Adding check-in policies

Bugs and Issues as Work Items
Using classic development practices, developers and testers perform work from several different sources. The project plan schedules work such as developing code and writing test plans. Separate lists are kept and scheduled outside of the project plan, to handle defect tracking, enhancement requests, issues, and risks. Project managers may set aside buckets of time to allow team members to work on these other lists, or they may create separate project plans. Regardless, the management of different types of work for the same development resources is cumbersome and error prone.

Since the work item tracking from Team System allows flexible and customizable tracking of all types of work in a single repository, managing these different types of tasks becomes easier. Different types of work items can be managed separately through different work item queries. However, since they are in the same Team Project, a work item list for a developer could have new development tasks, research tasks related to project risks, and bug fix tasks; all of them could be prioritized side by side and worked from a single list.

Testing
As implied in previous sections, testers also get significant integration in the overall development lifecycle as a result of work item tracking. Testers using Visual Studio Team Edition for Software Testers have full access to Team Explorer to view their own work items. For instance, many projects require the creation of manual test cases. These manual tests are created and managed in Visual Studio Team Edition for Software Testers. What test cases need to be written, and the status of those test cases, can be tracked by the work item tracking system. The project manager can then synchronize in order to track and manage the efforts of the test team as well as the developers. Testers follow the same process as developers do, and work on the tasks delegated to them through the work item tracking system. The manual test cases they develop would be checked into source control and can be associated with work items in the same fashion as developer code.

In addition, testers are able to review build reports to find out what features are ready to test. As developers complete development tasks and associate their code check-ins with work items, those relationships are stored by the Team Foundation Server. During the build process, the status of these work items can be updated to indicate that they are completed and included in the build. Those items included in the build are ready for test. By running a build report, a software tester will know exactly which work items they should focus their testing efforts on. Those work items could be requirements, bugs, or some other type of task.
This, however, is just the beginning. As testers discover problems in the system, they can report these back into the Team Foundation Server, using work items. By issuing a "Bug" or similar custom work item, the tester can record work that needs to be done. These new "Bug" tasks can be routed to a development lead, a project manger, or the appropriate developer, as specified in the process templates. In addition, the tester can set up a work item relationship so that the bug work item is connected to the original work item that he or she was testing against.

When the developer receives the work item assignment and addresses the defect, he or she continues the workflow. The developer's resolved "defect" work item would appear in build reports so that the test team can verify the fix. Since Team Foundation Server is acting as a back end for this entire process, requirements, development tasks, defect reports, and problem resolutions can all be tied together. These items can be traced and reported on with minimal effort from the team members.

Reporting and the Work Item Database
An important aspect of Visual Studio Team System and the Team Foundation Server is the storage of work items. All work item data is maintained by Team Foundation Server in a Microsoft SQL Server 2005 database. In addition to the flexibility, stability, and scalability of this approach, there is a tremendous value from a reporting perspective.
As a result of creating a Team Project based on a specific process template, the project portal exposes appropriate reports. Individuals who are interested in the status of a development project, but not directly involved, can run reports to get the status of development tasks, bug counts, and any other work item or non-work item reports. This is of great value to business users and IT management. The project portal is a WSS team site and contains a Web part that allows viewing of reports created in SQL Reporting Services. The reports available on the site can be customized through the methodology templates.

Work Item Customization
The process templates provided by Visual Studio Team System are highly customizable. Individual organizations and groups are able to modify almost all aspects of the process to be compatible with their own requirements. In fact, some organizations will want to create multiple types of custom process templates tailored to different types or sizes of development projects.
At a high level, the process template architecture provides customization of the following areas:

  • Classification Structure Service (CSS)—Defines the structure for team projects, including the iterations defined for the project lifecycle and the project hierarchy.
  • Group Security Service (GSS)—Defines the initial groups and permissions for the process templates.
  • Reports—Defines the standard reports provided by the process.
  • Source Control (SCC)—Defines the permissions and notes available for source control.
  • Windows SharePoint Services (WSS)—Defines the document templates, document libraries, and the process guidance.
  • Work Items (Currituck)—Defines the type and characteristics of work items, work item queries, a default list or work items for new Team Projects, and the mapping of work items to Microsoft Project.
Within your process templates, the work item tracking system can itself be heavily customized. You have the ability to define your own work item types or, as will typically be the case, refine work item types based on an existing process. For example, instead of the default five work items provided in MSF for Agile Software Development, you may define work item types for: requirements, bugs, risks, and issues. You can name the types of work items whatever you like; for example, perhaps you prefer "Defect" instead of "Bug." You can have as many, or as few, types of work items as you need for your purposes.

In addition, you can actually change the contents of the work item definitions. For example, you may decide that a specific work item type needs additional attributes to make it useful in your environment. Adding a Severity field to your "Defect" work item type is as easy as editing an XML file. In addition, you may specify valid values for your new field (for example, Very Severe and Unimportant). You can also configure how the field is visible, and the permissions required for modifying the value. Additionally, there is support for basic workflow that will allow the Team Foundation Server to automatically impact the value of the field as your work items move through their lifecycle.

As an example of the different fields that are commonly associated with work items, the following list contains the default fields for the "Bug" work item defined by MSF for Agile Software Development, beta 2: Id, Title, Assigned To, Area Path, Iteration Path, History, Reason, Changed Date, Changed By, Created Date, Created By, Summary, Issue, State Change Date, Activated Date, Activated By, Resolved Date, Resolved By, Closed Date, Closed By, Priority, Triage, Test Name, Test Id, Test Path, Found In, and Integration Build. It is nice to note that with all of the fields that may hold data for this work item, many of them are automatically captured during standard processing, without extensive data entry for team members.

Continuous Integration Using Team Foundation Build

What is continuous integration?
Continuous integration is the process of starting a build whenever code is checked into the source control server. It recommends having a dedicated build server where the sources are synchronized, compiled, and unit tests are run.

Software development life cycle processes evolved over time. Development teams realized the importance of having periodic builds; starting with a weekly build, becoming tighter when 'nightlies' began, and even tighter still with 'hourlies.' As the benefits of frequent builds became more visible, organizations wanted more builds more regularly, and started 'continuous integration.' But nightlies still exist; many still rely on them for getting a formal, reliable build.

How to do Continuous Integration Using Team Foundation Build?
Team Foundation Build is the build automation tool in Visual Studio Team System. Built on top of MSBuild, Team Foundation Build integrates with other Visual Studio Team System tools like source control, work item tracking, and test execution to provide an end-to-end build process. It does not provide continuous integration out of the box, but it can be customized to easily do so.

Check out here how you can easily do that...

Thursday, February 09, 2006

Take care while checking out in VSTS …

The term “Check-Out” differs from one system to another; in Visual Source Safe (VSS) it means “Get me the latest version of the file from the server and lock it so no one else can edit it”, while in Concurrent Versioning System (CVS) it means “Get me the latest version”. Now in Team System Source Control Check-Out means “Tell the server I want to edit this file and mark it writeable in my file system” while having an option to lock the file in one of three modes (None, Check-Out and Check-In)

This is a new pattern for VSS users and may cause confusion to some people and make them thing there’s a bug somewhere.

Captured from Martin Woodward – one of the brains behind Teamprise
Martin Woodward – Check Out in Team System

Tuesday, February 07, 2006

TFS RC Installation Guide ...

Although we are still waiting for TFS RC but the Installation Guide appeared on Microsoft Download Center, till RC is officially available it'll be a great chance to start looking at the Guide and be prepared ...

You can go directly to the CHM file link here ...

If you are upgrading from TFS Beta 3 Refresh here is an overview of the process you'll need to follow to be RC:
  • Download the Team Foundation Server RC from MSDN Subscriber Downloads.
  • Download the Upgrade Utility. (This won't work till RC is there)
  • Uninstall Team Foundation Server Beta 3 Refresh.
  • Follow the upgrade instructions, which are included with the Upgrade Utility.
  • Install Team Foundation Server RC.
  • Complete the post install upgrade instructions, which are included with the Upgrade Utility.

TFS RC is here ...

It's finally here ...

Today TFS RC was released on MSDN at last ...

A great step ahead in the revolution ...

Sunday, February 05, 2006

TFS RC ... What's new in it ...

I got a look at some of the biggest changes in TFS RC and here is a summary of such list ...
  • Bug fixes: They’ve found and fixed a ton of bugs. This release is substantially more reliable, stable and performant than Beta3.
  • Friendly name support for Work Items: Active Directory 'Friendly Name' is now used to assign work items insteas of the network account names.
  • Improved SharePoint configuration during install: The #1 issue during installation is ensuring that SharePoint is correctly configured for proper use by TFS.
  • Improved error detection within Setup.
  • Move SQL Reporting Services to the Application Tier: Because Reporting Services requires IIS to be present and many companies do not allow IIS and SQL to run on the same server, The Reporting Services was moved off the data tier in dual server deployments (no change for single server installs).
  • Upgrade utility: A lot of work on the upgrade scripts was done to allow migration of data from Beta3 refresh to both the Release Candidate and the final build of TFS. These scripts will also help migrate your data from the RC to the final bits to allow customers to “go live” with this release.
  • Reports: A lot of improvements to the reporting system were done so that everyone is going to like the changes done :)
  • Admin tools: Same goes for the admin tools.
  • Portal: Number of reports on the main page is reduced and the overall look of the default portal is cleaned up.
  • CMMI Methodology: A bunch of work to bring the CMMI process template up to shipping quality by fixing bugs in the work item templates and reports was done.

Team Foundation Server RC Feb 7th ...

It's almost there ... as noted in Jeff Beehler's Blog :
"... the Team Foundation team signed off on their Release Candidate build ..."
"The CD images have been handed off to the team that handles the uploads to the MSDN download center and according to current estimates, we should have bits available for download sometime on Tuesday, February 7th."

Can't wait to get it ...

Saturday, February 04, 2006

VSTS Great Collaboration …

Borland Software Corporation announced that it will provide one of the first fully-integrated requirements management solution for Microsoft® Visual Studio® 2005 Team System, Borland's award-winning CaliberRM™ requirements management solution is designed to provide Microsoft teams with a comprehensive way to manage requirements throughout the application lifecycle, enabling teams to select the right software projects, apply the right resources and adjust projects as they progress through different phases and roles in the development process.

Quoted from the press release …
“Below are specific use case scenarios of the planned integration of CaliberRM and Visual Studio Team System, as defined by roles within the application lifecycle:
Linking Requirements to Tests – Once analysts enter requirements with CaliberRM, they become visible within Visual Studio Team System with test creation and development tasks linked directly to them. Consolidated test results will be available so analysts can verify not just that code was developed to meet a requirement and tests were created to test a requirement, but that the tests passed and the requirement has been successfully fulfilled.
Developers Implementing Requirements – When a requirement is created or updated in CaliberRM, the changes will immediately become visible within the Visual Studio Team System environment, and development tasks will get assigned to make sure that the product code reflects the latest requirements. When a task gets completed, its status will be available for all team members so the analyst knows the code meets the correct requirements and the tester knows there is new code ready to be validated against the updated tests.
Creating Business Stakeholder Transparency – CaliberRM provides transparency of product status through reports which show requirements, test and development task status. The integration between CaliberRM and Visual Studio Team System allows users to generate reports showing each requirement and test plan associated with the approved requirements as well as the test plan results so business stakeholders can see which requirements are being satisfied in the product for each reporting period. “

Read the full release here ...

Visual Studio Team System Books

Although VSTS is not released yet but VSTS Books started to appeat by both MSPress and by various publishers, these include AW Publishing, Apress and Wrox to name a few.

Take a look at 4 of the great books to come ...
  1. Working with Microsoft® Visual Studio® 2005 Team System by Richard Hundhausen
  2. Pro Visual Studio 2005 Team System by Jeff Levinson & David Nelson
  3. Professional Visual Studio 2005 Team System by Jean-Luc David, Tony Loton, Brady Gaster, Erik Gunvaldson, Noah Coad
  4. Software Engineering with Microsoft Visual Studio Team System by Sam Guckenheimer

Wants to know about VSTS??

Take MS Clinic 2551: Introduction to Visual Studio Team System, which will offer you the following:

  • Introduction on Visual Studio Team System
  • Managing the Software Development Life Cycle
  • Introduction to Visual Studio Team System Features
  • Using VSTS Tools Across Multiple Roles
  • Using VSTS Tools to Support the SDL Process
  • Automating Reporting and Status Using VSTS
Go take it here ...