Congratulations to TeamPlain

Today, Microsoft announced the acquisition of TeamPlain - the makers of the highly regarded web interface to Team Foundation Server.

TeamPlain was founded by a group of very passionate and very capable folks; Microsoft is lucky to have these guys in the fold.

Thanks!

Eric.

Orcas Feature - Version Control Folder Comparison

Hey guys,

Here is another graduate of the Team Foundation Server Power Toy - the folder comparison. This feature was called 'TreeDiff' in the PowerToy.

There are actually a wide range of uses for this feature - including helping you reconcile differences after spending time offline from Team Foundation Server. I'll do a follow up post on how to use this feature in those kinds of scenarios.

For now, please click below to check out this overview video of Folder Compare.

Thanks!

Eric.

Streams and Branches Part 2 - Would this work in Team Foundation Server?

Hey guys,

In terms of categorizing SCM products, Team Foundation Server fits more into the branch/merge mold than it does the stream mold.

That said, there are some interesting things about using a stream-based approach that we could leverage in Team Foundation Server.

Recall from my first post that there are numerous, numerous ways to do stream-based SCM. To try and narrow our scope a bit, let's just concentrate on the branch-on-task flavor of this a stream-based approach.

With TFS, you typically wouldn't branch-on-task. What you would typically do is make your changes - either in the mainline or a integration branch - and check them in. During the check-in, you would associate a work item with it.

With branch on task, you create a branch for the task you are working on (or the product you are using does this for you) and you make your changes. Once you are satisfied with your work, you merge it into an integration branch, which in turn will eventually merge into a mainline. Some products like AccuRev enable you to cascade your changes into other streams.

There are advantages and disadvantages to both approaches; I don't want to go too far towards a full comparison between these two. There is a very good discussion on the topic at CM Crossroads by folks who are far more qualified than myself :)

What I'd like to do is just explore what a branch-on-task approach might look like in Team Foundation Server. It might not work for everyone - or anyone :) - but I thought it is worth some experimentation.

Looking the Source Control Explorer, suppose that we have a project called Captcha as shown below.

Now let's say that we want to setup a branch-on-task model with this project.

The first thing we could do is set up an integration branch, this is where the changes are collected before they are integrated into our mainline. The Captcha project shown above effectively becomes our mainline.

So, we would create a branch as shown.

Now our structure looks as shown.

Since we are going to branch-on-task, we are going to end up with a lot of branches. Team Foundation Server is going to show us all the branches we have; so we need a bit of organization or things will get very confusing.

Let's setup a folder to hold all of our branches that are associated with tasks.

The toolbar button indicated below enables you to create a new folder manually; we will call our Development Team.

Now, inside of our development team folder, we will create a folder for each developer that we have. This is something we would have to do when a developer joins the team.

So let's just say I'm the lone developer, now we have.

OK, now we're ready to take on tasks. Suppose that we have the following bugs assigned to us (double-click the image to see if full size)

Let's follow branch-on-task strictly; that means we need to create a branch for each bug we are working on. Let's decide to start working on bug #2273 first.

So we create a branch of the Captcha_Integration (or mainline) into our development team work area.

Note the location of the branch - it is under development team\ericlee. We don't have to decorate the branch with _Bug_2273 if we don't want to; we can just associate a work item when we check-in the branch.

Each developer would be responsible for making a branch for the task they are working on. There is no specific branching privilege in Team Foundation Server, so any developer who can check-in changes can make a branch.

Our branch isn't 'real' until we check-in; so let's do that. When we check-in, we will also associate bug #2273 with it. We won't resolve the bug, since we haven't done anything yet to try and fix it, we are just associating the bug with our branch operation so we have a record that tells us why we created this branch in the first place.

Doing this work item association creates a link between the change set that committed our branch and the work item.

Now our structure looks as shown.

 

In theory, a project manager could query for work items that are still active, with a link to a changset where the operation was a branch and come up with a result that was reasonably close to what tasks were being actively worked on.

Once the actual bug was fixed, the final check-in for that fix would resolve the bug we originally associate the branch operation with. So bug #2273 ends up with 2 links to changesets.

Then, it is just a matter of merging the changeset from the task-branch into the integration stream.

A project manager or integrator would be responsible for merging changes from the integration stream into the mainline.

The branch-on-task approach has its benefits.

• Task-branches allow for interim check-ins. Suppose that a given task requires a fair bit of work, a developer can check-in, revert and even branch within their task-branch. You could do some of these same things with shelvesets, but I think that might become problematic if things got complicated.
• Having an isolated task-branch also makes it easier to transfer work from one developer to another. In our example above, suppose that I want to transfer the work that I've done for bug #2273 to another developer named 'darren'. I could just use the move operation to move my task into his folder as shown below.

         

• Task-Branches help project managers determine what tasks are actually being worked on, as opposed to just being assigned. You could go as far as seeing what kind of activity (i.e. number of check-ins, etc) that each task-branch was receiving.

This approach, implemented in Team Foundation Server - certainly has its drawbacks well.

• Branches freak some people out; especially if you are coming from a VSS background, you may not feel comfortable having so many branches.
• Branches means merges; the reality is that merging introduces some risk. It's arguably not riskier than coding, but it certainly something where errors can be introduced.
• There is a fair bit of meta data to keep in mind; there is nothing in Team Foundation Server that prevents you from creating a branch where you are not supposed to. That being the case, developers will have to know that they are supposed to create their task-branches in the right place.

I've never used an approach like this with Team Foundation Server in real-life, so I'm not sure how it would hold up. But, I thought it might be a good mental exercise to see what a branch-on-task model might look like in Team Foundation Server. There are still many things that need to be thought out; namely, what do you do with the task-branch after the task is done? Maybe you could delete it? Or maybe you could move it?

I certainly hope I don't stir up a religious debate over branch/merges versus streams; that is not my intention. I think there are some interesting things that you get from using a streams-based approach so I thought I would try and see if I could bring them over to Team Foundation Server. Hope it was at least an interesting read :)

As always, feedback and comments are appreciated. If there is interest shown, I would definitely like to refine this model over time.

Thanks,

Eric.

Orcas Feature - A Graduate of the Team Foundation Server PowerToy, Annotate

Hey guys,

The Team Foundation Server Power Toy is where the development teams likes to try out new features and respond to customer feedback. The thought has always been that the best features in the power toy would eventually make their way into the real product.

Looking at the Orcas March CTP, it looks like the Annotate feature in Team Foundation Server Version Control is one of those graduates.

Annotate is something like the blame feature in Subversion; it helps you see who made the changes in a given file.

I recorded a short, casual video about this feature in action; check it out if you have the chance.

Thanks!

Eric.

Orcas Feature - Build Agents, Queuing and more...

Hey guys,

The Team Build development must have been working pretty hard since the last release. The March CTP has a really mature-feeling build of this feature.

It really looks like a lot of thought has been put into how to make Team Build easier to use and more powerful.

There are a number of things besides continuous build that is worth a look at - build agents are managed in a much better way, there is a build definition editor, builds are 'queued' rather than just started, and build results are much easier to work with.

I made a casual, grab-bag style video of these new features; check it out if you get the chance.

Thanks!

Eric.

Orcas Feature - Continuous Build!!

Hey guys,

One of the most frequent feature requests made to the Team Foundation Server development team is for continuous build.

Continuous build can take many forms, but the general idea is to automatically kick off a team-wide build when a developer makes a check-in. Some development teams like to gather up a few check-ins before kicking off the build.

The idea is to try and catch changes that break the build as soon as possible.

The exciting news is that with the Orcas release of Team Foundation Server, there is a feature in the build called Triggers. These triggers enable you to determine when a build should be kicked off. One such trigger will start a build with each checkin; so we finally have Continuous Build!

I made a quick, casual video about the feature, check it out if you get the chance.

A Baker's Dozen of New Features in Orcas

There is nothing like having a new version of Visual Studio to play around with :) Not that Visual Studio 2005 is all that old, but the March CTP of Orcas was just released. I picked up the VPC version last night and gave it a whirl.

So far it looks great! I was expecting a very small upgrade to VS 2005, but there are some really substantial features here.

Here are a few features that caught my eye in no particular order.

Code Metrics

This is going to be really handy. Underneath the covers, VSTS was using code metrics like cyclomatic complexity to evaluate some of the code analysis rules.

It looks like in Orcas this functionality has been exposed directly. Hopefully we can use this feature in a check-in policy; I didn't see that option in this build, but maybe in a future one?

Annotation View for Files under Version Control

We've seen this in the Team Foundation Server PowerToy already, but it is nice to see it as part of the product. This feature is similiar to the 'blame' feature in Subversion; it gives you a chance to see who made what changes to a file. Really nice stuff! Hopefully this view will be extensible - I would love to incorporate the ability to right-click on a person in the annotation view and send an IM or schedule a meeting.

Team Foundation Server Build Definition Editor

 

No more dirty XML editing!  This is a great feature for anyone who has ever waded through a Team Build definition file. There are all kinds of nice new features added to Team Build, this is just one of them.

Build Retention Policy

One of the settings in the Build Definition is the ability to decide what you want to keep, and how much of it. This is handy if you're doing nightly builds. Chances are you are going to want to do some regular clean up. This retention policy will help you do that.

Continuous Builds!

I'm sure this will incite a massive cheer! You can decide when to start a build automatically - most notably you can do it when a check-in occurs; a continous build in other words.

Getting this feature in is a great example of how the product team is listening to its customers.

Build Queues

Not as sexy as Continuous Build, but still pretty cool; now you can queue up builds to run. Team Build is starting to look like a real full-featured release system now.

Folder Differencing!

This was in the Team Foundation Server PowerToy too I believe, but I didn't have a chance to try it out over there.

This is really something - you can do a folder-based comparison, which is particularly useful if you want to see differences between branches at a more granular level than just change sets.

Runtime Control of a Performance Session

 

Ah, last but certainly not least, improvements to the Performance Tools! This is a nice one, you can control your performance session as it runs - particularly useful is the ability to insert marks during the course of a performance run. These really help you when it comes time to do the analysis!

Query View in Performance Reports

Fantastic! It's so hard and tedious to sort through Performance Reports. You can dump them out to Excel and filter, but then you lose the nice visualizations. But, with a Query View you can structure a query to sort through the data, and still take advantage of the nice visualizations.

New Views in the Performance Reports

Some promising new views in the Performance Tools. I couldn't get the ETW view to work, but if we finally have a visualization for them, that's big. ETW events are super informative but very under utilized. This article has a nice summary and links to more information about ETW.

Integration with Work Item Tracking

Right-click and create a bug, what more is there to say :)

Performance Report Comparison

Being a former Program Manager on this team, it nearly brings a tear to my eye to see this nice feature :) Performance reports are so hard to work with because they gather so much data. It is nearly impossible to tell whether your current run was better than the last.

But, all that is changed with this view - you can compare the results of two performance files and get back a categorized report of the differences. Truly a great solution to a tough scenario, great job guys!