When DevOps becomes DevOops

While the common direction for most companies is to embrace DevOps, there are some pitfalls if not addressed.

With great power come great responsibility. - Uncle Ben.

This isn't just a Spiderman quote, it's very important to remember that changes can and do break things and with automation and continues deployment the chances to break everything is higher. Let's get one thing clear no process or person is perfect and therefore there is always a chance to break a production system so DevOps doesn't make that any more or less likely. 

Now here are a few common issues those that are new to DevOps are running into:

Taking out the code you don't understand.

Skipping long testing to make releases schedules.

Not having tests that cover enough possible issues.

Committing to master without testing.

Leaving security key, passwords and certs in the code.

Not have a rollback plan.

Not knowing why it failed before trying to fix it.

Mistaking data for code and result data loss.

Not understanding merge vs rebase and deploying broken code.

Not commenting code and having no documentation.

Coding for coding sake and not having a clear goal to work toward.

While this is not a complete list it's long enough for you to get the idea, for example, you see that testing comes up again and again in the list and automated testing and testing plans are the rock that DevOps is built on. If you can't test quickly then you can't deploy quickly without large risks. And this defeats the point of DevOps.

That said I don't want to sound overly negative here, DevOps is a great way to move forward and replace the slow iterations of services with faster-paced deployments, and the key to making it work is to start with tools that enable changes to be done faster. Just be sure that you take into account the points above and protect against DevOops.