Visual Studio vNext or VS 11

I started playing around with TFS 11 and Visual Studio 11 shortly after the announcement of the Developer Preview. Unfortunately (or fortunately) things started getting pretty busy with the business and the time disappeared.
Finally I have been able to polish off some of the posts that I started and will be posting these as time allows. So let’s start at the beginning:

 

Convert Project

The first thing most people do (I’m sure) is to open a solution, and the first difference shows itself. Thinking back, conversion from one version of Visual Studio project file to the next became a “blind” next, next, next operation. The new dialog almost took me by surprise. The standard csproj or vbproj files does not need to be converted (this is actually a feature in VS 11) and the smaller projects that I opened worked fine. Obviously something has changed with the Modelling Project and the Database Project (I’ll get to that in a later post).

 

Solution Navigator Explorer

Once your project files are up to date, the next thing you will notice is that Solution Explorer has changed a bit. Anybody familiar with the “Visual Studio Productivity Power Tools” would recognise this as the “Solution Navigator”.

Finally the “Collapse All” is a standard feature (It took long enough ). Other nice features include the search box, the ability to navigate “into” the file, class and method definitions and the Back and Forward “Navigation” buttons allowing you to “navigate” from one search result to the next.

Welcome 2012

WOW. I woke up and realised that we have officially started 2012.
Now if this is our last year on earth or not, I wish everyone a prosperous and fulfilling year ahead.
Some of the things that I’ll be looking forward to this year:

• Windows 8
• TFS & Visual Studio vNext
• C# 5
• Delving deeper into WP7
• And then scratching around Silverlight 5 as well

Have a good one!
Now to remember to put down 2012 instead of 2011!

Visual Studio and TFS extensibility

I came across this post by David Baliles listing a whole range of add-on’s to TFS and Visual Studio.

Whenever I speak to anyone that will listen I keep on re-emphasising the extensibility of TFS and Visual Studio. It really opens up the potential that lies within the applications, making it available to people and environments that no-one would ever have thought possible.

Together with this there are the people that actually take the time to solve their problems and then make their solutions available to the world. I really commend these individuals for their passion and effort.

David’s list just emphasises the extensibility and the community that surrounds it.
Have a look – it is a really interesting list, I’m sure you may find something that you have been struggling with…

Customising TFS Work Items

Work Items in TFS forms one of the primary “abilities” that Team Foundation Server exposes. A work item is a generic object that you use to record various “things” in TFS. The type, structure and workflow is defined as part of the process template as a work item definition or type. The MSF for CMMI process template has different work item definitions than for example the Scrum template would have. Work item definitions is also the closest that TFS will get to “exposing” or modelling a methodology.

In my business I often get requests to change or adapt work items to include fields that are important to the customer or to alter the workflow to better represent the process that is used internally in the customer’s team.

The work item definition is at its heart an xml schema containing fields, rules, form layout and workflow associated to the specific work item.
If you have a good xml editor you can export the work item definition using the witadmin utility, make your changes and then import it back into TFS using the same tool.

Of course if you don't feel like wading through all those angle brackets you can get hold of the TFS power tools and use the process editor.

After installing the power tools, select “Tools –> Process Editor –> Work Item Types” from the Visual Studio menu. You have the option of importing or exporting work item types (WIT),  editing types directly on the server or locally (using an exported WIT).
Good advice would obviously be to first export a WIT, make changes and then import the changed WIT if you are using a production  instance of TFS.

A note: As mentioned previously, the different types of work items are defined as part of the process template. For example the MSF for Agile template would yield the following work item types:

After selecting a work item the work item editor will open

You are now free to add new fields, change the work item form and alter the workflow.

It is simple enough to change the work item definitions using the process editor but you still need to take note of the following:

• Make sure you know the difference between the a Dimension, Measure and Detail when setting the “Reportable” field
• Make sure that you have a good understanding of, and cover all paths when changing the workflow for the work item
• When customising a work item it is important to remember that if you change the work item definition on a team project, the change will not be reflected on other team projects unless you manually update them. One way to overcome this is to alter the process template and include the changed work item definition in the process template. Next time you create a new team project those changes will be present.

 

Working for yourself…

I have been working for myself for over a year now and looking back I have concluded the following:

1. A pay check is the easiest (legal) money you'll ever make
2. I have never in my life worked so hard for so little
3. I am by far the worst boss I have ever had

Working for yourself is not easy, and is definitely not everybody's “cup of tea”.

Would I consider changing ?
Hhhmmm…..

Team Foundation Server is Version Control

This is a part of the blog posts surrounding the misconceptions that surround TFS. For the first post see TFS is expensive.

Team Foundation is Version Control…

There are a lot of debates raging (and have been for a long time) about how inferior TFS is when it comes to version control. Obviously the favourite comparison has always been between TFS and SVN, but these days the comparison is also shifting to the DVCS style of version control systems.

TFS version control (IMO) has always done what was needed. There are a lot of nit-pickers who look at the specific functionality that TFS does not support, but once again – I have used SVN and TFS and found that a lot of these features were really just “nice to haves”, and in most cases TFS did have a work around in one form or another.

The main thing that I feel is not addressed when people make these comparisons is the fact that TFS “IS NOT” version control. Version control is merely a feature, one of the components that make up TFS.
TFS is an ALM suite. It covers a much broader spectrum than just version control.

There are a lot of misconceptions around ALM as well. In fact, one of my large corporate clients was very keen to check the “we do ALM” checkbox after they started using SVN. Using version control does not mean you are addressing the full ALM!

So that said, one of the things that really excites me about TFS is the rate at which it is evolving. The “problem areas” are being addresses as the product matures. I’m sure you would have heard of TFS 11 & VS 11 by now.

Just looking at the changes that Brian Harry and his teams are making to TFS version control, it is going to be yet another game changing release:

• Off line or SVN style workspaces
• At last a new merge experience (I can finally stop using TortoiseSVN’s merge tool now )
• And looking at what is in store from the Team Explorer experience, it has to get you exited…

I’m off to get my hands dirty with the TFS & VS 11 developer previews…

Team Foundation Server for everyone, everywhere…

The topic I chose to present for this round of Dev4Devs Cape Town was (you guessed it) TFS.
This time I took a different approach and showed off the “new” focus that Microsoft has started adopting. Instead of trying to convert everybody to the Microsoft way of doing things, Microsoft is starting to adopt the desperate development realms and in some cases, is actually supporting them! This is very exciting for everyone using very competent, often “lower cost to entry” development tools and technologies, providing capability to grow which was previously unrealised.

So without further delay – here is a brief overview of my presentation: TFS for everyone, everywhere

IDE of choice…

Anyone who has worked with TFS should be familiar with Team Explorer. This is the developers portal into “the belly of the beast, erm TFS”.

Maybe a little less known to the Java, and especially the Eclipse developers would be a product  by the name of Team Explorer Everywhere (TEE).
This is (amongst others) an Eclipse plugin which is basically Team Explorer for the “non-Microsoft” orientated. It introduces TFS to the Windows, Linux, Mac, Solaris, AIX and HP-UX users (see here under system requirements for the “official” list of supported IDE’s and OS’s).

Deja vu?

As would be expected there are a few minor differences between the two, but by far any Visual Studio / Team Explorer user will feel right at home using and configuring TEE, right down to the check in dialog and policies.

API of choice…

OK, so now you have TFS integration into Visual Studio and Eclipse. What about the extensive .NET API (that is installed with Team Explorer)?

No Problem! Microsoft has released a TFS Java SDK.

Looking at a .NET example to create a work item in TFS:

1) Add a reference to Microsoft.TeamFoundation.Client and Microsoft.TeamFoundation.WorkItemTracking.Client

2) Establish a connection to the appropriate TFS Project Collection

   1: //get default credentials

   2: var credentials = CredentialCache.DefaultNetworkCredentials;

   3:  

   4: //connect to TFS project collection 

   5: TfsTeamProjectCollection collection = new TfsTeamProjectCollection(new Uri("http://localhost:8080/tfs/defaultcollection"), credentials, new UICredentialsProvider());

   6: collection.EnsureAuthenticated();

3) Using a Service Locator pattern we can get “services” from the project collection. In this case we are interested in the WorkItemStore. This is basically a repository for work items and can be used to load and query work items

   1: var workItemStore = collection.GetService<WorkItemStore>();

4) Then a bit of plumbing… Because each team project is based on a specific process template we need to get a work item definition that is appropriate to that project/process template. In this case we are looking for the “Task” work item definition in the “Dev4Devs” team project

   1: var project = workItemStore.Projects["Dev4Devs"];

   2: var workItemType = project.WorkItemTypes["Task"];

5) Create a new work item and start setting appropriate properties

   1: var workItem = new WorkItem(workItemType);

   2:  

   3: //set appropriate properties on the work item

   4: workItem.Title = "my new work item";

6) And finally, based on an active record pattern, we simple save the newly created work item

   1: workItem.Save();

Simple enough…..

So looking at the Java SDK, how difficult will it be?

1) The first step is to obviously get hold of the Java SDK and add it as a referenced library in the java project

2) Create a connection to the team project collection

   1: TFSUser user = new TFSUser("useraccount");

   2: TFSTeamProjectCollection collection = new TFSTeamProjectCollection("http://localhost:8080/tfs/DefaultCollection", user, "Password");

   3: collection.ensureAuthenticated();

3) Get the work item client (instead of store…)

   1: WorkItemClient workItemClient = collection.getWorkItemClient();

4) Get hold of the work item definition from the appropriate project

   1: Project project = workItemClient.getProjects().get("Dev4Devs");

   2: WorkItemType type = project.getWorkItemTypes().get("Task");

5) Create a new work item

   1: WorkItem workItem = workItemClient.newWorkItem(type);

   2:  

   3: //set appropriate properties on the work item

   4: workItem.setTitle("my new work item from java");

6) and finally

   1: workItem.save();

So, save a few nuances, pretty much the same when it comes to the interface exposed by the .NET and Java object models.

As mentioned earlier, I can’t wait to see where all this leads to in the adoption of TFS as a decent (and more often than not, cheaper) ALM suit.
Team Foundation Server…. not just your average version control