ProfileWell, I thought it was i...PhotosBlogListsMore  |  Tools Help |
|
October 25 Team SystemWe've recently moved on from the "experimentation" phase, and we've kicked off a small project to trial Visual Studio Team System properly. This has been up-and-running for a few days, and I thought I'd provide some initial comments.
Scoping
The project has a team of 9 devs, 3 QA, a Business Analyst and a PM. Its aim is to produce a shrink-wrap product for a particular vertical, based on a large existing source-code base. For a team of that size, we picked a single-server solution and specced out a quad-Xeon box with 4Gb RAM and a RAID5 disk array to support it.
We decided to stick with our current build and test system (NAnt, Draco, NUnit2) for this particular project, as we are still targetting DotNetFX1.1 and the pain of migration would be too high.
However, we're experimenting with a migration of a snapshot of the source tree from CVS into TeamSystem source control. Some initial experimentation reveals that it is possible to side-by-side these two source control systems without too much pain. Both being merge-based means that you have to pick which system is actually going to do the merge for you - and you can then see if they disagree! You can then commit the results into both.
Our build-and-test server lives on another box in the domain, and continues to check out from CVS, which itself lives on another server.
For this project, we're going with an out-of-the box MSF Agile process. We want to find out how this differs from our standard processes and documentation, and to determine how much we want to change v. how much we need to change it.
Installation
The most important point is that you've *got* to follow the instructions *to the letter*. The installation checklists provided in the TFS Installation CHM are nice and accurate - but you must follow them precisely; it is very sensitive to variation. We ran into a couple of problems during installation - it turned out that the "system healthcheck" can be a bit misleading. Our 4Gb, quad-Xeon box had "insufficient memory" and "insufficient processor speed". Ignore those warnings and carry on... We also dismally failed to install SQL Server on the original x64 edition of Win2k3 we had installed on the box. We repaved with the x86 build, and everything went swimmingly.
The installation instructions will take you right through from "the CD has stopped spinning from my Win2k3 server install". It is better *not* to have performed any of your standard application server configuration and lock-down before installing TFS; it has some particular IIS requirements (no FP Server Ext for example), and if your IT guy has prepped it to some "standard" configuration it might be tricky to get things going. Better to perform post-installation lock-down after you've proven to yourself that the installation is working.
I also found that it can be a bit tricky to set up your first administrative user; the TFS instructions are a bit sketchy about where to find the correct places in Reporting Services and SharePoint Services to configure the site admins. It is well worth reading the admin guides for those products too, and familiarize yourself with the infrastructure first, because you *have* to get it right before you try to create your first TFS project.
Why is that?
Well, it turns out that some irreversible database commits occur in TFS (e.g. source control) before the SharePoint site is created. While it tries to roll-back from most failures, under some circumstances, you can end up with a SharePoint site creation failure that leaves an orphaned, invisible TFS project that the TFS delete tool can't remove (even with the -force option), but which prevents you from reusing that project name again. It is possible to unpick that by hand in the SQL Server - but that's a painful afternoon's work and only marginally better than reinstallation!
Setup
Creating the new TFS project is very straightforward, and almost completely automatic. I was working inside VS2k5RC, but any Team Explorer instance will do. Unfortunately, adding team members to a project is mind-numbingly awful; you have to add them to TFS, SharePoint and Reporting Services. The UI is completely different for each of these tasks, and the conceptual models don't exactly map neatly onto one another. On the plus side, there is a handy chart indicating the privileges you need to apply in each of the application servers for each user role, and more-or-less where to apply them. Again, it is useful to understand the admin model for each server before you do this, rather than just blindly following the instructions.
For even a 15-person team, this is somewhat manual and therefore error-prone. I'm hoping for some automation in this area by RTM.
Having created a project, there are a bunch of Work Items already waiting in the system, and assigned to the project creator. Some of these are around source migration and policy, some are around actual project set-up and inception. These all point you at the project guidance, so it is pretty straightforward to get going.
Project Inception
I was slightly disappointed with the Persona and Scenario templates available in this version of MSF Agile, but pleasantly surprised by the Vision document. In our regular process we usually create a "Scope" document which lives alongside the "3 paragraph" Vision and the detailed elaboration of Personas and Scenarios; it helps us keep an eye on policy around what is in- and out-of-scope; this is chiefly to avoid feature creep, which is the dark side of an agile, scenario-orientated project. The Vision template was easily understood by the BA, and the "Persona" document also offered a reasonable template. The scenario templates are a little light on structure, and we will probably want to enhance it a bit for the next project. One quite powerful feature is the ability to create work items with associated "type" information. For example, you can create a "Scenario" work item to have someone elaborate a scenario. This takes a little getting used to for people familiar with a "bugzilla"-type "one-size-fits-all" approach.
Out-of-the-box there are a couple of MS Project plans on the SharePoint site - one for test and one for implementation. As a result of a bug in Beta 2 it is unnecessarily tricky to use these - TFS cannot integrate with the Read-Only SharePoint files and throws an exception when you try to push your selected work-items into it.
Incidentally, mapping from work items to project plans or Excel spreadsheets is not really mentioned in the getting started guide (you actually have to read the docs properly; what's that all about?), but it is the core of the TFS management process. You just select a bunch of work items in Team Explorer and you can then insert them into a given MS project file. You can then "publish" your changes to TFS (as distinct from publishing the document to SharePoint), or get updates from TFS.
To get around the Beta 2 bug, the Known Issues document suggests that you have to Save As... the MPP to a local disk. In fact, I've found that you have to Save As..., quit Project, restart, reload the file and *then* push the docs into it. Obviously, you have to replace the document on the SharePoint server when you're done.
You can happily add your own structural elements, milestones etc. to the project plan, which survice round-tripping. You do have to be a bit smart about duration and start time, as these can easily be lost when publishing and updating - I've not quite worked out why that happens yet, as it isn't entirely predictable.
Source Control
Source control has moved to a merge-model by default. This is a good thing, in my opinion, as we are used to this from CVS, and we find it very flexible. You can enforce various rules, such as code review, FxCop validation, and one-work-item-per-checkin. All of these are part of our standard process, so we just turned them all on. And then turned the FxCop validation off again when we realized that it didn't really work unless we were using VS2k5. Unfortunately, the source control system still has the same difficulties as Visual SourceSafe when it comes to getting the repository-tree to reflect the file system tree. Because it is integrated with the Solution System, it has a tendency to make up its own folder names, and ignore a more complex, multi-solution on-disk structure. I would have thought that this was common with the kind of large software projects at which TFS is targetted, so this is a bit frustrating.
The most important limitation is that you cannot check files in at the root of source control repository - you must create a folder below this to check items that live at a solution root.
This is nothing you can't work around, but it is more taxing that it needs to be. An explorer-integrated source control system (like TortoiseCVS/SVN) is, IMHO, superior to an IDE-integrated system, particularly when you move to a merge-based model, and there is no longer a correspondence between touching a source file and "checking it out".
Non-developers
It is a shame that there is no easy way of accessing and managing your work items from the SharePoint portal; for non-dev/test team members, that's the only reason for having the Team Explorer - everything else they do is essentially managed through the portal.
So far, so good... Comments (27)
Trackbacks (30)The trackback URL for this entry is: http://mwadams.spaces.live.com/blog/cns!652A0FB566F633D5!594.trak Weblogs that reference this entry
|
|
|
