Review – Professional Team Foundation Server 2013

It is The Book. It’s the book you should have on your desk, library, shelve, whatever if you are working with Team Foundation Server.
I can describe it as a the most comprehensive book on the matter, the go-to reference when you need to plan/understand/troubleshoot something on TFS.
The 2013 edition is even better than the last year’s one, covering Git and the Distributed Version Control System, Visual Studio Release Management and all the new stuff of the latest version – Visual Studio Online included.
Everything is very smooth and in deep as you’d expect – you won’t find generic stuff or something about Visual Studio or MTM. If you are searching for them, you should see other books. It is not a pure beginners’ book: the planning section for example is very specific.
But even if you are a regular user, you are going to get a lot of value from the book. I strongly suggest it to everybody, from who uses TFS every day who wants to understand what goes on behind the scenes to the hard-core Team Foundation Server Administrator.

How to use PowerShell DSC with Visual Studio Release Management

After the brief introduction earlier this month it is now time to push forward – let’s see how the Update 3 CTP of Visual Studio Release Management enables you to push your DSC scripts to the target machines.

Firstly, the script. To keep things simple, I decided to deploy my script in an independent build and then leverage on VSRM for the deployment – no build template integration.

[sourcecode language='powershell' ]
Configuration DemoAppConfig
{
    param($servers="localhost",
    [String]$SourcePath = '\\dtfsat\Build',
    [String]$AppPath = 'C:\AppPath'
    )
    Node $servers
    {
        File CopyApp
        {
        Ensure = 'Present'
        Type = "Directory"
        Recurse = $true
        SourcePath = $SourcePath
        DestinationPath = $AppPath
        }
    }
}

DemoAppConfig

[/sourcecode]

Then we can create a new Standard Environment:

which is going to contain our agentless target server. To configure a target server, you’d need to run Enable-PSRemoting –force and winrm qc –transport:HTTP from PowerShell.

This server must be added using the FQDN and the listener port – the 5985 is the default port used by the HTTP listener.

This server is always going to be in a Ready status as long as there are the required permissions in place.

The only missing bits are the Component and the Release Template. As mentioned, the Component is going to be picked from an external network share (the build drop location) and used as-is. This is just for this sample anyway, the standard Build Definition used by VSRM would work as usual.

The big difference stands in the Deployment Tool used for the component – it is going to be Run PowerShell on Standard Environment, which provides all the facilities for running the DSC script:

This is going to be our single entrypoint for running DSC script. Moreover – if you look at the Release Template toolbox it is quite…empty:

But it would work like a charm :) The Deployment Sequence is going to be pretty lean as well: invoking the Component’s deployment for the target server – and that’s all:

This is what you are going to need to create a basic DSC-based deployment using Visual Studio Release Management. No rocket science required!

A quick look at the Team Foundation Server’s permissions inheritance

Straight with the sample – why does it happen…

…even if my user is a Project Administrator?

Because the single user’s permission are less important than the Team’s one – and as in this team there is a explicit deny on that permission (Edit project-level information) even if he is an Administrator he is going to get a deny.

Indeed…

That’s because you can be the CEO, but you won’t be allowed to change the delete the Team Project on your own if you’d be fired, for example :)

PowerShell DSC – extreme automation in a DevOps world

Release Management Update 3 CTP1 introduces support to PowerShell Desired State Configuration to deploy applications in your environments – this is utterly cool, but…why?

Before looking at VSRM itself, I think a bit of introduction to DSC is needed.

PowerShell Desired State Configuration is a new management platform built-in in Windows and based on, guess what, PowerShell. It can do a bunch of useful tasks, which I leave to the documentation because I just want to dig into the core concepts.

As it is built-in in Windows, it is agentless. Well actually the agent is inside PowerShell and Windows Management Framework, but for our purpose (deployments) we can consider whatever system running PowerShell 4.0+ (so Windows Server 2008 R2 and above, just by installing PS 4.0 and WMF 4.0) a DSC-capable system.

All of that goodness relies on a keyword – Configuration. If you set a Configuration block at the beginning of the script, you are invoking DSC.

DSC uses a .mof file which is created by the script itself, so after creating and running the script you just need to call Start-DscConfiguration with the appropriate parameters.

Let’s see a code snippet, it is very easy to use

Configuration InstallFX35_45
{
    param($servers="localhost")
    Node $servers
    {
        WindowsFeature Net-Framework-Core
        {
            Ensure = "Present"
            Name = "Net-Framework-Core"
        }

        WindowsFeature Net-Framework-45-Core
        {
            Ensure = "Present"
            Name = "Net-Framework-45-Core"
        }
    }
}

Here it is. The Configuration block is called InstallFX35_45 – it will check for the .NET Frameworks 3.5 and 4.5 on the target servers (or on just localhost if not specified) and, if any of them are not present at runtime, it would automatically trigger the installation of what’s missing via Install-WindowsFeature.

We just have to launch it, to get the .mof file, and invoking Start-DscConfiguration:

InstallFX35_45 -servers "PTFSDT", "PTFSAT"
Start-DscConfiguration -Wait -Verbose -Path .\InstallFX35_45

Everything is handled by the OS – so what we should care about is the whole configuration, nothing else. This specific solution addresses almost all the needs we might face in a DevOps environment – and in a very robust way!

DSC scripts are idempotent – so you can reapply a change and get to your desired state (hence the name…) regardless of the current status. No complex logic for catching exceptions or incremental changes – all is handled by the underlying infrastructure.

You can use DSC for installing roles, services, interacting with IIS, copying files…all from PowerShell, and in a completely reproducible environment.

The PowerShell team released a very handy Resource Kit, to get started with DSC and, eventually, DevOps – you can download it here.

 

.