It’s alive! Team Foundation Server at Readify
March 20, 2006
We’ve been running an instance of Team Foundation Server (BETA 3) up on a virtual machine at Readify for about five months and a few people – especially Darren, have taken full advantage of it. This evening I spent about four hours remotely installing Team Foundation Server Workgroup Edition (RTM) into its production home on a non-virtual server.
The installation went smoothly as expected (I can almost do it in my sleep now) and it seems to be performing quite well. Now that we have the infrastructure setup there are a few housekeeping items that need to be dealt with and then we’ll open the gates.
Here is my TODO list over the next couple of days:
- Work with our fabulous infrastructure guys that aren’t at all the nasty draconian kinda guys that you find in most IT organisations to sort out our disaster recovery strategy (already having fun discussions around this).
- Figure out if we have a self-service story. I’m not going to give everyone the keys to the kingdom on this box, some of the assets that we are putting into it are going to be too valuable to risk this box being played around with. But – I still want people to be able to create their own team projects and this involves having some fairly heavy rights on the server. I’ll probably look at what is required to get the PCW kicked off via a web-based front-end which runs with elevated rights.
- Find out what we need to do as a partner, down here in Australia, to get a license for the full blown standard server edition. While the workgroup edition is a good start, we need to be able to support more than five users on this thing.
- Migrate existing projects across to the new box. I opted to do a fresh install onto a physical box rather than try and upgrade from BETA 3 to BETA 3 Refresh then to RTM, and then try to migrate the databases across. I know some people have been looking at what is required to migrate projects, and when we setup the BETA 3 environment we said that we wouldn’t necessarily be able to take the projects, I did say I would give it a good go. At the very least I should be able to dump out the source code and take the work item data across.
Of course, my first order of business tomorrow will be to take the above list of tasks and insert them into a TFS Team Project to manage adoption, issues and feature requests for TFS.
March 20, 2006 at 12:00 am
Mitch,
I did a similar thing between Beta 2 to Beta 3 and Beta 3 to RC. If you can loose your source history then it makes life easier for you to just move a cut over.
My top tip for the day is to create a user called “TfsMigration” or perhaps even “Unassigned” in your domain and associate them with your project. When you you migration, run as that user. This will save you years of people asking questions about source that was imported at this time. It will also save you from looking at the imported work items once they are closed (by default they get assigned back to the user who created them…). Once the import has been ran, you can remove the user from your domain or just deney them logon rights.
In terms of work items, trusty old Excel has saved the day on a number of occasions. Create a new query with all work items (including closed ones). Dump all this data into Excel. Now you can use Excel installed on a version with the RTM binaries to upload the data. You’ll need to do in in a multi-pass process manually converting usernames and copying over status after the work items have been initially created etc but it works. You’ll also loose history, links and file atachements for work items. A little tip is to use a field that you don’t normally use (for example baselined effort or perhaps even rank) to store the original work item ID when you are copying over – just makes the manual conversion process easier. Alternativiely, you can make your new title a concatonation of “ORIGINAL_ID: ORIGINAL TITLE”
If you really want source history then it is possible to write some code (using the OM) that extacts each changeset from the Beta 3 server into a flat filesystem along with an XML file for the meta data (commiter, comment etc)
You can then write some code that does the reverse inserting the source into your new repository changset at a time. If you run this as a user with TFS Admin permissions then you can specify the user to use for each insert so blame can easily be correctly given. The only problem is that history looks a little funky as the entire source tree history is compressed into the couple of hours it takes for your script to run.
I have the advantage of working somwhere with their own TFS Client API so this was a little easier for me
, but the same should be possible using the MS ones if you *really* wanted the history and were willing to spend the couple of days it would take to write the migration utility… A similar thing should also be possible for Work Items, but I really didn’t want that pain.
Good luck!
Martin.
March 20, 2006 at 12:00 am
Thanks for the tips Martin!