When DevOps used to be called Beer...

Looking back I see a number of phases in how software was deployed. This is largely from my experience of investment banks but may well be relevant in other business areas too.

Pre-2001, a lot of releases where performed by UNIX System Administrators (SAs). Getting approval in some cases was manual. We'd print out the approval form and get the business to sign it. If you wanted an SA to do something for you it helped if you had purchased that person (or his manager) a beer recently. Even better, if you had managed to get this person into a taxi at the end of the night to get them home. Relationships and trust where established in well known City public houses.

After 2001, we all became more professional (which wasn't a bad thing) and this practise changed. Along with it though, we saw 'silo-isation' happening and teams (empires) got created that communicated only through horribly generic request systems. Frequently SAs and DBAs started to be located in different buildings to developers. This built physical and logical walls between teams making 'working together' very tricky.

This got so bad that Technical Project Managers where needed to interface between the developers, application support teams, DBAs and SAs. They needed to understand the language of each team to get the project delivered.

In 2008/09 the business realised that they weren't making as much money as before and that they were spending a lot on IT. In the drive to become more efficient we began the long road to automation of deployments. This involved a lot of untangling of spaghetti processes and unraveling of manual tasks while all the time keeping the business in business. People (especially managers) don't generally like change so a lot of convincing was needed. The result has been a huge drop in the support required for deployments and a reduction in the human errors.

There was a slow reduction in the need for SAs/DBAs in the deployment cycle – which suited them. The separation of SAs/DBAs from developers is still work in progress I think and where DevOps really has the power to change.

As a summary, DevOps, to me, means to do your job as an organisation better, deliver better software more efficiently. The two main tools, as I see it, are:

1.  Effective and open communication between teams.
2.  Automating the build, test and deployment of software.

At Vamos Deploy we think deployments should be easy, configurable, auditable and standardised. Deployment should be one of first things to get right, not an annoying afterthought in building your application. Any deployment should just fit in with the existing framework. You should be free to use the language of your choice. You should be looking forward to deploying and the happy smile of gratitude from your users. Vamos was designed and built keeping all of this in mind (and your annual bonus).