This incredibly powerful feature of PowerShell probably wouldn’t be a best kept secret if it had a less ridiculous name.  If it was called by a more boring, yet descriptive name, such as “dynamic parameter matching” or even “parameter unfurling” it would at least give an indication as to what it actually did.

The standard way of passing values into PowerShell functions is via a named parameters, for example:

which results in the output:

Hello World!

This is perfectly fine if you only have a few parameters, but if you are writing more complicated scripts (the standard example is some form of WMI query which requires a large number of parameters) it can become quite unwieldy.

Splatting allows you to convert those named parameters into a dictionary or hash and pass them into the function. The keys in the dictionary or hash will be examined to see if the match the names of the parameters and they do the values will be passed in. So if we refactor the above script to use splatting, it becomes:

which results (as expected) in exactly the same output:

Hello World!

But the power of the splatting does not stop there. If you are working on more complicated PowerShell scripts, especially the kind that encapsulate workflow or automation steps (for deployments or environment provisioning) you generally have a top level orchestration function which then calls into a series of inner functions which carry out individual steps.

Without splatting it’s very cumbersome to try and pass values down through the call stack. But if you combine splatting with the power of the @PSBoundParameters then you can pass the top level parameter collection down through the layers:

which results (as expected) in exactly the same output:

Hello World!

The combination of these two features leads to some truly interesting possibilities. We have various ALM offerings around continuous deployment and environment provisioning, which has had enormous positive impact on our client’s productivity.  PowerShell has always played a major part in our automation story, but orchestrating the various scripts has always been a bit messy. Splatting has allowed us to refactor and distil our scripts to the point where our configuration data almost looks like a DSL, which drives the individual automation tasks.

The example below simulates the steps required to provision an IIS Website, Application Pool and to configure HTTP and HTTPS bindings. All the configuration data is held in a hash at the bottom of the example and is simply splatted into the top level orchestration function, the values are then automatically passed down to inner functions via the use of @PSBoundParameters.

Which outputs the following:

Endjin_Web_App_Pool
Endjin_Web
Endjin_Web_App_Pool
192.168.100.10:80:endjin.com
192.168.100.10:443:endjin.com

As you can see, the combination of splatting, @PSBoundParameters and PowerShell’s dot notation (which allows you to reference an element in a dictionary by it’s key) allows you to create powerful, yet easy to understand PowerShell scripts.

@HowardvRooijen

In this final part of this series about adopting GitFlow, we’re going to cover how we can use the exciting new feature branching abilities of TeamCity 7.1 to allow our continuous integration environment to work in harmony with GitFlow without incurring a DevOps overhead having to create build configurations to support all the different, sporadically created branches that the GitFlow process requires.

Enabling feature branching is very simple (as doing most things with TeamCity tends to be) – the first thing to remember is that you need TeamCity 7.1 or higher installed. I mentioned this because from the experience of many of our clients – a large number of people still seem to be running a TeamCity 6.5 install.

Enabling Feature Branches

For the project you are going to enable feature branching on, navigate to the “Edit VCS Root” page via: Administration > Edit Build Configuration > Edit VCS Root. The section you are interested in is the “Branch Specification” section:

TeamCity enables feature branching by allowing you to create a branch specification – a simple little configuration syntax that has the format:
+:<branch specification>
-:<branch specification>
Where + means include and – means exclude. You can use * to perform matches, for example
+:*
means include all branches, whereas
+:refs/heads/feature/*
means include all feature branches.

For ease of copying and pasting the values for GitFlow are included below:
+:refs/heads/develop
+:refs/heads/feature/*
+:refs/heads/hotfix/*
+:refs/heads/master
+:refs/heads/release
+:refs/heads/support/*
One thing to note is that refs/heads/<branch name> is the fully qualified name of the branch rather than the shorter version of just <branch name> that we’re used to using.

Feature Branch Builds

Enabling feature branches has two knock on effects – the first is that you can now filter your builds by branch:

Branches are grouped into two main categories “active branches” and “inactive branches”. An active branch is any branch that has had a commit within the last 7 days (this value can be changed by altering the teamcity.activeVcsBranch.age.days parameter). Inactive branches are ones older than the specified threshold. The reason branches “decay” is because on any project of reasonable size the number of concurrent branches can become large quite quickly.

If these branches didn’t become “inactive” the UI would soon become cluttered and unusable. In the screenshot above – you can see we have two active branches – develop and “gf005″, which is actually the id of the task within YouTrack. We like to use this convention for branch names as it makes it easy for anyone on the project to figure out which changes are in which branch.

If you want an unfiltered view of current activity, you can select “Active branches”:

The final knock on effect is that there is a new option available from the “Run Custom Build” dialog. This is very handy if you want to perform any advanced functions against a specific branch, for example deploy a specific version of a build from a specific branch (if you are using TeamCity as your deployment dashboard).

That’s really how easy it is to configure TeamCity to work with the GitFlow process. It may seem daunting at the outset – but hopefully this step by step guide illuminates how straight forward the process really is and might persuade you to invest a little more time experimenting with and improving your own ALM processes.

If you have any questions about the process – feel free to leave a comment or ping me via @HowardvRooijen

Every project starts the same way,
You create a place to put Solution Artefacts
On one file system
On one computer

Templify allows you to create a tokenised template of your entire solution. So if you’ve got a default web application framework, which includes a build system, some deployment scripts and other goodies and you want a way to package the whole solution up and allow others to share and reuse it, Templify is the answer.

It’s now almost three years old and quite a bit has changed in the world since then one of the main things being that NuGet has appeared and made package management a thing in the .NET world. The “package restore” functionality is especially interesting, as it allows you to package up just the source files for a solution without having to include the binaries, which vastly increase the size of any redistributable zip of a solution or demo you’d want to share.

In that three year period there have only really been two major bugs reported – the first was more a complaint than a bug – sometimes packing and unpacking a Templify package could be very slow. Thankfully a kindly user of Templify decided to try and get to the bottom of the problem and fixed it. The second problem reported was that some users found that Templify altered the file encoding (it would convert a file from ANSI to UTF8) of any file it tokenised. Luckily we had already solved this problem in another one of our internal build and deployment tools, so it was quite straight forward to make an IP donation to the Templify project.

One of the other changes to happen in the last three years is that Visual Studio 2012 was released and one of its key features is that it no-longer supports Visual Studio Installer Projects, which Templify uses. So as part of this new release I’ve created a new Advanced Installer based installer and our very own Paul Waller decided to spruce up the installer graphics to align with our new brand and website.

The latest version is now available for download, please provide any feedback via the GitHub page.

@HowardvRooijen

This post finally covers the nitty-gritty of how you use the GitFlow extensions to drive the workflow. Firstly the extensions add a new command, “flow” which has 4 sub commands (and one experimental – “support”) which encapsulate the workflow:

> git flow

• init
• feature
• release
• hotfix
• support

As each GitFlow command has a series of options – it’s probably best to cover them off one by one:

> git flow init

This command initializes your existing git repo to use the GitFlow extensions. The extensions don’t perform voodoo magic – they don’t do anything special to your repo – they are simply scripts that automate a series of existing git commands to create a “pit of quality” that allows you to easily follow the conventions – if you had an aversion to working smarter you could manually run all the git steps, following the same conventions and achieve the same ends – but why go the long way round?

When you run the following command:
> git flow init
You will be ask if you want to override the default naming pattern (hint – you don’t, but it’s always nice to be asked).

If you find having to hit enter multiple times bothersome then you can use the following command to initialise your git repo with the default settings:
> git flow init –fd
The screenshot below shows the difference:

> git flow feature

This is probably the command you will most use in your day-to-day development activities. In essence it doesn’t do anything particularly special – it just creates a branch in which you can develop a feature. The point is that it’s a very low friction way of creating an isolated sandpit for you to create a new feature in. Just like any other branch in git, you can push it up to a remote repo to share it with other developers to collaborate and push, pull and rebase just like you would if you developed just in the master branch.

The point of the feature branch is that it should contain a small unit of work (we’re talking hours or days worth of work, not weeks or months) and that there can be many feature branches being worked on independently as in the following workflow visualisation:

The full list of GitFlow feature commands are as follows (many of them should not be a shock to the system as they are just standard git commands):

• git flow feature [list] [-v]
• git flow feature start [-F] <name> [<base>]
• git flow feature finish [-rFkDS] [<name|nameprefix>]
• git flow feature publish <name>
• git flow feature track <name>
• git flow feature diff [<name|nameprefix>]
• git flow feature rebase [-i] [<name|nameprefix>]
• git flow feature checkout [<name|nameprefix>]
• git flow feature pull [-r] <remote> [<name>]

The most common commands you will use are the following:

• start <name>
• finish <name>
• publish <name>
• track <name>
• checkout <name>
• pull <remote> <name>

> git flow feature start <name>

Naming your feature branch is an interesting topic – our standard is to use the Id of the work item you are delivering – in our internal devlab that is the YouTrack Id. The reason we do this is so that it’s absolutely apparent to anyone in the team what a particular branch relates to. This convention works well for hotfixes too as these are generally recorded as bugs in your work item tracking system.

The screenshot below shows the process of creating a new feature for a specific work item id (gf006). GitFlow provides you with a nice set of instructions on what to do at the next step of the workflow.

To backtrack to the “the extensions don’t perform voodoo magic” point the command:
> git flow feature start
Translates to:
> git branch feature/<name>
> git checkout feature/<name>


> git flow feature publish <name>

Now you’ve created a feature branch – you might want commit your initial changes either to ensure they are backed up on the remote or to collaborate with other colleagues. To do this you need to issued the following command:
>git flow feature publish <name>
This command translates to the following native commands:
> git push origin <name>
> git config "branch.<name>.remote" "origin"
> git config "branch.<name>.merge" "refs/heads/<name>"
> git checkout "<name>"


> git flow feature pull <name>

Similarly if you are the other collaborator and want to get the feature branch, you would issue the following command:
> git flow feature pull <name>
For the first time feature pull, translates to:
> git fetch -q "origin" "<name>"
> git branch –no-track "<name>" FETCH_HEAD
> git checkout -q "<name>"
And for any subsequent feature pull translates to:
> git pull -q "origin" "<name>"

> git flow feature finish <name>

Once you completed work on your feature, it’s time to merge it back with the main develop branch. To do this you need to issue the following command:
> git flow feature finish
This translates to the following native commands:
> git checkout develop
> git merge –no-ff "<name>"
> git branch -d <name>

> git flow release

Now you have a feature that’s complete, you probably want to bundle this up into a release so that you can push it into Production. The purpose of this branch is to test, stabilize and finally release the changes. The diagram below visualizes the workflow, showing how features eventually make there way into a Release branch:

As you can collaboratively make changes to code in the branch – the sub-commands available are very much aligned with those available for feature branches:

• git flow release start <version>
• git flow release finish <version>
• git flow release publish <name>
• git flow release track <name>

> git flow release start <name>

Just like a feature branch you need to “start” it – the screenshot below shows the process of creating a release branch called “iteration01″ from within the feature branch “gf006″. Note how the release branch is created from the “develop”  branch rather than the feature branch:

Now the branch is successfully created and testing and stabilisation can continue.

> git flow release finish <name>

One your release has exited the final quality gate and is ready to be released into production – you can “finish” the branch. Note from the screenshot that you should provide a message.

This command is a façade for a whole series workflow steps:

> git flow release finish -F -p iteration01
Translates to:
> git checkout master
> git fetch origin master
> git merge –no-ff iteration01
> git tag -a iteration01
> git push origin master
> git checkout develop
> git fetch origin develop
> git merge –no-ff iteration01
> git push origin develop
> git branch –d iteration01
If you are not familiar with the standard git commands – the above steps translate, in English to:

• Latest objects have been fetched from “origin”
• Release branch has been merged into “master”
• The release was tagged “iteration01″
• Release branch has been back-merged into “develop”
• Release branch “release/iteration01″ has been deleted
• “develop”, “master” and tags have been pushed to “origin”
• Release branch “release/iteration01″ in “origin” has been deleted

At this point the changes for your next release exist on your master branch and have been tagged with the version number specified.

> git flow hotfix

The hotfix command has been created to solve the problem of defects slipping through the quality gates and being identified in production. This branch exists to allow a single defect to be fixed, tested and then merged back into the master branch. This is not a process for adding extra features into the production release – this should only be used to fix a specific defect – any other features should be handled in the normal way using feature branches. The diagram below visualizes the workflow:

The following sub-commands are available:

• git flow hotfix start <version>
• git flow hotfix finish <version>
• git flow hotfix publish <version>
• git flow hotfix track <version>

> git flow support

This is still considered an experimental feature for the case where a team has a product that supports multiple customers who need fixes but don’t want to upgrade to new release. The diagram below visualizes the workflow:

And that’s it – GitFlow is a simple, low ceremony set of extensions to automate a simple convention for managing the complexities of dealing with the software development release cycle.

In the final part of this series, I’ll show how you can configure TeamCity to work in harmony with GitFlow.

One of the most interesting developments to happen in the Git ecosystem (apart from its growing adoption rate) is the creation of the Git Flow branching model and its embodiment as an plugin extension to the core Git client libraries.

GitFlow sets out to answer the following questions that plague every software development team:

How can we:

• Keep our repository tidy?
• Have consistency between projects?
• Get our developers up to speed quickly with our procedures?
• Enable the team develop a feature in isolation from the main branch, but also allows them to collaborate?
• Stabilize before a production release?
• Manage production releases?
• Manage production hotfixes?
• Customize our codebase for a specific customer without that affecting another customer?

The solution GitFlow proposes is a prescriptive branching model, born of experience which answers the questions above, and a set of Git Extensions that allow you to manage and automate work through that model.

GitFlow specifies the following branch structure:

• master
• hotfixes
• release branches
• develop
• feature branches

Master

Instead of the master branch being the default bucket where all changes happen, in GitFlow the purpose of this branch is to contain code that’s in a production ready state. You should be able to deploy code from this branch into production at any time and the code in this branch can be tagged with a specific release number to aid that process. This is quite a change for most development teams where 99% of the development happens in the master branch. GitFlow enables you to put a quality gate around the master branch, using workflow, as it requires actual effort to create a release, and then merge that release back into master.

Hotfixes

This branch is a special case for dealing with urgent defects discovered in production post release. The purpose of the branch is that you make a single change to fix the issue (you do not slip other features into this fix as this could introduce other stability issues). This change is then folded into the master branch and also into the develop branch.

Release Branches

This branch is used for gathering features for future release. This branch is also useful for release stabilisation – making changes required to fix issues discovered by any final exploratory testing.

Develop

This is the branch where “general” development activities can occur (rather than on the master branch). This branch can become the general bucket for all changes – but this is really not how it should be used. Any piece of significant work should be done inside a feature branch.

Feature Branches

These branches are for developing an individual feature – this can be dictation by a set of required changes, a backlog item, a bug – essentially any unit of work that needs to be carried out. These branches are short lived – they should not be used for weeks or months on end (otherwise you will incur large integration problems as code on this branch will be out of date compared to all the other work going on).

Visualising the Workflow

The easiest way to visualize the pattern is a process flow diagram, showing how changes flow through the development cycle. The arrows signify the creation of or merging of a branch, the dots represent a commit:

Just to re-iterate one point – branches should not be long lived – they are not another mechanism to allow developers to go dark: the longer a branch lives, the more pain you are incurring for yourself (and your team) when you come to re-integrate your changes. GitFlow is not a silver bullet to solve all your release cycle problems, it’s a pattern and workflow for reducing the friction, but the work still has to be managed; hotfixes, features and releases have to be planned and managed – otherwise you have just added complexity to the chaos.

Installing GitFlow

There are two ways in which you can install GitFlow:

• Download getopt.exe & libintl3.dll from http://bit.ly/XdYcBc
• Extract and copy to: C:\Program Files\Git\bin
• Clone the GitFlow Repo, but running the following command from Git Bash:

$ git clone --recursive git://github.com/nvie/gitflow.git
$ cd gitflow


• Run “C:\gitflow> contrib\msysgit-install.cmd” as Administrator

Or you can:

• Download https://dl.dropbox.com/u/5892928/DevTools/Endjin.DevTools.Git-Flow.7z
• Unzip and run Configure-GitFlow.ps1

As GitFlow is a series of Git command line extensions – you’ll need a nice command line environment (if you don’t already have one).

Using Chocolatey to install Posh-Git

Chocolatey seems to be one of those “best kept secrets” on the Microsoft world – it’s essentially apt-get but based on the NuGet feed protocol. To install Chocolatey first you just need to open a PowerShell prompt and execute the following command:
@powershell -NoProfile -ExecutionPolicy unrestricted -Command "iex ((new-object net.webclient).DownloadString('http://chocolatey.org/install.ps1'))" && SET PATH=%PATH%;%systemdrive%\chocolatey\bin

Now you have Chocolatey installed – you can use it to install Posh-Git – which essentially allows you to use Git from within your PowerShell environment. Issue the following command:
c:\> cinst poshgit
Chocolatey will locate, download and install Posh-Git.

When you navigate to a Git repo inside the PowerShell command environment you should get extra information about the state of the repo and which branch you are currently on. This is very useful when using GitFlow

Now you should have your environment correctly set up to use GitFlow. In the next part of the series, we’ll cover off how to actually use it.

• set up a business bank account,
• set up a FreeAgent account, for all our accounting needs
• signed up for Office 365 (or BPOS as it was then),
• registered the endjin GitHub account
• built a virtualised Continuous Integration Environment using TeamCity.

With those 5 simple steps, we had all the systems we needed to run our company.

Quite a bit has changed within the company in the last 24 months, but Git & TeamCity have remained an absolute cornerstone of how we do day to day development and “work smarter”; teaching other companies to do the same has become one of our core consultancy offerings in the ALM / DevOps space. It’s no co-incidence that on his first day, our apprentice was shown how to set up and configure a GitHub repository and push his first commit, or that we publish a Step by Step guide to Hosting TeamCity in IIS 7 or that we released a set of PowerShell cmdlets for managing and interrogating TeamCity.

These systems are absolutely fundamental to what we do.

To anyone who has worked within the Microsoft space and has grown up using Visual Source Safe or Team Foundation Server, branching is something to be feared and avoided at all costs unless you want daily nose bleeds.

In these systems, changes are stored as deltas or changesets, the result of which is that in their branching model, branches sit side by side on your file system.

This means that to create or swap between branches has significant overheads, which means if you’re developing something like a web application, you have to reconfigure IIS to point at the branch you’re currently working on. Also every branch you create requires N amount of disk space, where N is the size of the main branch. Nothing insurmountable, but just added friction.

Along came Git

Git is the total antidote. Rather than pay a branching tax, it’s actually a bit more like getting a branching rebate. Git stores changes as snapshots, therefore a branch is simply a moveable pointer to a specific commit (the actual implementation detail is that a branch is actually a SHA1 checksum of the commit).

“I’m an egotistical bastard, and I name all my projects after myself.
First ‘Linux’, now ‘git’.”

Linus Torvalds
Creator of Linux & Git

Instead of having multiple branches coexisting side-by-side on your system, in Git creating a new branch involves writing 41 bytes to a file.

My favourite way of describing the difference between the TFS and Git branching models is as follows, in TFS – branching is essentially like the TV Show Fringe in that you have to deal with parallel worlds crossing between those world is a difficult process with severe health risks to the person “crossing over”, whereas with Git is more like Doctor Who: branching is essentially dealing with time streams where you can easily go forwards, backwards and even sideways.

vs.

So it’s essentially Parallel Worlds vs. Wibbly Wobbly, Timey Wimey. And we all know bow ties are cool.

In the second part of this series – we’ll tell you a little bit more about the GitFlow branching model and how to get your development environment set-up and configured.

@HowardvRooijen

Endjin are proud to sponsor Agile:MK a new user group for Agile Practitioners based in / around the Milton Keynes area.

The January meeting is on the Tuesday the 15th from 6pm – 8pm at Jurys Inn Hotel, Midsummer Boulevard, Milton Keynes, MK9 2HP

To be part of Agile:MK signup via the LinkedIn Group.

If you cannot attend the meetings – do not fear – you can still keep up to date with all the goings on via the Agile:MK Journal, Issue 1 is available to download by clicking on the image below:

@HowardvRooijen

The problem I wanted to solve was that I wanted to be able to geocode a user’s postcode and then calculate the distance between their location and another. There are plenty of paid for services out there but I remembered reading a blog post by Steve Wright about manipulating spatial data to get it into SQL Server.

The following sample utilises the Sql Server Spatial Types Assembly, which can be found on NuGet. Essentially it allows you to create a SqlGeography type from two strings that represent Longitude and Latitude, utilising the SqlGeography.STGeomFromText method and then calculate the Distance using the STDistance method (on the SqlGeography instance) to calculate the distance (in meters) between the two points. There’s a simple helper method to calculate the distance into Miles.

The solution is available from the endjin Samples repo on GitHub.

@HowardvRooijen

Rather than implement a PowerShell API from scratch I decided to “work smarter” and stand on the shoulders of giants – in this case fellow JetBrains Academy Member Paul Stack, who created a very nice C# TeamCity Wrapper called TeamCitySharp.

PowerShell is hosted on the CLR – so calling .NET types is a breeze – it was very straightforward to wrap the C# API. Firstly I used dotPeek to list all the method names and I pasted these into a new PowerShell script and converted each of them into the vanilla Pester BDD format and outlined some behaviours:

The next step was to create the parameters to pass into the cmdlet. To start with I mimicked the C# API and had expressive function signatures – but after writing the first couple of cmdlets did a small refactoring and switched to using splatting (one of the most unknown / underused features of PowerShell), which allowed me to create a pseudo ConnectionDetails object that is in fact a hashtable – which is a much nicer data structure for describing all the different connection options. The final step is to test the results of your cmdlet.

This test will obviously fail as we haven’t implemented the Get-AllAgents cmdlet – but that’s simple enough to fix:

Note the use of @PSBoundParameters – this allows you to splat the parameters passed into the current cmdlet into a nested cmdlet. Very cool indeed and saves a lot of typing.
I repeated the process for the rest of the TeamCitySharp API and created the following cmdlets:

• Get-AllAgents
• Get-AllBuildConfigs
• Get-ArtifactsByBuildId
• Get-Artifact
• Get-ArtifactsAsArchive *
• Get-BuildConfigByConfigurationName
• Get-AllBuildsOfStatusSinceDate
• Get-AllBuildsSinceDate
• Get-AllChanges
• Get-AllGroupsByUserName
• Get-AllProjects
• Get-AllRolesByUserName *
• Get-AllServerPlugins *
• Get-AllUserGroups
• Get-AllUserRolesByUserGroup
• Get-AllUsers *
• Get-AllUsersByUserGroup
• Get-AllVcsRoots
• Get-BuildConfigByConfigurationId
• Get-BuildConfigByConfigurationName
• Get-BuildConfigByProjectIdAndConfigurationId
• Get-BuildConfigByProjectIdAndConfigurationName
• Get-BuildConfigByProjectNameAndConfigurationId
• Get-BuildConfigByProjectNameAndConfigurationName
• Get-BuildConfigsByBuildConfigId
• Get-BuildConfigsByConfigIdAndTag
• Get-BuildConfigsByConfigIdAndTags
• Get-BuildConfigsByProjectId
• Get-BuildConfigsByProjectName
• Get-BuildsByBuildLocator *
• Get-BuildsByUserName
• Get-ChangeDetailsByBuildConfigId
• Get-ChangeDetailsByChangeId
• Get-ErrorBuildsByBuildConfigId *
• Get-FailedBuildsByBuildConfigId *
• Get-LastBuildByAgent
• Get-LastBuildByBuildConfigId
• Get-LastChangeDetailByBuildConfigId
• Get-LastErrorBuildByBuildConfigId *
• Get-LastFailedBuildByBuildConfigId
• Get-LastSuccessfulBuildByBuildConfigId
• Get-LatestArtifact
• Get-NonSuccessfulBuildsForUser
• Get-ProjectById
• Get-ProjectByName
• Get-ServerInfo
• Get-SuccessfulBuildsByBuildConfigId
• Get-VcsRootById

^{* denotes a cmdlet that has been implemented but doesn’t have a passing test (mainly due to a lack of rights on the http://teamcity.codebetter.com server).}

Although the tests are integration tests and a little slow to run – there is nothing more reassuring than having a full suite of specifications:

A simple example of using the TeamCityPowerShell API is as follows:

Very straight forward.

If you don’t want to store your TeamCity credentials in plain text you can either enter them interactively using the following code:

Alternatively you can retrieve them disk using this PowerShell Cookbook recipe: Importing and Exporting Credentials in PowerShell

One item to note - TeamCityPowerShell depends on TeamCitySharp which is a .NET 4.0 application. By default PowerShell only supports .NET 2.0 – to enable .NET 4.0 support copy TeamCityPowerShell\SetUp\PowerShell.exe.config to the PowerShell install directory – this allows PowerShell to host the .NET 4.0 runtime.

You can find TeamCityPowershell on GitHub. If you have any feedback – please get in contact.

@HowardvRooijen

I’ve spent more of the last year working inside PowerGUI than Visual Studio and I’ve tried hard to take a few of our customers on the learning journey too. I’m very pleased that after doing a quick brown bag session about PowerShell and knocking up a sample framework that one of the DevOps folks took it and ran with it – automating the provisioning of their internal development, test and production environments – from a series of thick word documents that took over 2 man days to work through (and were also horrifically prone to human error) to a series of PowerShell scripts that could automatically provision an environment within a couple of hours.

Thankfully there are a myriad of resources to help you learn PowerShell here are a select that I’ve found very useful:

Free Guides

If you really want to get your head around what comes out of the box in PowerShell 2.0 (which is installed by default on Windows 7 and Windows Server 2008) a great place to start is Jonathan Medd’s – PowerShell 2 – One Cmdlet at a Time – which does exactly what it says on the tin – it lists every cmdlet (think function) and tells you what it does and how to use it.

One of the least known and most powerful features in PowerShell is remoting – the ability to execute PowerShell scripts, in context on a remote machine. This opens so many doors from a DevOps perspective. On the downside – because remoting requires you to deal with networks and security – it can be a bit painful to get up and running with and another indispensible guide is Ravikanth Chaganti’s – Layman’s Guide to PowerShell 2.0 remoting – to tell the truth – I felt bad reading this free guide – the amount of real world knowledge and blood, sweat and tears problem solving is of such a high quality that it really shouldn’t be a free ebook.

Books

The two free guides really wet my appetite and I wanted more – both depth and breadth and I found this in abundance in Bruce Payette’s – PowerShell in Action 2nd Edition – if you want a holistic view of the platform – it’s a great start. If you want a more practical guide to how to use PowerShell there are two other great resources – first is Don Jones and his book Learn Windows PowerShell in a Month of Lunches. Don is a bit of a star he’s very active not only on his twitter account – but he’s also produced a seriously large number of accompanying screencasts, freely available on YouTube. The second is Lee Holmes (who’s been on the PowerShell team from the start), his book The PowerShell Cookbook is a wonderful resource – brimming with Problem –> Solution recipes; if you’re getting started with PowerShell these are the type of problems you are going to hit straight away and such The PowerShell Cookbook should be your first port of call. The latest PowerShell book I’ve been reading is PowerShell and WMI by Richard Siddaway which is a little more advanced and hard-core – but useful for those of us who want to interact with Windows Machines at a lower level.

Blogs & People

As always the first place for a Microsoft Technology is the Official Microsoft PowerShell Blog. Next would be the man behind PowerShell, Microsoft Distinguished Engineer and  Lead Architect for the Windows Server Division – Jeffery Snover, his enthusiasm for PowerShell and being more productive with automation is utterly infectious – he’s a really great speaker and I would highly recommend watching his talks (listed below). After Jeffery the next stop is Lee Holmes’ blog. When you get stuck and start searching for help – chances are you’ll land on Joel Bennett’s Huddled Masses blog – lots of great pragmatic content to be devoured there. Another great resource is the PowerShell Community Site.

Web Casts

If you don’t have time to read books luckily Microsoft have put a lot of effort promoting PowerShell at their various conferences and via Channel9. I can’t recommend these talks highly enough – the topics are wide and varied – from using PowerShell to manage servers, to using PowerShell to create a management API over your applications – each of the talk shows how flexible PowerShell is and how productive you can be with it.

Channel 9

• Jeffrey Snover & Bruce Payette  (2007) – Windows PowerShell: Origin and Future
• Jeffrey Snover and Dmitry Sotnikov  (2007) – Learn and Master Windows PowerShell with Quest Software’s PowerGui
• Expert to Expert (2008) – Erik Meijer and Jeffrey Snover – Inside PowerShell

PDC 2008

• Jeffrey Snover  – PowerShell: Creating Manageable Web Services

PDC 2009

• Kenneth Hansen, Narayanan Lakshmanan – Building Your Administration GUI over Windows PowerShell & Windows PowerShell: An Automation Toolbox for Building Solutions That Span Small Businesses, Enterprises, and Cloud Services

Tech-Ed 2010

• Mir Rosenberg, Refaat Issa – Advanced Automation Using Windows PowerShell 2.0
• Jeffery Hicks – Paradigm Shift: Microsoft Visual Basic Scripting Edition to Windows PowerShell
• Phil Pennington, Don Jones  – Manage Your Enterprise from a Single Seat: Windows PowerShell Remoting
• Don Jones – Inventory Your Network and Clients with Windows PowerShell

Build 2011

• Andrew Mason & Jeffery Snover – Windows Server 8 apps must run without a GUI – learn more now
• Jeffrey Snover, Refaat Issa – Make your product manageable & Manage a highly-efficient environment at scale using the Windows Management Framework (WMF)
• Christopher Palmer – Windows networking with PowerShell: A foundation for data center management

Tech-Ed 2011

• Dean Corcoran – PowerShell Above and Beyond: GUIs, Workflows, and More
• Don Jones – Windows PowerShell Remoting: Definitely NOT Just for Servers
• Dan Harman, Jeffrey Snover – Advanced Automation Using Windows PowerShell 2.0
• Jeffery Hicks – Managing the Registry with Windows PowerShell 2.0
• Jeffrey Snover – Windows PowerShell for Beginners

Writing testable scripts

One of the most immature aspects of the PowerShell platform is writing tests for scripts – I’ve tried many of the frameworks that are out there – each has it’s own strengths and weaknesses – but the framework I’ve been using (with some success) of late is Pester – a BDD style framework for PowerShell, you can grab the code from the official GitHub Repository.

Tooling

Lastly a word on tooling – even though Windows comes with PowerShell ISE (Integrated Scripting Environment) – I’ve found PowerGui to be a much nicer environment to work in – the debugging support (which you will need) is far superior to ISE.

Remember: work smarter, not harder!

@HowardvRooijen