VSTS


Many people are having problems installing Team Foundation Server 2008 with an (existing) installation of SQL Server 2008.
The problem is that the TFS RTM 2008 does not support SQL Server 2008;
SP1 provides that support and you can get it from MSDN downloads, but SP1 only works over an existing TFS installation. So, this is a problem.

The workaround is to merge the setups to make SP1 an installable, with the steps below:
1. Copy the AT folder from the TFS install disk to your hard-drive, say C:\TFS_AT as the .
2. Extract SP1 to your hard-drive, the
Run the command from the SP1 folder: TFS90sp1-KB949786.exe /extract:C:\TFS_SP1
3. Combine installable and SP1
Run: msiexec /a \vs_setup.msi /p \ TFS90sp1-KB949786.msp TARGETDIR=
4. Run setup.exe from the

Source blog: http://blogs.msdn.com/aabdou/archive/2008/05/13/team-foundation-server-sp1-beta-now-available.aspx

To read more about the features added in SP1, check:
http://blogs.msdn.com/bharry/archive/2008/04/28/team-foundation-server-2008-sp1.aspx

Advertisements

In order to provide non-Visual Studio users (like business folks and clients) access to the Matrix, there are a few options available from Microsoft and third-parties.

The two I’ve tried and will talk a bit about are Team Foundation Client and TeamPlain. There are other tools out there too, but I haven’t looked at them and don’t plan to. (Sorry!)

The out-of-the-box option offered by Team System is the Team Foundation Client, which is essentially the TF Explorer plug-in. But this requires an install on the user’s machine which is always an overhead, since it involves IT folks and help-desk, etc.

To address that issue (I guess), Microsoft recently acquired a company called devBiz which has a product called TeamPlain to provide web access to TF. It is a pretty slick-looking website product that hooks into TF at the back-end.

The TFC install did not work for me “as-is” from the MSDN DVD because the paths expected by the setup program are different from the actual paths on disc. Doh! The workaround for this is to copy the install folder on a drive and copy/move required folders as you come across the “not found” error messages. I came across 3 errors. Does this mean better QA is required?

The TeamPlain install went pretty well but fyi, it does need an install of TFC on the web-server hosting TeamPlain. (I’m guessing TeamPlain is exploiting some APIs provided by some component in TFC.). I installed TeamPlain on the TF server itself and some companies might have a problem with that configuration because it might pose a security risk, and for that it is possible to configure a separate web-server to host TeamPlain.

The UI of TeamPlain is pretty slick but I think it is too cluttered and could be dumbed-down for business users or maybe specialized for different users. I also got some crazy errors at times while accessing Source Control (SOAP exceptions for Network Service while authenticating) but these could be due to our network glitches too.
One thing that bugged me, but I understand that it’s a transition period, was the web pages that opened up when I clicked the “Buy License”, etc. links. They just take you to a page announcing the buy-out. How about letting me know in a nutshell about licenses (if I need them anymore or whatever) first?

I am playing with it at the moment and will write about any issues I come across later.

An important factor in using TS effectively is having the right Team Project design and having a solid plan for Configuration Management.

It is important to understand major issues related to projects and TS features because a bad design can cripple your development process, and you might have to start over.

A good starting point is to know the scope of a Team Project and what it contains, and to understand how branching and merging works with this. There are many good articles with related information but I have not come across any advice on a solution.

So, I’ll try to explain what I designed and why and leave you to read about Team Projects and merging/branching.

As you may know, a Team Project is a container for items like source control, work-items, documents, etc. What these items could be is configurable at a higher level with Templates (there are 2 provided out of the box). Project reports, documents, etc. are available at a Team Project level. Most dev teams work on a number of products which are maintained over time and enhanced over release cycles, mostly with parallel development. Instinctively, one would think of having 1 Team Project per Product and also maybe 1 Team Project per release in order to manage a release tightly and eventually do some merging across releases, etc.

Unfortunately, there are limitations of not being able to move artifacts like Work Items, etc. across Team Projects and one has to consider the implications of those before running off and happily creating Team Projects. It is likely that different products share features or a part of the code-base and bug-fixes or enhancements need to be propogated across projects. In most realistic situations, a bug (read Work Item) slated for 1 release may get pushed to another. Given the limitations and requirements, the conclusion is to have 1 Team project for the entire Product line, assuming these Products are similar and share features and the code-base.

The downside of this is that the Team Project is one mother-lode and granularity is lost at a product or release level. I hope the limitations are addressed in future TS versions, but till then one might have to customize Reports and other things to get information at a Product/Release level. If you have other ideas or workarounds, please post them.

Given the assumption of using 1 Team Project, I will talk about Configuration Management (branching/merging, building, etc.) later…

One of the interesting projects I’m currently leading is deploying VSTS in-house and coming up with a plan to migrate to it and change our processes to eventually use it for our SDLC.

We have planned the move in several phases.

Phase 1 (underway) consists of deploying the infrastructure and system, migrating some legacy code from VSS and supporting new .NET 2.0 projects.

Phase 2 will include getting more groups on board (DBA, Claims processing, etc.) and incorporating a daily build for Continuous Integration.

Phase 3 will include extending the use to Product Management and Project Management and using work-items and portal features.

I will talk about the different pieces and activities in coming posts and hopefully that will help some of you out there.

Stay tuned…