Team Foundation Server Version Control Housekeeping Tasks

Hey guys,

I posted a short video that illustrates how to do some basic housekeeping tasks in Team Foundation Server Version Control (i.e. delete old workspaces, undo other users changes when they leave, unlock locked files). Check it out if you have the chance.

Thanks!

Eric.

Small things are sometimes the most useful...

Windows Vista has a new set of API for working with RSS feeds. I don't mean to imply that this is a 'small' thing, since I'm sure it was a lot of work to create this.

Before Vista, there were lots of different ways of consuming a RSS feed - anything from a community .NET project to opening up a socket and parsing yourself.

But, what I really like about the built-in support for RSS that Windows Vista provides is exactly that, it's built-in :) All of the hassles of figuring out a folder structure, creating a data store, providing sync and async ways of downloading content and downloading content at a regular interval have been figured out and implemented. Not rocket science per say, but the devil is in the details, so it's nice to have all of this functionality ready and wait for you as a developer.

I made another 'highlights' style video about this feature and posted it to Screencast.com, check it out if you have a chance.

Thanks!

Eric.

Organize, Visualize and Search

One of the more subtle, but very important (IMHO) additions in Microsoft Windows Vista has been in the Windows Explorer.

A few folks around the community have been categorizing these additions as 'Organize, Visualize and Search', which is a pretty apt name.

What Vista has done is enabled customers and developers to do a much better job of organizing data by using the new Property System. Similiarly, the Live Icons and Preview Handlers give deveopers ways of providing information to their users in an elegant and non-intrusive manner. Lastly, when all else fails, there is always a new, extremely powerful desktop search capability. This feature is embedded in Windows Explorer, but can also be accessed through an API.

I made a short 'highlights' video of these features, check it out if you get the chance.

Thanks!

Eric.

Streams and Branches Part 1

Hey guys,

If you look around at the SCM market, you'll see a few 'stream-based' products. AccuRev, PureCM and the UCM implementation of ClearCase/ClearQuest.

Team Foundation Server, like Perforce, Subversion and many others can be categorized as branch/merge systems.

There have a been a lot of really good discussion about branching/merging versus streams. A really good one can be found at CM Crossroads.

I found that discussion really interesting and informative. Sometimes the best way to see if you really understand something is to try and explain it to someone else; that's why I wanted to post about my thoughts on streams, and how they might apply to Team Foundation Server.

Two things make understanding streams difficult. First, all of the stream-based vendors have a slightly different interpretation of what a stream is. And secondly, you can use a stream-based approach in such a way that it looks exactly like a branch/merge approach.

From my point of view, the difference between a stream-based approach becomes really evident when you follow a branch-on-task approach.

A branch-on-task approach means that you would create a branch for every task you are working on.

UCM implements this by asking developers to associate every check out with a work item (CQ calls these activities).

What conceptually happens under the covers is that a branch is created for this developer, and some meta-data is associated with that branch to record that work item that is associated with it. This private branch is created transparently, and the developer's workspace is populated with items from that branch.

As the developer is working, they are free to make intermediate check-ins into their private branch. It is literally a private branch, their own private sandbox, so they can do anything that they would like there.

Usually, in a stream-based product, a 'project' will be comprised of at least 1 integration stream, 1 baseline and many of these task-based streams.

When a developer finishes their work, they deliver it into the project's integration stream.

Conceptually, the tip of the developer's branch is merged with a collection, or integration branch.

Stream-based products abstract this merging operation; from the developer's point of view, they press a button and their work goes where it is supposed to go, and they can move onto the next task.

Usually, a project manager or release manager is responsible for working with the integration stream. They decide when an integration stream is stabile enough to produce a baseline. Future projects, and subsquently future integration streams, can be seeded from these baselines.

Some stream-based products like AccuRev enable you to cascade streams; so a deliver into one stream can make its way through a hierarchy of parent or child streams.

The stream-based products I mentioned earlier have features to make this branch-on-task approach easier to manage (you can imagine that you'll get a lot of task streams really fast if you have a very busy project.

I don't want to say much about whether a stream-basd approach is 'better' than a branch/merge approach. That is a really subjective topic because a lot really has to do with your prior experience and the dynamics of your team. I will say though that there seems to be some real benefits to using streams. For example:

• Seeing a list of task-based streams could add visiblity into a daily SCRUM meeting
• Since a developer's current work can be located on the server in a private branch, it would probably be easier to transition that work from one developer to another. This would probably be easier than pulling files from a local workspace.
• Isolating developers from merging branches is probably a good thing :)

So what does this mean for Team Foundation Server? Obviously doing branch-on-task without some rules for the road would be a disaster. Since it is getting late on a Sunday night, I'm going to wrap this post up; I'll talk about what a streams-basd approach might look like in Team Foundation Server in another post later this week.

Thanks!

Eric.

Virtual PC 2007 is available, and free!

Hey guys,

I'm a big fan of virtualization technology - as a small business owner it is invaluable because it enables me to switch from many different OS setups with a minimal number of machines.

I usually use Virtual Server R2 to do my virtualization, but one drawback to it is that it does not virtualize a sound card. It is also meant for server virtualization (as it's name would suggest) so its performance seems to be geared more towards headless performance than user interaction (though the user interaction is reasonable).

Virtual PC has always been better for user interaction, and a new version, Virtual PC 2007 has been released this month. See Ben Armstrong's blog for details. His blog is a great resource for all things virtual as well.

Like its sibling, Virtual Server R2, Virtual PC 2007 is free for download. You can grab yourself a copy from

http://www.microsoft.com/windows/downloads/virtualpc/default.mspx

From the little I've read about it so far, it looks like the big improvements to Virtual PC 2007 are:

- Support for Vista as both a guest and host

- Support for multi-monitor setups

- x64 support

I'm trying it now and will post more about my results with it.

Thanks!

Eric.

Video - Branching by Label

Branch by label is an interesting option in Team Foundation Server. The scenario in the video uses a label created by Team Foundation Server Build and branches from that.

You might do something like this if you are using Team Foundation Server Build as your release mechanism and use recommended builds as a way of seeding future projects.

In any case, enjoy the video (double-click on the video to full screen it). As always, please let me know what you think.

Thanks!

Eric.

Videos Redux

Hey guys,

A while back, I posted a few VSTS related videos on YouTube. I like doing the videos because they make some things easier to convey than a written blog.

One of the problems that I had with YouTube is that I could never get a resolution that was very good.

So, I decided to switch over and use Screencast.com, which is a beta effort from the folks who make Camstasia.

Click on the image below to view a video that illustrates how to revert a change set. It's best to right-click on the video, choose Zoom and view the video in full-screen mode to get the best resolution.

Thanks!

Eric.

All Hail Fiddler v1.2.2.2 Beta!

The long and short of this post is that if you want to use the VSTS web tests from Fiddler with ASP.NET AJAX applications, use the beta, not the v1.2 release. You can find the beta at

www.fiddlertool.com/dl/fiddlerbetasetup.exe

In case you haven't heard of it before, Fiddler is a tool that records HTTP requests and responses.

It is similiar in concept to the web test recorder that is part of VSTS, but it ties into the Internet Explorer object model much closer. The most obvious benefit to doing so is that it can record ASP.NET AJAX requests.

In terms of ASP.NET, the VSTS web test recorder will only capture HTTP traffic when it is sent 'properly' by the browser. That is an ASP.NET full postback or a browser refresh.

Of course, the whole idea of AJAX is to minimize full postbacks. The ASP.NET AJAX toolkit does a remarkable job of writing AJAX enabled web applications.

The problem that this causes for VSTS is that VSTS can't pick up the AJAX requests back to the server; so these types of applications are very hard to test.

This is where Fiddler comes into play. Fiddler can pick up the AJAX requests and emit a VSTS web test from it.

Now, the version of Fiddler that I used was the release version v1.2. That version has a bug where form field names are not recorded properly. Not sure what all the scenarios are that cause this, but ASP.NET AJAX applications are definitely one of them.

The version that you want is here www.fiddlertool.com/dl/fiddlerbetasetup.exe.

Fiddler does a really nice job of emiting a VSTS web test that you can put into a test project.

Thanks!

Eric.

Top 9 just doesn't sound quite right...

I just realized that I've already blogged about web test transactions - my screen shots in that post were actually much nicer :)

So, here is another handy dandy feature in web testing - parameterizing your web servers.

This feature makes your web test much more portable. If you create a parameter out of your web server, you can easily switch between the ASP.NET Development Server, your local test IIS and your real IIS.

Thanks!

Eric.

Top 10 Most Often Overlooked Features in Visual Studio Team System

Features, features, features - Visual Studio Team System is just chock full of them.

But of course, as any good sales/marketing person will tell you - sell benefits, not features!

Sometimes, in following this good advice, some features get lost and forgotten about.

Anyways, I thought I would pick out a few that I think don't quite get the attention that they deserve.

Here they are, in no particular order

1. Web Test Transactions

The transaction feature just enables to capture timing across a series of pages.  For example, let’s pretend that registering for a site involved a user going to the following pages.

1. www.mygame.com
2. www.mygame.com/register.aspx
3. www.mygame.com/information.aspx
4. www.mygame.com/interpretcaptcha.aspx

By default, you would get per-page (or per-request) data which is useful.  In some cases, however, you might want to know what the overall user experience for a given scenario is like. For example, you might ask, how long does it take a person to sign up for the game? 

In that case, you would create a transaction called ‘User Registration’ and put each of those page requests under that transaction. 

When you run the load test, you’ll get per-transaction data as well. So then you can see the average amount of time it took to execute those 4 pages together. Sometimes the system integration type companies will get SLA requirements like ‘a new user registration must be completed in 4 seconds or less’; that feature helps verify it.

2. Load Test Timing Details Storage

This property captures really interesting information, but it is not on by default. From the documentation (http://msdn2.microsoft.com/en-us/teamsystem/aa718897.aspx), a quick description about this feature.

"If Timing Details Storage is enabled, then the time to execute each individual test, transaction, and page during the load test will be stored in the load test results repository. This allows 90th and 95th percentile data to be shown in the load test analyzer in the Tests, Transactions, and Pages tables."

3. Merging Code Coverage Results

This one is quite cool - if you ever have a bunch of individual test results that address the same set of code and you wonder what the collective code coverage of those tests are, you can merge the code coverage results together with this feature.

4. Uploading documents from the Team Explorer

Actually, this is probably news to nobody except for me :) Being a very small company, I don't make too much use of the Team Portal. But, if you do, remember that you can upload documents directly from the Team Explorer node if you do not want to go to the Team Portal site. You can also create new folders and document libraries; very cool!

5. WasEver clause in WIQL

I mention this a lot whenever I train or present, but the wasever clause is very powerful in WIQL. For example, you can quickly see what bugs have regressed in your project by using 'state wasever resolved'.

6. Test MetaData

I try to mention this whenever I get the chance, but there is a wealth of metadata that you can associate with any type of test in VSTS. This metadata is available by viewing the properties of a test in the Test View. Anything from the person that owns the test, to the area that the test addresses can be attached.

7. The Test View can group!

If you ever need to organize your view of your tests, you can group by a number of fields; this is where using metadata like owner or area really helps.

8. You can export Performance Reports

 

This one is close to my heart; sometimes it is just easier to process dense performance reports when they are in XML or CSV format. Exporting a performance report gives you that option.

9. Cloaking items in Workspaces

I've talked a little about this one before. Sometimes there will be things that you don't want in your workspace. Maybe it is a bunch of image files, or documents, or old code. Most of the time, when you are editing your workspace, you are figuring out what you want to work on. The cloaking feature allows you to specfy what you don't want to work on or worry about.

10. Exit Criteria choice in a Task

Last, but certainly not least is the humble Exit Criteria indicator on the default Task work item type. 

I'm often guilty of looking at only the Description tab in a Task; but there is a wealth of good data in the other tabs too :)

One of these is the field that indicates whether the given task is used to determine whether the current milestone or iteration can be exited. If you use this field diligantly, you can build a better picture of when you are close to the end of an iteration.

Anways, there are many more features out there built by the hardworking folks on the development team; apologies for the ones that I've missed.

Thanks!

Eric.

The Joy of IM

Hey guys,

One of the things that I miss the most about not working at Microsoft anymore is the corporate IM provided by Live Communication Server 2005.

Live Communication Server 2005 is one of my favorite products actually.  It does the basic IM functionality - presence and message sending, but what makes it really stand out is the integration with your telephone system.

Live Communication Server 2005 can integrate with a number of PBX (private branch exchanges) to enable you to literally right-click on an IM client and call them up.

It sounds trivial, but that little feature saved hours and hours of time, and dozens of emails. 

Talking on the phone with someone can be a remarkably productive thing to do when you're trying to solve a problem. In my experience, thorny issues are rarely solved properly with a long email thread. Those long threads seem to eventually sputter out with no resolution, or someone abruptly ends things by saying something rude. For some things, a good old conversation between a couple of human beings directly can solve things so much faster and better.

This is where I think LCS really comes into its own; by integrating into the existing phone line, or many of the VOIP PBX's, you can really increase the productivity and morale of a team.

When used properly, IM can be so much richer than email - the integration between LCS and Office is really compelling. Whenever I opened a document in MS, I could see a list of everyone wh had a hand in that document, and whether they were online or not.  You could easily imagine the same sort of thing for source code files in Visual Studio. If the person who checked in a given file is online, you can quickly IM them with questions if you needed. If they were not online, you would know immediately and do something else, rather than waiting indefinitely for an email response.

There is an obvious question about why one wouldn't just use a public IM service like Yahoo, MSN or AIM for the same purpose. A lot of those services offer some level of phone integration as well.

I think it boils down to how comfortable one would feel about having business conversations over a public system like Yahoo, MSN or AIM. The implied confidentiality of those conversations would seem to make the investment in LCS worthwhile.

Anyways, if you have a chance, pop over to http://office.microsoft.com/en-us/communicationsserver/default.aspx and have a read about LCS. If you're feeling really adventerous, have a look into the multitude of PBX systems - my favorite is Asterisk, an open source PBX (http://en.wikipedia.org/wiki/Asterisk_PBX)

Thanks!

Eric.

Windows, Trees and Trunks

Hey guys,

During my time at Microsoft, I spent about 2 years as a software developer in Windows Server 2003.  It was a fascinating experience working in such a large development.

I recently came across an old article that talks about some of that process so I thought I would share the link

http://www.winsupersite.com/reviews/winserver2k3_gold2.asp

I was the person designated from my team to attend the Windows War Room meetings - I remember quite vividly that small room in building 26 :)

About mid-way through the article, there is some discussion about how the Windows team does its source control structure.  I get a lot of questions about how to structure source control in Team Foundation Server, so this part of the article may be particularly interesting for some folks.

Thanks!

Eric.