There are still several misconceptions surrounding DevOps that I hear or see on a daily basis (conversing with others, blog posts, podcasts, twitter, etc). There are the people within technology that still haven’t heard of DevOps at all. Several things that I often come across include are:
- “DevOps is a team.”
- “DevOps is a role.”
- “DevOps is a set of tools.”
So let’s try and clear some of this up. DevOps is all about implementing strategies and practices to foster collaboration in move work through your delivery pipeline in the most efficient manner possible.
“DevOps is a team”. I think Jez Humble did a pretty good job explaining this statement in his post ‘There’s No Such Thing as a “DevOps Team”’. For those that just want the summary Jez states that creating a team, calling it DevOps only creates another functional silo perpetuating the problem. He goes on to state, however, that supporting development in “packaging, deployment, and post-deployment” activities and if you want to call them a “DevOps team”, that’s okay. In this definition, it is more about the implementation and practices and less about creating yet another silo in your organization.
“DevOps is a role”. This goes hand in hand with the previous statements of DevOps as a team. There are a number of different skills and roles within the practice of DevOps, I don’t really see it as all-encompassing. There are always outliers to this depending on the organization. However, let’s assume we are talking about larger organizations. Several types of roles exist (focusing on the descriptions here is more important than the actual names):
- Release managers assist in the orchestration of a release. I see them as helping to develop the delivery pipeline.
- Automation engineers / architects work to analyze, design, and implement automated provisioning of environments, compute platforms, and other resources necessary for continuous deployments.
- Software developers / testers are responsible for taking user stories and turning them into code. They may be largely unchanged from an organization perspective however they will be critical for implementing and adhering to processes necessary to support continuous integration.
Several other roles exist as technology professionals to fill in any other gaps that arise as you are implementing DevOps practices and strategies. It is difficult to put names to roles such as this, but they really help to educate and facilitate whenever and wherever necessary.
“DevOps is a set of tools”. Tools can help facilitate and accelerate the strategies and practices; just purchasing or bringing in tools will not give you DevOps. Configuration management tools (chef, puppet, saltstack, ansible) can assist in things like automation, but you still need to reduce the bottlenecks in the processes between work moving in the pipeline. Automating a bad process, for instance, may not fix a bottleneck and it may, in fact, make it worse.
At the end of the day, DevOps is about people and process. In order to have DevOps, you need to create a healthy culture of trust and collaboration. Trust can be built through transparency and feedback loops. Give people information and trust and allow them to do the right thing. At the end of the day, everyone in your organization is on the same team. You are all striving for the same thing.