Five Anti-Patterns in DevOps

My motivation to write about anti-patterns and DevOps was to create a compilation with the most absurd and common scenarios ever seen in my career. Before I mean that I did work on all of them and with that, the purpose of this article is to share experiences and give a small collaboration to the growth of our community.

DevOps Team

Traditionally, the Dev team has worked in a new software release. After done, the new code is tested, packaged, and delivered for the Operation team that was responsible by deploy in a production environment. This process had many problems: the dev team does not have the information about the environments neither the operations team had knowledge about the application.

To solve this problem some companies add more one element to the process: the DevOps team. In fact, the problem just increased. Create a DevOps team is like to create more complexity and become communication more difficult. With that, it was added a strange element to the process.

DevOps is a Culture. DevOps is not a team.

Manual Deploy

It is common to have a document with steps to deploy the applications. The dev writes the steps to build and deploy the application. An operator read these bread paper and do the procedural process.

In this scenario is possible to have a Continuous Integration server but there are not automatic triggers. The input of the configurations and secrets are manual when they are not written in the code.

The result of these procedures is afraid and it has many faults and errors.

Update Environment

We assume that in any existing environment there are applications in run status and even if it doesn’t exist to add or remove packages or settings in an environment makes it difficult to manage.

It is easier or less difficult to recreate the environment. Do this using code. There are many tools to help with this work: Terraform, Vagrant, Ansible, Puppet, Packer, and many others.

Big Bang Deploy

We call the Big Bang Deploy or Deploy’s Day the action of the gather a large number of changes to be deployed just once. I’ve seen companies take days in only one deploy. The chance of failure is very big. This deploy, in general, is a big monolithic and rollback undo all changes.

Break a deploy into small deploys. Make small batches of deploy. Deliver value continuously.

Arbitrary Use of Tools

Each software tool is designed to solve a specific problem, not all. For example, Terraform is a tool to build infrastructure, Ansible is a configuration management tool and Maven is a build automation tool. Why use Maven as package management or Ansible to build infrastructure? It is better to use tools that already exist and work well.

Avoid complexity. Make it simple.

Conclusion

There are many initiatives made in isolation that is done with the goal of implementing DevOps but as we have seen a collaborative environment is not built just buying one suite software tools, creating a specific team, or any other isolated initiatives.

The DevOps is a Culture. Instead of creating a new team foster good practices across the company, share the knowledge, create initiatives like meetups, webinars, dojos, and groups. Automate everything possible.

Do everything as a code. Codes can be versioned. If an environment has a problem you can just destroy and build again. Analyze code quality. Test and monitor everything. All steps of the process need to give feedback.

There is no ready recipe for creating a DevOps Culture but you can start with the small initiatives described in this article.