News:  What is DevOps? (25/06/2016)

Here’s the Wikipedia definition:

DevOps is a software development process that emphasizes communication and collaboration between product management, software development, and operations professionals. DevOps also automates the process of software integration, testing, deployment, and infrastructure changes. It aims to establish a culture and environment where building, testing, and releasing software can happen rapidly, frequently, and more reliably.

One could argue that definition is on the opinionated side and that defining the approach as a ‘software development process’ is OTT.

DevOps has been facilitated by the move towards cloud computing and ease by which off premises IT infrastructure can now be provisioned, for example by service offerings such as Microsoft Azure. In parallel, if not earlier in part, there has been the push towards more agile (small ‘a’, deliberately!) approaches where we want the teams involved in software development to be more responsive to the needs of the business and their customers, whether internal or external. Thus, there is an increasing expectation that software should built responsively to the needs of the business whether this be in the form of shorter development cycles to more regular deployment to production.

To achieve this the boundaries between development (coding) and operations (server management) have become less isolated and the involved roles blurred. Hence ‘devops’.

Consider an example of a recent project where Propona have embraced devops. The project is a legacy multi-layered web forms application to a SQL server backend. We migrated this to Azure – web apps and Azure SQL Server databases: two web applications representing staging and production and three databases: dev, staging and production. The development web application would then be on the developer’s machine pulled out of a Git repository in BitBucket using SourceTree, for example, as our source control client. Further, we configured an Azure Virtual Machine to act as a build server utilising TeamCity and Octopus to automate the build and deploy to the staging server when checked into source control. As part of these steps the application is appropriately configured to the target environment. We could have incorporated tests in the build process but in this case we did not and we also left it as a manual step to deploy to production, which was actually an Azure deployment slot switch to minimise any downtime.

In terms of ancillary tools, we used Slack for messaging which we hooked into TeamCity to be alerted to the progress of builds by team members as well as any exceptions reported by bugsnag.

The time investment in configuring the devops tools and processes means we can deploy more often with more reliability and can always easily roll back to earlier code version in production. Thankfully, we’ve only needed this facility once so far.

Reference https://en.wikipedia.org/wiki/DevOps Back to News