Loïc Baumann's Blog

Article MSDN sur la gestion de configuration avec VSTS 2010

Après avoir réalisé une série de posts en Anglais sur la gestion de configuration avec la CTP d'Octobre de Visual Studio Team System 2010, j'en ai profité pour traduire le tout en Français pour la MSDN France.

Vous trouverez donc ce nouvel article ici.

Un grand merci à Eric Le Loc'h de Microsoft France pour son aide !

Un petit teaser :

VSTS2010 CTP11: Work Items – Part 1

As I said in the previous post, the Work Item feature of the current version of TFS is already great, but everybody knows there's room for improvement.

So far, here are the pros and cons I see in the current state.

Pros

• Integrated in the Development Environment as well as Web Client: developers, PMs and stakeholders can all have access to them.
• Can be linked to code: the code is no longer the referential or entry point of you evolution and fixes.
• Highly extensible and customizable: you make them fit YOUR process and not the opposite.
• User friendly: it's always better for a quick adoption because the learning curve is really smooth.
• Traceability of changes: for CMMI lovers (or slaves!?).
• Workflow based: simple but there's no such things on Words for instance.

Cons

• The linking system is too limited concerning Work Items: all you can do is create an unversioned, two ways link between two Work Items.
• No MS Project Server integration.
• Rich editing too limited to store high level information.
• The Query system is good, but it's hard to get a good visibility when you have a lots of Work Item, issue mostly due to the first stated one.
• Lacks some automation between them: for instance it could be nice to automatically "activate" a Code Review Work Item when a given Task is ready to be reviewed in order to notify automatically the reviewer.

Most of the feedback I had from PMs and Lead developers was that Work Items was great, but it was hard to have a clear global view of what was going on and maintaining everything to keep it synced was a costly task. In other words: "one by one it's great, but when we have a bunch of them, it's harder and we are lost!"

I honestly don't know if this is an issue a lot of users have or not. If I speak for myself, I always tried to make the Work Items a "Project database/view" of the developments, organized the same way as MS Project but with all the features the Work Items can offer and it wasn't really possible.

I know you can use them from Project, most companies/team I've seen were working with Project Server, with many MS Projects for one Team Project, and Resources spread across multiple projects. Well, something you can't achieve with the current state of things.

Ok, so let's finally start with concrete stuffs!

So what's new now? Many things including: Link types, typed link view control (in the Work Item Form), queries using links, hierarchical representation, etc.

The new link system

Finally, something that many people waited for is arriving, a real linking system for Work Item. I wished I had it for the 2005 version then I wouldn't have to write that…

As stated above, the current version of TFS have a simple linking system, all you can do is link a Work Item 100 to another one, say 90 (then 90 references 100). A link will be created, it won't appear in the history (because it's not versioned) and finally your Work Item 90 will automatically be linked to the 100 too (100 will reference 90)! If you go looking in the databases of TFS, you quickly understand why it's done that way…

When before you only have one choice to link together two Work Items, you now have infinity of choices through the creation of your own Work Item Link Types.

Of course, there's already some predefined ones, let's summarize them briefly.

These are the three system types defined so far. If you look deeper, you will find in both Agile and CMMI process templates a definition of a custom link type:

<LinkTypes>
    <LinkType ReferenceName="Microsoft.VSTS.Common.TestedBy" ForwardName="Tested By" ReverseName="Tests" Topology="Dependency" />
</LinkTypes>

The attributes speak of themselves…

The Links Control

Speaking of Link Types, how do we link Work Items together now? Well, there's a new Work Item Link Control named "LinksControl".

Among its new particularities:

• You can have more than one of these controls in your Work Item Type definition.
• The control will display links based on a preconfigured filter (still declared in the WIT definition).
• You can create a WIQL (Work Item Query Language) from its content. This one may looks not much useful at first, but as far as I saw, only direct links are displayed in the Links Control, which can be very limited concerning viewing the hierarchy. We'll see later than converting to a WIQL can solve this issue easily.

There's also a new dialog to create a link:

You can see in the dropdown all the types of links you can create, it should fulfill the needs of almost every projects, don't you think?

Using Hierarchy

Ok, I will create three Work Items: a Requirement, a Change Request and a Task, linked all together.

Looking in the Links control of the Requirement, we can see only the Change Request work item, as suspected only direct children are displayed.

So what can we do if we want to display the full hierarchy? Apparently the only way is to use the Queries.
Let's try that quickly!

First we create a Query from the Work Item by clicking on the View As Query button from the Links toolbar:

The result is not quite what we expected:

The query still shows only two Work Items, and not the child of the 336 one.

If we click on the Edit Query button on the Query Window toolbar, we will maybe able to tweak things.
Here is the top part of the Query Editor Window

Sounds like the Type of Query being Work Items and Direct Links is the reason why we can't see more.
The different choices available are:

I guess the last choice is the good one! So I change my type of query to Tree of Work Items and refresh my query.
After saving the query, the displayed result is what one would expect:

Finally I have my full hierarchy displayed, great!

Now look a bit closer to the four little buttons I highlighted in read, using the first one will change the layout of your query window to a more explorer friendly one:

The result is pretty cool, but you better have a wide screen to get all the information you need. Using a grid to display hierarchical information has the inconvenient to take a lot of space.

To conclude, I think the hierarchy will be useable for real life projects, and that's the most important thing!

VSTS2010 CTP11: Work Items – Preamble

I continue my journey on the evaluation of the latest CTP of Visual Studio 2010 (formally known as Rosario), now is the time to play with one of my favorites part of TFS: the Work Items.

I can really say that the Work Items were for me the main reason I start evangelizing Team System in its early days. I really saw into them the possibility (finally!) to gather all information about a project development into one unique repository, and let people from any kind of role access to them.
I know this is not totally the case, but it tends to be more and more at each release of the ALM platform.

I've seen a lot of projects managed with many tools, with the same information found multiple times across them, with people having to move it or synchronize it from one to another. Working this way has a cost and is risky too, and I have suffered from these many times.

So Work Items were for me the light for better days coming, nothing can be perfect at first, but I was a strong believer they will fill all the needs through time: what I saw was great, the potential was there, and well, it's built by Microsoft and we were already pretty surrounded by Microsoft software, it can only help!

Nowadays in projects, Work Items don't store everything. The reason behind that is a mix of technical limitations and the fact that the team is not prone to change its way of working.
For these reason, they were most of the time introduced to contribute to a limited part of the process, coexisting around already long time adopted software, trying to steal data from them! 

With TFS 2005 and 2008, I intend to use the Work Items when the following criteria are met:

• Need a workflow, potentially involving many people.
• Need for traceability of the information.
• Need to link the information with the code.

In practice, I ended most of the time using Work Items in these scenarios:

1. Task driven development, with an optional Code Review.
2. Previous scenario plus defect tracking and change management.
3. Previous scenario plus risk and issue management.

Depending on the teams and projects, these different scenarios were using Work Items to take care of different things. Take the Task one for instance: it could handle Triage, Work Partitioning, Planning, Time Tracking, Scoping (through Iteration and Area Path), etc. The task could be interoperating with MS Project for Planning and Time Tracking if the team used the software.

I of course tried to use Work Item for "everything", considering that having relationship and full traceability between Requirement, Specification, Design, Development, Review, Testing and Code would be, well, nice!

For instance, storing requirements and specifications in Words document won't give you traceability matrices, a good management of history, and won't be a part of the common repository for project information (i.e. the Work Item Store), etc. Every change leads to human actions to update the related artifacts, this is error prone, and time consuming, in other words: not good !

So it would have been nice to use Work Items to store those information decomposed at a very small level, to have the possibility to build a traceability matrix that warns you of broken/out-of-data specs when requirements change.

So, this preamble is meant to explain what I expected from Work Items, how I use them (because I don't think there's only one way to use them).
The following posts will be in depth evaluation of the news features, and we'll see if Work Items can solve problems we had, do more things than before.

Stay tuned!

VSTS2010 CTP11 and Shelves

The Shelve concept was introduced in Team System in the very first release and it was immediately a success: a demo killer feature and an everyday handy one too!
The concept is simple, and the implementation (I guess) doesn't seem complicated either, and yet the feature fills a need we always had.

But if the concept is great, there are some features we miss:

• Not being able to unshelve a file that is currently in pending changes (possible with the PowerTools though).
• Not being able to unshelve to a different location (possible with PowerTools thought).
• Pending changes resulting from a ShevelSet behaves exactly the same as for a ChangeSet, and it's problematic when there're locks (can't unshelve a given ShelveSet twice).
• Security on a ShevelSet, they are visible to anyone, it would have been nice to create some "private" ShelveSet or set permission on a given one (e.g. useful for code review).

The first two features are possible using the command line TFPT.EXE program, but it would be nice to have it within Team Explorer.

So, let's check if there's some improvement with the latest CTP.

Unshelve + merge:

Let's try to unshelve files that are in pending changes:

The result is:

Still the same…

Unshelving to a different location:

Unshelving to a different location from the Pending Changes window:

The displayed dialog shows no possible action to change the destination of the unshelve. Again

Unshelving locked files:

Following the scenario:

• User TFSSETUP upload a picture, then check it out, modify it and create a shelve of it (without undoing local changes).
• User Darren tries to unshelve the previously created shelve, and the result is:

again.

Security on ShelveSet:

Nothing closed from what I wished was implemented, seems there was no evolution on that part too…

Conclusion

Well, I guess you already know what the conclusion is: no evolution on the Shelve. This is a bit disappointing.
But I do hope the Power Tools features will be included in Team Explorer in the RTM.

VSTS2010 CTP11: A bit of history…

Hi again,

I’m still working through the Source Control of the October CTP of Visual Studio 2010.
I guess now is the time to see if there are improvements concerning versioning.

I’m still working on the multi branches Team Project I created in previous posts.

Let’s see the history on the Form1.Designer.cs file of the version 2.0 of the test project.
First we select History from the Source Control Explorer on that file:

Then, here is the result, fully expanded:

Wow, it doesn’t look like the previous versions! This display is just powerful! One of those I was waiting for so long! As you will quickly notice, there’s the history of our version 2.0 file, but also the changesets related in other branches.
The indentation level gives you quick information about which branch the changeset belongs to:

- The first level being the branch of the file you’re viewing history of.

- The second one being directly related branches (for the V2.0 it can only be Main).

- Subsequent levels are following the hierarchy between branches, naturally…

For those who were complaining about not be able to see history through branches, now I guess you are served well!

One quick remark: the History window is now a View Document of Visual Studio, you will have one Window opened per request, is it a good/bad thing, I think it’s a matter of taste.

Now let’s look a bit closer to the new toolbar in that History window, there are some icons we already know, others that are brand new.

· The first is to view the file of the selected changeset.

· The second will display the details of the changeset.

· The third and fourth are used to compare files and folders.

· The fifth is the now famous Annotate feature.

· The sixth is brand new, called Track Changeset.

· The last one is used to get in the current Workspace the version of the selected changeset.

Now let’s get back to the Track Changeset button, it smells good, let’s see…
I select the changeset 61, and click on that button. A new dialog appears, asking me to select the branches I’m interested to view information about.
Let’s make it this way:

The result is awesome (if you don’t judge the colors used):

What we have is a graphical representation of the flow of a changeset through branches. In this particular case you can see that changeset 61 is the result of a merge from CS 60 and is the source of a merge to version 2.0 that leads to CS 62. And of course you have full traceability for previous changeset. You can see that both CS 58 and 59 lead to CS 60 (remember the multiple “cherry pick” merges with only one check-in I did in a previous post?).

This window is mainly a graphical representation, but that’s not it, one of the killer demo-feature is you can drag and drop a given changeset from its branch to another one to initiate a merging operation. I don’t know if it will be used a lot, but the feature is just so cool!

There’s another representation of the changeset tracking history: the hierarchical representation. Here is what you get in this case:

The flow is still very well represented, giving you an idea of what went on.

There’s another feature I won’t cover which seems to display the labels related to changesets shown in history, another thing we missed for so long.

All in all the improvements here are good contributions to the Source Control part of Team System, you may find some enhancements as nice to have but working on large scale projects

VSTS2010 CTP11: Source Control – Branching management – Part 2

Hi all, I’m still going through the Branch system of the Source Control. We saw in the previous post that the branch feature evolved from the previous versions.
There’s a new restriction where you can’t create a branch that is inside its parent branch. I used to consider that case as a valid one, well, not a bad practice at least.

The next test I did was creating many branches to simulate a Main branch and many version of the product. The branching model used was intentional, I know it was not the best way to go in previous version, so I wanted to see if there was some improvement out there.

There’s a new good feature now to visualize the relationship between branches, select the branch, right-click on it, and choose the View Hierarchy menu item.

And you now have what you’ve expected for so long! :)

A graphical representation of your branches!

As you can see on the previous picture, we have many branches, all deriving from Main, the Version_1_5 is itself derived from Version_1_0.
The purple color is the branch from which you created the graph. And the cyan one is the currently selected one.

By right clicking from the Version_2_0 branch you have all the possible actions “branch-wise”.

For instance, the Merge… operation will propose you to merge from the 2.0 version back to the main one.

There’s a case I was particularly interested: merging two branches not directly related. In this case it would be merging Main and Version_1_5. This was not supported in previous versions of Team System, and I always thought it was a great miss. So here we go, let’s try it for now:

Oops, looks like it’s still the same as before. The only choice I have is to merge back to the version 1.0, which is the direct parent branch.
I guess I have to ask MSFT people if it will stay the same in the final release… Thread on the Rosario forum.

Ok now let’s try some merge. I have made some modification on the version 1.5 and 2.0 of the application. What I’m going to do is merge the changes from 1.5 to 2.0.
In the current state, I have two choices:

1) Baseless merge, which is not really a merge, as I would have to take care of everything manually.

2) Merging 1.5 back to 1.0, then to Main then to 2.0.

Let’s take the second case, it’s more interesting.

First it’s a good opportunity to test a feature I really missed in previous versions: being able to accumulate merges and check everything in just once.

Using the WICreator, I use Work Items to drive the merges, then the purpose of the program is to take all the changesets referenced by a given Work Item that are candidates to the merge (i.e. they are from the source branch and they were not already merged to the destination one) and merge them to the destination branch.
What I would have liked to do is multiple “cherry pick” merging operations, and then create only one resulting changeset (aggregate all the changes into one changeset is always better, don’t you think?) by check-in them all at once.
Unfortunately, we can’t merge to a file that is in pending changes with the current versions of Team System, leaving me no other choice that perform cyclic merge/check-in operations.

So to test this new feature, I have two changesets having a file in common that I want to merge from the 1.5 version back to 1.0.

Let’s use the Merge operation:

Note above that both changesets are selected.

And the result is?

Yey, it worked!

After playing a little more, I realized that you can merge to a file that is in pending changes of type “editing” or “encoding”. This is understandable, except if you want to make what I just did in two separated steps: you can’t!
Because the result of the first merge will put the “Form1.Designer.cs” file in “merge” and “editing” pending changes, disallowing the second merge operation.

But, I’m very happy about the new feature, I really think it’s a good one!

Ok, so now let’s merge from the 1.0 to Main, then Main to 2.0.

From 1.0 to main, I had no issue, everything auto-merged perfectly.
From main to 2.0, I expected a conflict because the 2.0 had its own changes, and I wasn’t disappointed:

Here comes the new “Conflicts” pane in the Pending Changes window. I’m sure you know how it’s working with current versions, and I’m sure you don’t like it much.
As you can see, now the information becomes a lot more clearer, “theirs” and “yours” are long gone (at last) and all the information about conflict is summarized in one window, helping you to make the right call.
In this case we have two conflicting files: “Form1.cs” and “Form1.Designer.cs”. The current file to resolve is “Form1.cs”, you have now the three possible choices clearly displayed, waiting you to make the call.
Each conflict can be resolved separately or you can apply a given operation to a multiple selection, watch this:

I will manually merge these, and check the result in smoothly.

To summarize the merging improve in many ways, meeting most of the expectations.
Only the merge of indirectly related branches doesn't seem to be supported, that's still a great miss.

But thumbs up for the improvements !