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).

Application Deployment with Vamos Deploy

To demonstrate the ease of deploying applications using Vamos Deploy we have a demo application suite called Jupiter which has a client-server architecture.
Below shows the Jupiter_dev grid that we have setup: 

 $ vamos grid Jupiter_dev info
 Description    : Jupiter development
 Edit status    : Unfrozen
 Change status  : Changed
 Owner group    : developers
 Release group  : developers
 Applications   : JupiterServer             1.0.17      dev
                : JupiterUI                 1.0.37      dev
                : PythonDjango              1.7.1       dev
                : PythonGoogleFinance       0.7         dev
                : PythonLinux               3.4.lin32   dev
                : PythonRequests            2.5.0.1     dev
                : PythonRestFramework       3.0.0       dev
                : PythonWindows             3.4.win32   dev
 Properties     : jupiter_http_host = 192.168.56.101
                : jupiter_http_port = 8091
                : jupiter_window_title = JupiterUI-Version:1.0.37-Build:#52
 Repos          : arepo-nathan-pc             
                : arepo-vm-barcelona-alpha

A Vamos grid contains a list of applications, a list of properties and a list of repositories. When we deploy this grid the applications get deployed to the compatible repos with properties providing environment specific settings.
This grid is in a ‘Changed’ status because I updated JupiterServer to 1.0.17 earlier. To deploy this changed grid:

 $ vamos grid Jupiter_dev deploy
 Deploy of grid Jupiter_dev initiated. Release id 55
 Hint: Monitor deploy progress with:
       vamos deploy info --releaseid=55
 Monitor tasks with:      
       vamos task info --releaseid=55

Lets monitor the progress from the command line and from the Vamos Dashboard: 

 $ vamos deploy info --releaseid=55
 ReleaseId : 55
 Gridname  : Jupiter_dev
 Status    : Complete
 Start     : 28 Jul 2015 15:19:10 BST
 End       : 28 Jul 2015 15:19:10 BST
 User      : usera

Now thats completed we can start our new JupiterServer. This command line could be executed from a job scheduler. It doesnt need to change when a version of the application is deployed.

 arepo-vm-barcelona-alpha$ /vamos/ARepo/grids/Jupiter_dev/JupiterServer/bin/start_JupiterServer.sh

We can use VamosJump on my desktop (arepo-nathan-pc) to start JupiterUI:

In summary Vamos Deploy has delivered the JupiterServer application and its dependants to our Linux server and delivered the Jupiter UI to my laptop. We have environment specific properties set that enable the two to communicate.

Application Deployment Best Practises

Its 11:45pm on a Saturday evening and I’m waiting for the release of my application to the production environment. It was scheduled for 2:30pm but there was some delay with some other application. The production support team are almost ready to do my release but they have been saying that for 3 hours. It doesn’t have to be like this…

Having spent many years streamlining, standardising and simplifying complex deployment processes we have compiled a top 10 of best practises you need from a deployment process:

1. Automation. Get rid of all those manual tasks.
2. Consistency. Standardise as much as possible.
3. Audit trail. You need to be able to look back at who did what and when.
4. Visibility. You need to see what is happening now - to know the current status.
5. Promotional lifecycle. Only allow applications through the gate to the next level if they pass the tests.
6. Segregation of duties (SoD). Developers should not be gatekeepers to production. An access control mechanism should divide duties between different people or teams.
7. Reduce release notes to a minimum. The more steps in the release notes the more scope for human error. 
8. Deploy with consistency across all environments. The first time you fully deploy your  application should not in production.
9. Rollback strategy. Incase it all goes wrong you need to rollback to the previous working version as fast as possible. In reality, what is usually employed is a partial rollback or an emergency release if the fault can be fixed quickly.
10. Keep it simple and keep it clean!  Complexity is the enemy.

The good news is that Vamos Deploy ticks the box for all the above.

If you are lucky then you will have the time and personnel to redesign your entire release process end to end. In most cases the release process only gets attention when it gets really bad. Maybe the wrong application is deployed or it doesn’t work as expected in production and the delays cross into the unacceptable. So the little resources that does get allocated to improvements needs to be well spent. A deployment tool that can be integrated in phases is essential.