A first look at Team Foundation Server 2015

A few days ago Microsoft released a first CTP of Team Foundation Server 2015, together with another one for Visual Studio 2015. Whoo!
I was particularly curious about Team Foundation Server, as the preferred way of evaluating new features is Visual Studio Online. Keep in mind what Brian said: “More than anything it was a forcing function for us to practice getting ready to ship TFS 2015”, meaning I’d expect other TFS 2015 CTPs soon. Moreover, don’t forget many of the Visual Studio Online features had been brought into TFS 2013 Updates, so it isn’t like 2008 any longer.
It is the beginning of a new wave. The TFS 2015 wave! It is quite of a change, I reckon, but based on my experience it works pretty well. I manage a gigantic TFS deployment with all the trimmings, and being on the Update Train is perceived as extremely valuable by both my colleagues in Operations and my users. So expect sizeable features to show up after RTM.
Before looking at the actual features, a word on the installation process itself. It didn’t change a lot, but there are a couple of tidbits worth mentioning.

You can now configure a Basic Server (TFS Basic as we knew it) or a Full Server. The Full Server makes it clear that the new Build is a new core service:
SharePoint Foundation doesn’t ship in the box anymore, hence the 370MB ISO size. You can still integrate with an existing SharePoint deployment of course:
So let’s start with what’s in the CTP1:

• Extensibility and integration
• Agile tooling improvements
• Licensing changes
• Build.vNext

Extensibility means you now have the whole set of REST APIs which were available in Visual Studio Online only, together with the Service Hooks. This is very interesting for the whole lot of in-house applications you might have, plus a out-of-the-box integration facility with the supported 3rd party services.
Oh, integration…I think this screenshot says it all:

Do you want to integrate with a Jenkins build server? A couple of clicks, and you are in!
On the Agile tooling improvements it is basically lots of what we already saw on Visual Studio Online with all the reliability improvements we cannot see because they are behind the scenes.
To be honest, I read quite a few comments busting the Product Team’s work because there aren’t hundreds of new eye-popping features in this CTP, and I cannot agree with them. It is a CTP1, to be used as a shipping test for the team, it isn’t feature-complete or go-live supported. Why all this mess? They used to be called alphas, and I still remember the excitement when the first virtual machine containing an alpha of Visual Studio 2010 (codename Rosario at the time) came out, with really few features inside a Visual Studio Team System 2008 IDE, and everybody was excited about it. On my side, I’d rather appreciate what we can have to learn and share feedback, instead of complaining…
Anyway – back to the features :)
The licensing changes are all about the Stakeholder Access Level, extending lots of the Standard features to the basic, CAL-less tier. It is amazing because it enables a true involvement by the stakeholders themselves, without being too limited by the lack of a CAL.
Eventually, Build.vNext – it is a new Team Build concept, based on scalable agents instead of rigid matching between controllers and agents. But what matters most is that the workflow is now easier, clearer, and cross-platform.

Does this mean the old XAML-based build is going away? Absolutely not, everything works as it does today, but this is now the way forward for the future. With Build.vNext, you won’t have a dedicated Build Controller setup any longer. You can have it, but it would be the Legacy Build Service we saw in the installation as a separated, optional step to do – aka XAML-based Team Build.

PowerShell DSC in legacy pipelines, or with no pipeline at all

It is true that PowerShell DSC is the newest kid on the block, but it is also true that we can integrate it in legacy pipelines, or where we have no clear pipeline whatsoever.

How? Pretty easy – even if there is DSC in the name, we are still talking about PowerShell, hence who can stop us from invoking a legacy script or even a command?

For example, think about where you have a script which stops IIS, copies the new content and then the scripts restarts IIS, using iisreset and xcopy. Not best practice at all, but it is broadly used. You can replace it with this:

The Invoke-Command cmdlet is a standard PowerShell one, it has nothing to do with DSC. But embedded into a DSC script it can make a functional step into the DSC script itself.

Even better, do you have a preparation script which prepares the environment? You can use Invoke-Command with the –FilePath switch, pointing at your script, as part of the DSC script.

What are .tfignore files?

I was talking with Gian Maria this morning about the need of excluding some files from the Version Control, with both TFVC and Git. With Git (and the .gitignore file) you can specify rules for it, but what about the TFVC?

Typically you have two options, a check-in policy or a .tfignore file. What is the latter?

It is a file which specifies some rules about the allowed and disallowed files in the Team Foundation Version Control. You need to create it in your Workspace folder, and you can specify rules like these. Yep, pretty much like the Git counterpart.

Of course it isn’t like a check-in policy, but it provides a good way of enabling basic rules on the allowed files in your TFVC. It is very helpful anyway when you have large teams, it enables a quick distribution of a standard set of policies without too much mess around the startup.

The hidden gem of Microsoft Test Manager: tcm.exe

Can you clone a specific Test Suite into an existing Test Plan? Not really.

Shall you resort to Excel, getting – in this scenario – an half-baked result? No, either.

And what if you want to work with test artifacts in a script?

You should use tcm.exe instead! By design, MTM doesn’t expose all the possible capabilities, for a matter of User Experience. As it is a tool aimed mainly at testers, too many options might be confusing for the user. But that does not mean that a scenario like cloning Test Suites (not the whole Test Plan or the single Test Case) is impossible or barely possible by using tools not really fit for it - tcm.exe fills this gap.

What you’ll need to do is just calling tcm suites:

You can get the Suite ID from MTM. Even if you are cloning from/to the root of the Test Plan, it is still a Test Suite hence you have a Suite ID:

You can also override fields, and clone stuff across Team Projects. It is pretty handy.

But it isn’t over, as it has other capabilities:

I find very, very useful the possibility of running specific tests from the command-line (tcm run) and, very helpful in case of migrations and integrations, downloading the XML mapping of Bugs, resolutiontype and failuretype with tcm fieldmapping.