Migrating to Team Foundation Server 2010: Preamble

About a year ago, I led an effort to introduce the organization where I work to automated unit testing, continuous integration and automated deployment as part of the development process. We implemented CruiseControl.NET, wrote and refined dozens of NAnt scripts, and in the end, established a working CI environment for our project, complete with nightly builds, one-click deployment to our test environment, and execution of NUnit tests, code analysis and creation of API documentation.

This year, Microsoft released Visual Studio 2010, and with it a new release of Team Foundation Server, and our team has all come together to work towards implementing TFS into our environment. With that implementation, the existing CruiseControl.NET build environment will give way to TFS Build, and I will use this blog to document and share the planning, process and lessons learned as part of migrating a medium sized application in to TFS as Team Projects.

In the coming weeks, we’ll be making decisions about things such as:

  1. How to structure our projects in TFS Source Control.
  2. How to organize our Solutions and Team Projects.
  3. How to map our current CI process to the TFS Build workflow.
  4. How to manage our Agile/Scrum process using TFS Work Items.

As a prelude, here’s a brief overview of the application we’re working with.

Ours is an intranet application for project management and workflow handling. The basic structure follows a n-Tier architecture, though we are using Dependency Inversion. The component parts include:

  • An ASP.NET Web site project
  • A Utility library for common functions.
  • A DataAccess library for database access.
  • A Workflow library for common workflow functions.
  • A Core library, defining our business entities, data access interfaces, and service methods.
  • A Data library, which implements our actual database calls.
  • A Controller library, which is a go-between for the Web Site pages and our Core layer.
  • 2 libraries containing integration to 3rd party product APIs.
  • Several unit Test libraries for the Core, Controller and Workflow libraries.

All told, our Visual Studio solution contains 16 projects.

We also have a project containing our common NAnt build scripts and CruiseControl.NET configuration files, and each individual project has a NAnt build script governing the build for that assembly.

The Utility, DataAccess and Workflow assemblies are shared with other applications.

Finally, we have about a half-dozen 3rd party Assemblies that we use, which includes the Microsoft Enterprise Library, Telerik UI controls, and Aspose Word.

In planning our migration, we must be able to continue to allow the Shared Assemblies to be accessible and used by other projects, as well as maintain all the functionality NAnt and CC.Net provides.






Leave a Reply