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. […]

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, […]

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:

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:

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! 🙂