Thursday, 5 March 2015

Why can’t I output the result of git log from a PowerShell script?

Git log is a special command, it uses a pager and it seems the PowerShell ISE hangs when you run into that kind of commands. If you try creating a script relying on running git log in whatever form, you won’t get anything.

The workaround is not the very best, but it does the trick:

$logcommand = "git --no-pager log ... [> file.ext if needed]"
Invoke-Expression $log

Other commands like git diff are not affected by this. This made me lose quite a bit of time this morning…but I am happy to be unblocked now.

Wednesday, 25 February 2015

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:AT8
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:AT9
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.

Thursday, 12 February 2015

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.

Wednesday, 11 February 2015

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.

Tuesday, 3 February 2015

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.

Thursday, 29 January 2015

My first approach with open-source: TFSThemeUploader

To be fair, I’ve never been involved in open-source very much. I mean, personally. Moreover, I have always been quite shy of my stuff, as nowadays I mostly write scripts and no longer full-fledged production applications.

But anyway I decided to give it a go. So please, do not shoot the pianist, alright? :)

TFSThemeUploader is a simple PowerShell script aimed at automating the scenario described in this MSDN article. I’ve always thought it is quite tedious to manually complete, as it requires a bit of fiddling around XML and command-line tools. There is absolutely nothing wrong with it, but when you need to perform the same actions for more than one or two projects it isn’t very…compelling – hence the script.

I might expand it actually, to make it a bit more user-friendly and to expand the possible scenarios, I have a couple of ideas. But for the meantime, it is a good start I think.

Saturday, 17 January 2015

Continuous-Integration-as-Infrastructure and Git Flow

This came out at Friday’s meeting of the London ALM User Group – can I set up an infrastructure CI build for my whole Git project, configured with Git Flow?

I think Git Flow is a great piece of tool for non-enthusiasts or anyway people with limited interest in understanding Git. It creates a naming convention skeleton for your branching strategy, and using SourceTree you can let this kind of users work on their stuff with limited supervision.


So, thinking on it – can Team Build help? Of course it can!

If you select the appropriate Include statement for the branches you’d like in the Build Definition, it is literally one click away:


Doing so you are telling the Team Build to run a build (CI in this case) on the feature/* branch, where of course the star is a wildcard. Every branch you are going to create will benefit from it without any effort.

So you commit whatever you need, and the CI is already working for all you wish - given the mapping.

gitflow2 gitflow3