Adam Singer : Team Foundation General

Pack-Man

Adam Singer — Fri, 15 Aug 2008 18:02:00 GMT

In case you haven't heard, Visual Studio 2008 Service Pack 1 is available!

As you prepare to install the TFS 2008 SP1, I'd like to strongly recommend that you first run the BPA tool. From the Visual Studio Team System forums, I've seen two folks already have installation failures because their current system wasn't quite what TFS expected it to be. In one case, the team had modified the TFS AppPool accounts without using TFSAdminUtil so the old TFS service account that no longer existed was still referenced quite a few other places. In another case, the permissions of the TFS Setup user had been modified. I know that the BPA tool would have exposed the first issue and think it would have found the second, as well.

If you have a machine where you'll install both the VS SP1 and the TFS SP1, you should run the BPA tool before installing the VS SP1 or else you may not be able to use the TFS tools to fix any issues. This is because the two packs share several assemblies whose internal APIs may have had breaking changes between RTM and SP1. This would cause the TFS administrative tools to not function if they use those APIs.

Hopefully this will help folks avoid SP1 installation issues so you can get it up and running. It's very well worth it- I promise!

Ventriloquism: TFS Style

Adam Singer — Mon, 28 Jul 2008 18:45:00 GMT

Quite a long time back, Buck posted about how to recover from the situation where one TFS machine is created as a clone from another. This can lead to clients still showing the project list for one server when the connect to the second. Based on a recent Visual Studio Team System forums question (they certainly seem to be inspirational to me these days), I decided to code up a very simple tool that connects to one or more TFS instances and spits out their GUIDs so you can check whether they were cloned from each other. The actual interesting block of code is as follows:

TeamFoundationServer tfs = new TeamFoundationServer(arg);
Console.WriteLine("The GUID for server '{0}' is:{1} {2}",
arg, Environment.NewLine, tfs.InstanceId);

As you can see, there isn't much to finding out the GUID of a server. I've attached the project in case you want to play around with it yourself. Nothing fancy- I even attempted to manually hack it back to a Visual Studio 2008 capable csproj file since I'm using a recent internal version of the next release. Enjoy!

Edifice Reqs II: The SQL

Adam Singer — Wed, 16 Jul 2008 16:00:00 GMT

Back in March, I posted about the requirements for TFS installation. I promised to post about "SQL Server and it's Various Components", but have been tied up with the Visual Studio 2008 SP1 like a Thanksgiving turkey (only not quite as delicious).

In any case, I'm back from outer space. I just blogged in to find you here... ahem. I'm getting side tracked with my song spoofs these days, apparently. Hey, they say blogs are supposed to be conversational, right?

SQL Server 2005 and SQL Server 2008 have quite a few subcomponents that Team Foundation Server requires. If you're installing TFS 2005, we require everything possible to be installed, running, and set for automatic startup. In TFS 2008, we investigated this requirement and determined there were several of these components and restrictions we didn't need. Depending on your desired configuration, there are different components you must have installed.

For all installs using SQL Server 2005, we require the SQL Database Engine ("SQL DB"), the SQL Analysis Services ("SQL AS"), and SQL Reporting Services ("SQL RS"). If all components are remote from the TFS Application Tier, you must install some SQL component on the AT so that we can use the SQL assemblies to talk with the remote components. The simplest way to achieve this is to install the "SQL Workstation Components". If you are using named instances of SQL DB, SQL AS, or SQL RS and don't want to use the port numbers to communicate with them, you should install the SQL Browser and set it to start up automatically. This will provide the hook TFS installation needs to find SQL components.

If you're using SQL Server 2008, please note that it's still pre-release. For TFS 2008 RTM, TFS was installable using the version of SQL Server 2008 that was available publicly at that time. TFS 2008 SP1 Beta is installable on the SQL Server 2008 February CTP (a.k.a. CTP6). Abdelhamid has a great post you might want to check out here that has the details on that score. For the TFS 2008 SP1 RTM release, we plan to support SQL Server 2008 RTM. At present, the components we require for SQL Server 2008 are the same as for SQL Server 2005. I don't anticipate that changing, but think it's important to add the qualifier in there just in case lightning strikes (twice) an alligator that's attacking a coin that landed on its edge.

My service is packed, I'm ready to go

Adam Singer — Wed, 09 Jul 2008 19:12:00 GMT

...installing here, upgrade once more
(Adapted from "Leaving on a Jet Plane")

A post on the Visual Studio Team System forums reminded me of one very important tidbit of Visual Studio patching. The integration of Team Foundation Server with Visual Studio enables all sorts of marvelous functionality and is great for development, but does place some restrictions on what patching scenarios are supported.

In particular, all Visual Studio derived products on the same machine must have the same service pack level. This includes Visual Studio Express SKUs, Visual Studio Standard, Professional, Team System (and the individual role SKUs), Team Foundation Server's Application Tier, Data Tier (only exists in TFS 2005), Team Build, Proxy, and Team Explorer. Since these components share common assemblies, if one tool has been upgraded to SP1 while another is still at RTM the functionality is undefined and unsupported.

The easiest way to check your SP level is look in the control panel Add/Remove Programs (on XP/Server 2003) or Programs and Features (on Vista/Sever 2008). For the former, check the "Show updates" button. On the latter, click the "View installed updates" link. There, you should be able to see which components have been updated and which haven't. If there's a mismatch, my recommendation is to reapply the Visual Studio and TFS service packs to bring everything back up to the latest SP. Of course, you can also uninstall the SP from everywhere that it's installed, but I would hope you'd want to get the latest and greatest functionality!

Best of luck, folks, and feel free to shoot along questions and comments if there's any other topics you want to see me address.

Edifice Reqs

Adam Singer — Fri, 07 Mar 2008 18:16:00 GMT

I'd like to tip my hat to the father of a guy I worked with as a camp counselor one summer long ago for the post title. He owned a demolition company called "Edifice Wrecks".

In our last episode, I described the OSes that the various Team Foundation features support. This time, I'd like to cover what other software components you need to install, and how you can best do so. As before, I'll be making copious references to the Team Foundation Install Guide so I recommend you download it to play along at home.

Application Tier and Proxy: Both of these components require IIS 6 with ASP.NET, or, if you're on Longhorn Server, IIS 7 must have IIS 6 Compatibility, ASP.NET, HTTP Redirection, and Windows Authentication installed. I usually install it through Add/Remove Programs (Windows Server 2003) or Server Manager (Longhorn Server). Specific instructions for each OS can be found on the install pages "How to: Install Internet Information Services 6.0 on Windows Server 2003" and "How to: Install Internet Information Services 7.0 on Windows Server 2008".

The Application Tier also requires SQL Server. You can use either SQL Server 2005 or certain versions of SQL Server 2008. Since the latter still hasn't released yet and changes in CTPs have broken TFS functionality, I strongly recommend using SQL Server 2005 SP1 or SP2 for production installs of TFS. There are separate instruction pages for each of SQL Server 2005 and SQL Server 2008 on Windows 2003 and Longhorn Server, so I won't list them all out here. They're children of the "Prerequisites for Team Foundation Server" topic in your install guide. To sum the up, though, I'll say the following. You need the SQL Database Engine, Analysis Services, and Reporting Services. Workstation components are very useful for troubleshooting, so I'd recommend them as well. If you want to mix and match instances, things get a little bit harrier- I'll address that in a separate post. Besides that, the simplest install is to take the defaults for SQL Server 2005, using either Local System or a domain account as your SQL service account. Note- this is not the Reporting Service account, but rather the SQL Database engine account. Reporting Services should be run as Network Service, and using the selection "Install the default configuration" on the Reporting Services options page will do this for you.
The Application Tier requires SharePoint, as well. If you don't yet have an install of SharePoint on your corporate network, the simplest path is to just let the AT install and configure SharePoint for you. If you want to install SharePoint on a machine other than you TFS Application Tier, however, you should very, very carefully read and follow the page "How to: Install SharePoint Products and Technologies on Windows Server". Make sure to follow the steps all the way through to configure the SharePoint sites. One thing I will add to the install guide is that if you want to extend the existing site on port 80 instead of creating a new one you must set the "Description" to the existing web site name (e.g. "Default Web Site") in step 17. If you don't do so, it will disable the existing site and create a new one with just SharePoint components.

Team Build: Team Build as a server doesn't have any particular prerequisites. However, in order for it to be able to run coverage analysis, or run tests you must install the appropriate SKU. For running tests, you need Visual Studio Team Edition for Testers or Visual Studio Team Suite. For coverage analysis, you need Visual Studio Team Edition for Developers or Visual Studio Team Suite.
Team Explorer doesn't have any other software prerequisites. It installs all the necessary Visual Studio shell components to host itself and stand on its own.
SharePoint Extensions: The only prerequisite for our SharePoint Extenstions feature is that SharePoint be installed. As I mentioned in my previous post, we currently only support 32-bit SharePoint installed, but are actively working on a power tool for 64-bit.
Team System Web Access: The system requirements documentation for TSWA is currently online, but not in the TFS Install guide. You need to install IIS 6.0 or 7.0 with ASP.NET, the .NET 2.0 Framework, and Team Explorer.

Next, we'll take a closer look at SQL Server and its various components (that sounds like a rock band, doesn't it, Dave Barry?). See you then!

Pre[ranasaurus] Reqs: The OSic Era

Adam Singer — Tue, 04 Mar 2008 21:37:00 GMT

I've seen a bunch of questions over time about what it takes to get Team Foundation Server (TFS) components installed. Because it varies by component, the answer is usually rather lengthy and takes long enough to fully describe that eyes start glazing over, heads start nodding, and the utility of the information is basically reduces to a (very) small hill of beans. So, over the next few posts I'll review specific prerequisites (a.k.a. "prereqs" to their friends) for the TFS components. I'll be refering to the Team Foundation Install Guide left, right, top, bottom, and center (possibly front and back, too, but don't hold your breath), so I recommend you download it so you can play along at home. Also, it's pretty useful in its own right.

Today, we start with the all important operating system. I'm going to gloss over the hardware requirements since they're all listed on the pages I reference. If you're interested, feel free to read up on it at the source. Each TFS component has its own specifications for what it can and cannot be installed over, so we'll break them down by categories:

Application Tier and Proxy: These two SKUs can only be install on 32-bit OSes in the VS2008 release. In addition, they require a "server" OS - Windows Server 2003 or Longhorn Server. For Windows Server 2003, we require at least SP1. All 2003 Editions other than the Web Edition are supported. For a complete list, check out the "System Requirements for Team Foundation Server" section of your install guide. The Proxy page ("System Requirements for Team Foundation Server Proxy") starts out by saying "The software requirements for Team Foundation Server Proxy are the same as for Team Foundation Server" so you can just look at the first page to get the list of OSes you can play with.
Team Build is a different story. It can be installed on 32- or 64-bit systems. On the latter, it will run in WOW64 mod since it's actually a 32-bit application. The install guide page doesn't give you an exhaustive list, but rather refers to the Visual Studio 2008 Readme with some modifications. As with the Application Tier and Proxy, we require at least SP1 or R2 on Windows Server 2003 and only support Standard and Enterprise Edition. On XP, we require at least SP2 and it must be Professional. For Vista, we support Home Premium, Business, Enterprise, or Ultimate Edition. They don't mention Longhorn Server on the "System Requirements for Team Foundation Build" Install guide page, but I can't imagine why it wouldn't be supported. I'll find out about that.
Team Explorer also references the Visual Studio requirements, but doesn't specify any exceptions like Team Build has. As with Team Build, it will run in WOW64 mode if installed on a 64-bit OS. See the "System Requirements and Additional Client Software for Team Explorer" page for more detail.
TFS Databases can be installed on a 64-bit machine only if you use the "dual server" deployment where the Application Tier resides on a different machine from the SQL instance with the TFS databases. In addition to the OSes listed in the Application Tier's requirements page, you can find the 64-bit OSes the databases supports on the page titled "64-Bit Support in Team Foundation".
Remote SharePoint: If you choose not to install SharePoint on your Application Tier, it can be installed on any OS supported by SharePoint, with some caveats. Currently, our TFS "SharePoint Extensions" SKU doesn't like 64-bit OSes. As Jason mentioned, we're working on a Power Tool to rectify that and will post more when it's available. Otherwise, for 32-bit OSes, see the Install Guide page "How to: Install Windows SharePoint Services Extensions for Team Foundation Server" on how to upload the appropriate templates and redirectors to make SharePoint and Team Foundation Server friends.
Team System Web Access: According to the Power Tool download page, TSWA only supports Windows Server 2003. As TSWA is incorporated into the main line components for the next version I'm sure we'll see more information on its support.

I hope there aren't too many nodding heads and glazed eyes- it's very tough to condense all of this down, especially when you enjoy words as much as I do. Next time we'll investigate what other software must be installed prior to TFS. Stay tuned!

Supercalifragilisticexpialidociou-dition

Adam Singer — Tue, 05 Feb 2008 23:43:00 GMT

With Team Foundation 2008 generally available, I've seen a bit of confusion over the various Editions offered. Of course, there's still a bit of confusion over how "Workgroup Edition" relates to workgroup networks, but there's also some missing clarity around the upgrade paths, the restrictions, etc. Hopefully this simple guide will help make the Edition story a little less obtuse.

Believe it or not, we have four Editions, or so they tell me.

Trial Edition
Workgroup Edition
Retail Edition
Volume License Edition

For all intents and purposes, 3 and 4 are the same. The only difference is how you obtained them, and whether you have to fill in the PID yourself or if it's already filled in. Both are fully functional and should have no timebomb or user limit restrictions.

The Trial Edition has a 90 day timebomb, but is otherwise fully functional.

The Workgroup Edition has nothing to do with domain versus workgroup network deployments. Rather, it's a version you get with an MSDN subscription that has a five user limit. It's my understanding that it may only be installed in a "single server" configuration.

Supported upgrade paths are from Trial to Workgroup, Trial to Retail or Volume License, and from Workgroup to Retail or Volume License. Brian Harry has a great post on how to upgrade.

I hope that helps- if not, let me know and I'll see what other information I can dig up!

Great news!

Adam Singer — Tue, 31 Jul 2007 16:45:00 GMT

I'm still alive! Yes, I know you all agree that's great news. At least, I think it's great news so will classify it as such here in my blog.

First, a bit of business:

Come chat with the Visual Studio Team System product team – This Wednesday

Join members of the Visual Studio Team System product group to discuss features available in Visual Studio Team Foundation Server, Architecture Edition, Development Edition, Database Edition, and Test Edition. In addition, discuss what's new in Beta 2.

We will be holding two sessions:

Join the chat on Wednesday, August 1^st, 2007 from 10:00am - 11:00am Pacific Time. Add to Calendar | Additional Time Zones

-or-

Join the chat on Wednesday, August 1^st, 2007 from 4:00pm - 5:00pm Pacific Time. Add to Calendar | Additional Time Zones

Now for something on a more specific and on-the-front-lines style.

Orcas Beta 2 has been out for awhile now, and with it a lovely improvement that I think will make Team Foundation administrators jump for joy, throwing confetti and streamers all the way. Hey, it's still my blog and I can imagine what I want to.

In Whidbey, syncing users from Active Directory to TFS happened due to three conditions but really only two conditions. This was fixed in Orcas as part of the Sync Large Groups feature crew. As such, you can now take advantage of the ability to modify the periodic AD/GSS sync period. To do so, you need to manually modify a Web.config file on the Application Tier that by deafult will appear under the folder "%PROGRAMFILES%\Microsoft Visual Studio 2008 Team Foundation Server\Web Services\services". DISCLAIMER: I do not guarrantee that this will not cause your computer to eat all of the data it has ever come into contact with, possible with fire. This confers no warranties and no rights, your mileage may vary, use at your own risk, void where prohibited, etc. [Note: still my blog].

You'll need to add the following two lines to the key/value pair section at the top of this file, followed by resetting IIS to make sure our application pool picks up the changes:

<add key="IdentityUpdatePeriod" value="01:00:00" />
<add key="IdentityUpdateInitial" value="01:00:00" />

Note that I've set both the initial update (i.e. the delay after startup that the first periodic sync happens) and the delay between periodic syncs to 1 hour. You can increase this to multiple hours, or decrease it to a matter of minutes. Be very careful when reducing the time as forcing the sync to happen too frequently will likely decrease the overall performance/throughput of your Team Foundation Server due to the multiple connections to your domain controllers that a sync opens as well as the processing that it kicks off in the SQL Server to update the cache.

Well, there you have it. Administrators spontaneously breaking out in song, bluebirds and rainbows for everyone, and a bright smiling sun grinning at us from behind fluffy white clouds. That last part sounds somehow like Super Mario Brothers, and this frightens me.

What's up, Doc?

Adam Singer — Tue, 26 Jun 2007 23:55:00 GMT

This week, we have one of our User Education ("UE") folks out visiting the North Carolina office. We're talking about all manner of interesting documentation topics, including what we want to work on with respect to documentation for future versions. After spending a bit of time scratching my head and trying to come up with answers I realized that I don't have to come up with ideas all by myself. After all, any of you out there who have experience using and reading our online documentation certainly have at least as much of an idea what may be needed or what else you'd like to read.

With that in mind, I'd like to make an open call to all users of TFS to comment here or use the "Email" link on my blog to pass along your thoughts. What documentation changes would you like to see? What documentation have you found most helpful? Where can we improve? Any other thoughts?

No 'I' in 'Team'

Adam Singer — Wed, 28 Mar 2007 19:45:00 GMT

I've had this brewing in my head for awhile now and wanted to share it with you, my fellow netizens.

This stems in part from a philosophy course I took back during my undergraduate days called "Freedom and Responsibility". The basic question in the course was "do we have free will and, even if we don't, are we responsible for our actions?" My final paper was an analysis of the sentence "I have free will" and comprised two basic sections. First, to determine the truth or falsehood of the statement we have to define "free will" and what is necessary to be free willed. Next and this is even more important, we need to define who or what the "I" is that [believes it] has free will.

I proposed that the "I" part was more important because, no matter what free will ends up being, the subject of the sentence is the creature affected and through whose perspective the whole question is posed. Changing the "I" inherently affects the "free will", and so on.

You may ask why I'm bringing this up; does this have anything to do with Team Foundation Server? I'm so glad you [may have] asked.

Indeed, the same sort of analysis can apply to the very term "Team Foundation Server", only in three parts. Let's work backwards.

What is the "server"? That's fairly straightforward, but has hidden complexities. In the simplest world, the server is the application tier, data tier, build machines, and proxy machines through which users access and manipulate "team foundation" objects (version control items, work items, work item queries, team builds, reports, team portals, etc.). Of course, if it were that simple, we wouldn't have so many questions about setup and server configurations on the Visual Studio Team System forums. Still, those questions are mostly technical and less theoretical in nature. In the interest of remaining somewhat philosophical, I'll defer those questions for a later time.

What is the "foundation"? Again, we can take the simplistic view that the foundation is merely a collection of tools (version control, work items, team builds, team portal, etc.). However, there's more to it than that. The foundation is more of a framework or an SDK due to the project templates, object model, and publicly accessible web services [N.B. I'm not advocating directly interfacing with the web services here- they are intentionally undocumented as the OM is expected to be the major entry point for extra plug-ins]. These access points allow people to modify processes, workflow, and even work item types and project definitions. A framework is supposed to have some degree of open ended behavior capabilities, and that's what we [hopefully] provide with the OM/template model for Team Projects.

Finally, which "team" are we talking about? What is a team? The way I see it, "team" is a many layered onion, if onions contained multiple sub-layers per layer (not that some don't - I cooked one just the other night that--- hmm, off track here). At the innermost layer, the team is a single person. Personally, I want to make sure to be thinking about what you, each and every individual using Team Foundation Server, need, want, and would benefit from on a daily basis. How can we help you be more productive? Around that is the group of folks including your direct coworkers and manager. I want you to be able to use TFS to tell what that team is doing, how it's measuring up, and what its priorities are from day to day. Beyond that may be your feature group or product unit or sales team or... any number of things, really. You should be able to use TFS to find out what's going on there, too. And up and up and up to the level of your whole company. How can you figure out what your company is doing? Where it's headed? Hopefully, the answer will be "Why, used Team Foundation Server's reports and queries, of course!" If not so today, then hopefully someday soon.

To me, as with "I have free will", the key aspect of "Team Foundation Server" is what I'll call the "subject" of the phrase. The "Team" should always be the focus of our efforts- how can we help your team, no matter how big or small it may be, get more done with less hassle and frustration? What does your team need day to day? What does it want? What could you benefit from that we haven't even dreamed up yet?

If you ever think of an answer to one of these questions, please feel free to send it my way and I'll see what I can do to help you out. I can't control or predict the future of the world let alone Team Foundation Server, but I may just be able to nudge it along a bit, and sometimes it's the butterfly flapping its wings that causes the storm.

Enough philosophy- next time we'll get back to good old reliable TFS functionality posts. Cheerio!

The Chat in the Hat

Adam Singer — Tue, 06 Feb 2007 16:46:00 GMT

[With apologies to Dr. Seuss]

I'm working on a short program that will help you get information about your built-in groups. In the meantime, though, I wanted to pass along news about a Team System chat tomorrow:

Visual Studio Team System Chat – This Wed

Join members of the Visual Studio Team System product group to discuss features available in Visual Studio Team Foundation Server, Team Editions for Architects, Developers, Database Pros, and Testers. In addition, discuss what's new in the latest Community Technology Preview (CTP).

Join the chat on Wednesday, February 7th, 2007 from 10:00am - 11:00am Pacific Time.

Add to Calendar
Additional Time Zones

Truth in advertizing

Adam Singer — Fri, 05 Jan 2007 22:25:00 GMT

I'm an avid fan of Battlestar Galactica, as is only appropriate for a former Trekkie who only saw only the first two Matrix movies and was not impressed by the second. Therefore, when I saw the advertisement Visual Studio 2005 had on the SciFi web site for the show, I was definitely drinking the kool-aid. While I sadly forgot to get a screenshot of my own, Nick Cody has a picture available in his post "Cylons. Why debugging matters." from awhile back that you may all enjoy.

[insert holiday name] came early this year!

Adam Singer — Fri, 15 Dec 2006 18:20:00 GMT

As you've probably heard by now via Soma, Brian, or Rob (among others), Visual Studio SP1 is available for download! I do hope you'll try it out. Not only are there numerous fixes and incremental improvements, but there are even some new features. More details are available on the MSDN site.

Having helped out with the testing of SP1 over the past few months, I'm thrilled to see it out the door and available for all of you. It's been awhile in the making, but we wanted to make sure to get it right.

So now it's your turn- tell me, how did we do? What do you think? Do you plan to download a copy for everyone on your ChrismaHannaKwanzaSoltice list?

Virtual Green is made of People!

Adam Singer — Thu, 14 Dec 2006 21:45:00 GMT

So you want to run Team Foundation Server, but don't have the physical machine resources. You think- 'hey, isn't Virtual Server a free download now?' You're right! And what's best, TFS works just fine in a Virtual Server. Having done quite a bit of testing against servers set up in virtual machines, I can attest to at least basic functionality (and much deeper for some features). Still, there are a few issues to consider of before put all your eggs in the bandwagon as the train leaves the station.

First, we generally recommend that any virtual machine have somewhat increased memory and hardware from the default recommendations, and the host machine should have approximately double the recommended RAM. Also, I've heard that it can help to have the virtual machine's VHD stored on an entirely separate physical drive from the drive with the host machine's OS. If you have other processor intensive operations running on the host OS, or other VPCs running simultaneously, your TFS performance will decline as well.

Also note that I don't know if virtual machines are an officially supported TFS hosting mechanism (I would postulate due to potential performance hits as well as network configuration issues between host and guest OS). That being said, for small teams, virtual machines will likely help ease the hardware costs of a new server.

Oh- and virual machines certainly aren't made of people, you know. They're made of other machines, chopped up and reprocessed into a messy pulp of silicon and plastic, and eventually reconstituted as a Replicant.

New and Improved

Adam Singer — Thu, 14 Dec 2006 18:00:00 GMT

I always wondered about that phrase- "New and Improved". Either it's 'new', which means it never existed before, or it's 'improved' which means that it's better than the previous version(s) and, therefore, existed before. Finally I can stop wondering because I think I've come up with a situation where it can actually be logically applied.

Now that the first version of TFS (Team Foundation Server) is out in the wild doing its wild thing and we're well on the way in our hunt for version 2 we have a new issue to contend with. This issue is something that never came up in the last product cycle- Legacy Code. I'm talking about both product code and automated test code (of which we have a great deal).

The issue of course is that as we work, we learn. We come up with smarter, better, faster, stronger ways of doing whatever needs to be done. The old way still works, certainly, it's just not correct according to new preferred practices. In an ideal world, we'd like to refactor all of the code any time a new method comes into the shuffle. However, we only have so many hands and would like to release the next version some time this decade.

Given that, you have to make some tradeoffs and costing decisions. How bad does old code have to be before you update it? Certainly you'll update anything that gets broken, but do you apply all new practices, or just the critical ones? If it's bad enough, do you scrap it and start again?

In this sense, our automated test code is both new and improved. Some portions of it never existed before since the features tested didn't exist previously. Some portions of it have been upgraded to the new standards. And the third, unspoken, category is all that testcode from V1 that still does something useful, whether or not it's written the way we'd do it today.

I'd like to finish by posing a question to all you code writers out there- When what made your code tick just doesn't click, do you give it a kick, or just let it stick?