Unit Testing Powershell with Pester

I write a lot of Powershell these days; it’s my go-to language for quick jobs that need to interact with external systems, like an API, a DB, or the file system for example.

Nothing to configure, nothing to deploy, nothing to set up really; just hack a script together and run it. Perfect for one-off little tasks.

I’ve used it for all manner of things in my career so far, most notably for Azure automation back before Azure had decent automation in place. We’re talking pre-Resource Manager environment creation stuff.

I would tie together a suite of separate scripts which would individually:

  • create a Storage account,
  • get the key for the Storage account,
  • create a DB instance,
  • execute a DB initialisation script,
  • create a Service Bus,
  • execute a Service Bus initialisation script,
  • deploy Cloud Services,
  • start/stop/restart those services

Tie that lot together and I could spin up an entire environment easily.


Continue reading

Upload to Azure Blob Storage using Powershell

I needed to automate the process of uploading images to Azure blob storage recently, and found that using something like the excellent Azure Storage Explorer would not set the Content Type correctly (defaulting to “application/octetstream”). As such, here’s a little script to loop through a directory and do a basic check on extensions to set the content type for PNG or JPEG:

The magic is in Set-AzureStorageBlobContent.

Don’t forget to do the usual dance of calling the following!

These select your publish settings file, and set which subscription is the currently active one:

  • Import-AzurePublishSettingsFile
  • Set-AzureSubscription
  • Select-AzureSubscription


Actually, the Aug 2014 version of Azure Storage Explorer already sets the content type correctly upon upload. Oh well. Still a handy automation script though!


My thoughts from the recent #devopsdays conference in London; notes, inspiration, todos, ahas, and OMGs.

(Since my handwriting was so poor on the first day and my name badge was illegible, this was the badge for day #2!)
@rposbo name badge

Wow. There’s a lot to learn about this whole DevOps movement, but I actually feel that I can contribute to it having a pretty broad range of experience; I’m mainly development, but over the past decade or so have turned my hand to basic sysadmin-ing, DBA-ing, QA-ing, BA-ing, dev managing – almost all of the areas that need to be covered. I like to think of myself and a catalyst for implementation 🙂

I had initially been concerned that I lacked depth in skills like virtualisation and automation, but I’ve realise that those systems like Puppet, Chef, and Vagrant are potential solutions to a problem of configuration management (CM) and automation. Understanding the need for these tools is half the battle; being a specialist in them isn’t completely necessary, but an understanding to a level of basic implementation would be useful.

I’m already enrolled on a bunch of puppet webinars so will be getting stuck into that more soon.

Even though I’m pretty new to this, chatting with some key people did validate my thoughts that people shouldn’t be referring to “devops” as a person or a role in their presentations instead of an approach/framework/culture.


What happened at #devopsdays?

After being drawn in to the Basho booth by a raspberrypi/arduino/riak mars-rover-esque robot and chatting with John Clapham, who I didn’t realise was about to do the second presentation of the day (!), I end up deciding to sit right at the front (like a swot).

This turned out to be a great move as I ended up chatting with the organisers and even one of the founders of the DevOps movement, Gene Kim. Really nice guy, looks exactly like his twitter avatar (unlike some of us.. ahem..), and he even took a picture of the two of us together and let me know how to get onto the book review group for the long awaited DevOps Cookbook – bloody nice chap.

Chris Little, from BMC, is a really interesting guy to talk to as well – gave me a great overview of the background to DevOps, its “founders”, and helped me understand both its role in a company and in the future of the industry.

A pic Chris took from the stage
A pic Chris took from the stage
Try to play Where’s Wally and find lil old meeee…!


Each day there were four main presentations to start with, then some “ignite” talks.

I’m not going to try to go into the details of these presentations as 1) I’m lazy, 2) I tried to take notes on my phone and the battery died, and 3) other people have done it much better than I would have anyway!

Essentially, I found several of the presentations difficult to really grasp as I felt I was lacking a frame of reference. Perhaps this was just me not having enough of a Ops background, but I felt that the presentations could have benefited from a slide or two at the start laying the foundation for the remainder of the talk.

I was very glad to see at least one full presentation being completely non-technical, and instead focussing on the culture side of DevOps.


The afternoon of each day was put aside to OpenSpaces: everyone has the opportunity to propose a discussion topic, pop it on a post-it, people who want to vote can take a marker and add a dot on the post-its that they’re interested in. Those with the most dots get allocated a room and a time, and the discussions commence.

I initially thought this was a bit of a cop-out: I paid to attend a conference and half of it is the other people who paid talking to each other?! Rip off!

However, the discussions that I chose to attend helped me understand much more about monitoring, logging, database CI, puppet/chef/CF Engine/vagrant basics than I could have got from the main presentations, so I’m a convert.


DevOps is an exciting opportunity to technically innovate around CI, automation, delivery pipelines etc, and also to work with the business to introduce concepts like Impact Mapping.

This is where I’ll be focussing my professional efforts for the near future. I think there’s a lot of potential to help relieve stress on development teams and operations teams and relieve frustration from the business teams that define the work.