DevOps: The five biggest misconceptions

DevOps is the hot topic on everybody's lips. After all, who wouldn't want their software releases to be quick, straightforward and error-free without the inefficiency that occurs between contractors, development and operations? Urs Breu has been working in line with this approach for three years now and is only too aware of the most common misconceptions.

1. One person should be put in charge

So you've been put in charge of DevOps within your team and now you've got to make sure that this method is used for software delivery. Well, don't get too excited! Not only will you now be the last one out of the door in the evening, you are also the bottleneck in the project. What DevOps is actually all about is making sure that the process is automated as far as possible and is not dependent on just one person. Sure, there will usually be more 'manual work' at the start, but you will find you are able to, and indeed need to, automate the processes more and more as the project progresses. Every engineer needs to understand enough about the process that they are in a position to make a delivery. Ideally, even the customer will be able to deploy software without having to consult with the engineers again.

2. Testing takes too long

In my experience, even projects following the DevOps approach will often involve manual tests to start with. That's all well and good, but this process will take far too long for short, frequent release cycles. For our projects, we have automated the majority of the tests. Over time, our customers have really come to trust us when we say that these tests are effective and perfectly sufficient. Plus, they can shred a whole load of test scripts! And let me say this: an automated test that takes eight hours has been designed poorly.

3. Out of sight, out of mind

No longer having to think about how well the software works once it is in the hands of the customer – that's every developer's dream, right? The reality is that a few days later you get a call from someone telling you that something isn't working. In those cases, monitoring would have been a smart move. This is true for traditional projects and is actually even more important for DevOps with deliveries on an hourly basis. For real peace of mind, there are some tools that automatically monitor the system 24/7 and notify you immediately if there are any problems. In one instance, our monitoring system meant that we had a good three days to fix a file system before it was too late.

4. Banana software

DevOps is the perfect tool for delivering banana software. You can hand over 'unripe' software to the customer in line with their instructions and leave them to it. However, you don't have to deliver something really quickly with 'transparency' just because you can. As an engineer, I am responsible for product consistency, suitable architecture and choice of technology. And I always aim to give the customer good advice on these aspects. For me, the DevOps process begins with requirements engineering and ends with quality assurance.

5. DevOps will save the world

Do you really believe that DevOps is the solution to all problems? I stopped keeping count after the seventh groundbreaking method, if not before. It is reassuring, however, that pretty much every single aspect of DevOps can also be applied to all other IT projects and will work really well.