Are You DevOps?

Software engineering even as a relatively young discipline can still point to a plethora of different approaches to its implementation.

Many come and go but some gain traction until they become standard perceived wisdom.

One practice that is moving towards achieving that status is DevOps.

Many others have listed the values that DevOps holds dear alongside the techniques used to achieve them, but how do you know when you can truly say you have achieved a DevOps culture?

When You Postpone a Release

A core tenant of DevOps is to increase the speed and frequency of delivery, a failure to achieve these things is a principle reason that holds people back from both a DevOps culture and being truly agile.

However once you are comfortable with a DevOps approach then you will have reduced a release into production to be business as usual, simply a consequence of your teams completing work.

This nirvana means you will no longer be tied to a rigid left to right series of releases and will be much more confident to release when code is ready.

You are achieving DevOps when you can postpone a release without causing stress or discomfort to your teams or stakeholders. If something isn't ready today maybe it will be ready tomorrow or the day after, whenever it is ready we'll ship it.

When Development Teams Make an Infrastructure Change

A DevOps mindset tends to acknowledge that we have developed pretty effective ways to manage source code, so why don't we try and extend that philosophy to other areas of engineering.

All software requires infrastructure to be deployed to and run on. The definition, maintenance and management of this infrastructure has very often been a sticking point for teams that requires engagement and therefore dependency on others in the organisation.

A DevOps mentality combined with the ever increasing toolbox provided by cloud computing have given rise to a situation where we can define our infrastructure using tools that stand very close comparison to source code.

Not only does this mean it can be managed using similar tools but also that it can accept the rate of change and modification that we would normally only expect to see from traditional programming.

When You Fix a Bug Found by Automated Testing

A DevOps approach employs near continual testing of the system being developed.

These tests may operate at different levels, from unit tests to integration tests to automated UI tests. All these tests suites are automated and can be triggered from any event in the build system.

This can provide a dramatic increase in the amount of testing a code base is subjected to making it possible to simulate much more usage of the system than is possible via more traditional methods.

These increased levels of usage will result in bugs being exposed during development that would normally only be seen during production volumes.

We shouldn't expect to never see bugs in production again, but any tool that can increase the number of potentially user impacting bugs that are fixed prior to release has to be of value to any development team.

It is usually not possible to say that any approach to software development has truly been achieved. Most, including DevOps, have more to do with instilling a certain frame of mind within a team to influence decisions that are made as part of delivery.

In this sense no team can be said to have achieved DevOps, they may simply be more experienced in the application of the philosophy, they have moved past some of the more obvious pit falls and are reaping some of the benefits.

The intangible nature of achieving DevOps makes it even more important that we recognise the practices and behaviours that indicate that we're heading in the right direction.

The journey may never end but there are sign posts along way.