There’s no ‘I’ in team: DevOps done right

I have always been a firm believer in multi-disciplinary teams, possibly something that stems from the work I used to do to fight fraud at the Serious Fraud Office. At the SFO, a case team led by a lawyer had police, accountancy, and IT expertise all coming together to get the job done. In other disciplines we have singing, guitar , keyboard and drums to make great music; surgeons, anaesthetists and nursing staff to ensure we have a good outcome from a medical procedure. This all begs the question, why is this practice not more common in IT?

DevOps is what I am talking about here, but while that may look good on a CV, how many of us are actually doing it properly? Or even understand that it is much more about people than process or technology? For me, it was all became clear to our team of evangelists at a recent off site. Unlike the usual off-site where teams climb mountains or hang in the woods, we elected to work the problem by running our own internal hack. It not only enabled us to understand each other better, but it gave us space to apply DevOps principles for real. Like any hackathon we all wrote projects on a board. I signed up to do something real and to test a hypothesis I had – “Microsoft’s tooling can enable DevOps”.

The Project

Martin, one of our web developers, runs his wife’s online retail store on Azure, but hasn’t really setup testing and has a monolithic approach to coding so changes take too long to get live. This means his wife has to wait for changes, making experimentation hard – what is known as hypothesis based development. The web site was written in .net backed by an Azure SQL Database, so a good candidate to use Microsoft tooling, for example Visual Studio Online, against.

The Team

Martin, the other developers and an architect were joined by PowerShell MVP Jonathan Noble and myself to add in the Ops balance to the team. Jonathan and another PowerShell MVP, Richard Siddaway, were invited to this event to add more Ops expertise to our developer heavy group of 30+ evangelists.

What we did

Jonathan and I were interested in spinning up a testbed which could be torn down and recreated as needed. While we have both done a fair bit with Azure VMs, we hadn’t really tried to code services using PowerShell. To be honest we hadn’t done too much work in integrating PowerShell into any kind of Visual Studio, never mind the online version of Visual Studio. But before we got to coding, we needed to understand what we wanted to do and relate this to the actual problems Martin and his wife were having in making the website better.

It turns out that even if you don’t use Visual Studio for coding, you can knock up a plan in VSO - in our case a simple KanBan board:


The project tasks on the ops side, which I concentrated on, were focused on the ability to develop the DevOps principles of infrastructure as code, and continuous deployment where the former makes the latter possible. After some research we worked out that this was doable with a combination of PowerShell and VSO. We could code PowerShell  in VS2015:


I have connected my local copy of VS2015 to VSO, and it has pulled down and linked to our team project; this way our PowerShell is under source control. VSO can be likened to a virtual machine in that it will run this PowerShell for us, so we don’t have to worry about modules etc.

This approach also set off a few alarm bells as I was able to back up and copy the database from inside Azure because the Azure SQL had its firewall set to allow all ports! Another good reason for Devs and Ops to work together on stuff!

The other cool thing about our PowerShell is that now it is in VSO it can run as part of the build process, so if anything is not there (like the web servers) PowerShell will run to create it before the code is deployed:


Lessons Learnt

The key to all of this was the great working relationship in our team, the DevOps process and plan meant we could all work independently to a common purpose and bring our own skills to bear.

The Microsoft technologies really support DevOps. There are great Open Source tools out there, and if the existing web site we were working on was based on say PHP over MySQL, then it would have made sense to do all of this another way. Nevertheless, we knew the Microsoft platform and we were able be effective just using Microsoft tools.

Bizarrely Jonathan and I wrote more code than the developers did!

Comments (2)

  1. Jonathan Noble says:

    The most bizarre thing was that I found myself saying to a developer "Well it works on my machine!"

  2. Robert Lundkvist says:

    Well, with Windows Containers you should get away from the 'it works on my machine' comments…

Skip to main content