Share via

Rounding the corner...

  • Article

There comes a time in every software project where you realize that everything is staring to gel and the product suddenly feels very very real. I just had that experience with Visual Studio Team System, and it's really exciting.

During our last test pass, some of our testers were using the system from end-to-end, simulating the way a team would design, implement, and build software. I had my testers working on a .NET smart client application that could monitor the state of our Team System servers during the test pass. Now, we didn't use all the features of Team System, but we did put source control and work item tracking through its paces. Here's a sample of how we used Team System:

1. I created a new C# Windows Application solution and added it to source control in the "new project" wizard. It's a simple app that uses some of the Team System web services to query data such as total server uptime, the number of outstanding pending changes, the total number of changesets for our project, etc.

2. I filed a bunch of bugs and work items against the project and assigned them to various testers on my team.

3. As testers fixed the bugs and implemented the features noted in the work items, they did peer code reviews and noted the code reviewer in the checkin notes "Code Reviewer" field. Then they associated the bug or workitem they were resolving with the changeset and checked in their changes. Anyone who registered for them received e-mail notifications on each checkin.

4. From time to time, I would query the list of resolved workitems and bugs and then navigate from the bug details to the changeset details and use the diff tool to review the actual code that fixed the bug. 

5. One day, I made a change, but I had to leave the office before I could get a code review. So, I shelved my changeset and sent mail to Chris and asked him to review it for me. He unshelved my changeset to his workspace, made a few tweaks, and then checked it in for me.

As I said earlier, I didn't get to try out all the features of Team System during this test pass. As we continue testing, we'll keep adding in more and more components to our end-to-end test scenarios. Some of the things I'm really looking forward to trying include viewing reports about our outstanding bugs & work items, code churn, etc., using the builder component to automatically generate nightly builds of our project, using the test tools to do static code analysis to help us find design issues and interesting bugs, using the team sharepoint site to manage design specs etc. The fun just keeps coming!

Hopefully you'll see what I mean in the upcoming Beta release. But don't take my word on it... I really hope you try all these things for yourself and give us good hard feedback on what you like, what you don't like, and how you think it could be improved.

It feels great to be a part of such a great product!

Comments

  • Anonymous
    December 22, 2004
    This team system sounds cool, I hope its not gonna be hard to set up
  • Anonymous
    December 22, 2004
    My only question would be is there some way for the build script to be aware of what changeset number is being built, or a command that can be run or API to be called to tell me what changeset was the last one I got on the machine?

    I'll often embed something along those lines in my about boxes so that I can quickly get a particular version when reproducing bugs.
  • Anonymous
    December 22, 2004
    I have a real dilemma on my hands with regard to Team System. Background is that we're doing development of a web application in VS2003 which we customize, to a greater or lesser extent, for each client. To facilitate this we create a branch in SourceSafe for each customer. Naturally, since SourceSafe 6.0 has some, well, let's be charitable and say "limitations" in the area of branching and merging, all merging between the main development trunk and individual clients is done by hand with obvious painful consequences. We also use a painfully limited task tracking system and have no testing tools at all.

    Team System (in particular, the Team Foundation SCC part) sounds like it solves this problem almost entirely and also adds lots of other cool features to improve our processes, and hence the quality of our product. However, Team System won't be released for 9 months, and we're hurting from the lack of these features now. Furthermore, we certainly won't be deploying anything based on the 2.0 framework for a while, mainly because we need to wait until hosting companies have their environments set up to handle it.

    So what do I do? Options:

    1) Just suffer until September. Not appealing.

    2) Search for other alternatives and switch to them permanently. Suffer from poor integration with VS.NET and between the pieces. Don't gain the benefits that Team System will offer.

    3) Search for other alternatives and switch to them until September, then switch back. Suffer from poor integration, AND through two migrations and learning curves. Need to ensure that whatever we use in the meantime is supported for import into Team System, which may rule out many open source options such as Subversion.

    4) Switch to Team System as soon as the Beta comes out. Means that we're using beta software in production, but if the quality of the beta is good and we have a good backup strategy, this may not be too much of a problem. However, it may not be possible unless TS provides a solution for integration with VS.NET 2002 and 2003. Does the SCCCCCCCCI provider work with older VS.NETs? Also there may be migration issues between the beta and final releases.


    As you can probably see I'm leaning towards option 4 because its downsides seem to me to be minor compared to the downsides of the alternatives, as long as there's a way to work with it in older VS.NET versions. But I'm very interested in your feedback as someone actually involved in producing Team System - do you get the feeling that the Beta will be (unofficially and off-the-record, of course) up to the task of being used in production? And does Team Foundation Source Control have a story for users of older VS.NET versions?
  • Anonymous
    December 22, 2004
    Eric, setting up Team System in this release should be much smoother than in the Beta 1. If you have any specific feedback or suggestions related to setup, I'd love to hear them and I'm happy to pass them along to our setup dev tema.
  • Anonymous
    December 22, 2004
    The comment has been removed
  • Anonymous
    December 22, 2004
    Stuart, I hear your pain.

    Unfortunately, I can't (with any amount of self respect) suggest that you use a beta quality release for production purposes. While we're working very hard to make sure it's stable and usable for evaluation purposes, the beta won't be production quality (no beta is, right?).

    Also, the specific SCCI provider for Team System won't work in older VS.NET versions. But there is a thin client SKU that only includes the essentials of source control and bug tracking (and a few other bits), minus all the compilers & other tools that is intended to cover folks using older IDEs (or gasp... OTHER IDEs).

    If you can hang tight and make due until the final version is released, I'm sure you'll find it worthy of the wait. In the meantime, if you do get a chance to use the beta in a similar way to how you would want to use it in production and give us feedback, there's still time to make changes and tweaks to support top concerns.

    I'll try to get you a definitive answer on what will be supported for migration. VSS is certainly in that list, so if you stick with that, it should be straightforward to upgrade to Team System later.
  • Anonymous
    December 22, 2004
    Thanks for your thoughtful response :)

    Is there a good reason why the SCCI provider for Team System won't work with older VS.NET versions? Doesn't it kind of defeat the purpose of having a "standardized" source control interface if it's different in every VS.NET version?

    Even if we ultimately decide to just wait until the final version is released, this will be a pain for us as we'll still have to support older branches of our product that haven't been updated to the hypothetical 2.0framework version. The quality of IDE integration is the one thing that SourceSafe still does better than it's open source competition and the only thing that kept us from migrating a couple of years ago before Team System was announced, when SourceSafe appeared to be a dead-end product that MS didn't care about at all. Seems a shame to take a step backward in that department, even with all the steps forward being taken in other areas.

    I bet Subversion won't be supported for migration... :(
  • Anonymous
    December 22, 2004
    The comment has been removed
  • Anonymous
    December 22, 2004
    Thanks for looking into this :)

    Of course the ideal scenario would be if the workitem tracking, reports, testing, coding-standards-enforcement and build tools would all work with the older VS versions :) I can understand why these things are hard to retroactively apply to an older IDE, though, and why you wouldn't want to dedicate too much time to it compared to concentrating on getting the best possible behavior on the new version :)
  • Anonymous
    December 23, 2004
    When you say "Also, the specific SCCI provider for Team System won't work in older VS.NET versions" are you referring to Visual SourceSafe 2005? Won't VSS 2005 still exist as a stand alone product? If so, will using it by itself allow us to integrate with Visual Studio 2003.
  • Anonymous
    December 27, 2004
    Matt, I'll get you an answer on the VSS2005/VS.NET2003 integration story as soon as possible. I'm not actually on the VSS team, so I don't have that answer handy.

    I had the technical details a bit wrong in my reply above, but the main point still applies. According to current plans, you won't be able to plus Team System into older VS.NET client installations.

    The public SCCI layer is still there, but it has grown in VS 2005. Since we're using some of the new features that don't exist in older VS releases, Team System can't run in those older versions.
  • Anonymous
    January 17, 2005
    According to one of the VSS dev leads, yes, you should be able to plug Visual SourceSafe 2005 into Visual Studio .NET 2003.