8 key DevOps roles and responsibilities for team success
More than most IT initiatives, DevOps is built around people. Involve the right professionals, and get those people primed to work in concerted ways.
Processes and tools matter, but it's people that ultimately determine whether a business can successfully transform itself into a DevOps organization. Regardless of how you organize DevOps roles -- whether you form a dedicated team of specialists or you weave DevOps skills into existing job responsibilities -- make sure that your organization has the following domains of expertise in place to speed you on the way to DevOps success.
1. Software developers
Code is at the core of DevOps processes, and the people who write code are at the core of a DevOps organization. What's complicated is that not all developers are equally suited to DevOps practices.
Ideally, your DevOps strategy is powered by developers who have two main traits. First, they are flexible in their development tool set. They know a variety of programming languages and are familiar with different app development strategies, such as Agile methodology. This flexibility helps your team to adjust and improve on a continuous basis.
Second, developers who support DevOps must have at least a working understanding of what happens to code after it is deployed. They need not be system administration experts, but they should know how to manage production environments and recognize the complications that IT teams face as they manage code after its deployment. This knowledge is required to break down the silo structure that separates development from IT operations.
2. IT engineers
As the ops in DevOps, IT engineers are essential to the process. DevOps requires sys admins who are competent in IT operations, but ideally, they are more than that. They understand the software development process workflows and can collaborate with developers to reduce the friction that occurs when developers hand off code for deployment.
Look for IT engineers who know how to code. Ideally, they have experience writing not just simple system administration scripts, but application code as well.
3. Systems architects
DevOps requires no specific type of architecture. Success isn't determined by whether you host workloads on premises or in the cloud, and it won't necessarily matter which OSes you use. Still, a team that wants to design a DevOps-friendly architecture should keep certain goals in mind.
Because automation is foundational to DevOps, choose systems that can be provisioned automatically. You want to achieve architectural flexibility so that an architecture doesn't constrain the DevOps team's ability to improve practices on a continual basis. Build resiliency, redundancy and automated failover into system architectures; these features mitigate the disruptions caused by the inevitable failures that occur during CI/CD cycles. Knowing the ins and outs of configuration management is a plus as well.
Systems architects who understand these requirements play an important role in a DevOps organization.
4. QA engineers
Although developers have become more directly involved in software testing in recent years, quality assurance (QA) engineers still play a valuable DevOps role.
QA engineers focus specifically on how to define quality standards for performance, reliability and other factors before software is pushed into production. It is their responsibility to design and run tests that assess whether each new release meets those requirements as it flows through the CI/CD pipeline.
In some ways, the work performed by QA engineers might seem at odds with other DevOps goals. Inefficient software testing introduces delays to the CI/CD process, which hampers the fundamental DevOps goal of CD. To support DevOps most effectively, QA engineers should understand how to uphold software quality and create minimal disruptions for other DevOps processes. There are a variety of ways to do this.
One technique is to embrace shift-right testing for noncritical features. This enables some tests to be performed after code is deployed, which reduces the number of tests that run pre-deployment and gets new releases into production faster. This strategy would be inappropriate for critical features -- those should be tested before deployment -- but it works well for testing smaller application components that will not lead to serious problems if they turn out to fail a post-deployment test.
Good QA engineers can also write efficient tests that run quickly and automatically. They should know the ins and outs of test automation frameworks, such as Selenium, and be skilled in how to write tests that cover a lot of ground but that don't require a long time to run. They must also know how to interpret test results quickly and communicate to developers how to fix whatever caused the failure. Effective communication in this regard between developers and QA engineers is essential to maintain the CI/CD pipeline flow even when a test fails.
3 approaches to structure your DevOps team
Once you've identified the roles that enable DevOps, you need to combine or coordinate them into an actual DevOps team. This can be a major challenge -- the DevOps philosophy makes no specific recommendations about how to structure DevOps teams or integrate DevOps into existing teams. Most businesses choose one of the following approaches to structuring DevOps personnel:
- Replace dev and ops with DevOps. Eliminate separate development and IT operations departments entirely, and replace them with a dedicated DevOps team. The new team may include stakeholders from other domains, such as QA, or you can manage roles other than dev and ops as their own teams. This approach works well if you want to structure your entire organization around DevOps and never look back, but it requires major organizational overhaul. You also have to convince all of your developers and IT engineers to embrace a new identity as DevOps engineers, which may be culturally jarring.
- Run DevOps alongside dev and ops. Keep your existing development and IT operations teams intact, with a separate DevOps team that operates alongside and coordinates activities with them. With this approach, developers and engineers retain their identities and independence as you integrate DevOps into the overall organization. However, you'll have to build a new DevOps team from scratch and convince other teams to work with it.
- Embed DevOps engineers into other teams. This hybrid approach embeds DevOps specialists into your existing dev and ops departments. It requires minimal organizational or culture change -- but sprinkling DevOps engineers across existing teams may not initiate enough change to embrace DevOps in full. You may end up with an organization that does "DevOps lite" instead of total DevOps transformation.
5. User experience engineers
UX engineer is not necessarily a DevOps role that immediately comes to mind. An expert who can ensure that software pleases end users, though, adds value to your DevOps process.
This is especially important because it's easy to fixate on the technical aspects of DevOps, such as how often a team releases software or how many tests it runs per release cycle. The goal should not be to merely deliver good software that meets users' needs -- you want software that satisfies users. UX engineers can help the rest of the DevOps team maintain that focus.
6. Security engineers
Security engineers -- specifically, ones who understand DevSecOps and can put its tenets into practice -- are another core part of a DevOps organization. They bring a specific and important set of skills to the process.
To enact DevSecOps, an organization must set up tools and processes that enable developers, security engineers and IT professionals to participate in security operations. All three groups of stakeholders should have visibility into security problems so that they can counter those problems in a collaborative manner. Likewise, developers should be prepared to communicate with security engineers early and often to help design code that is secure from the start. IT engineers should work closely with the security team to ensure that their deployment and management processes follow best practices with regard to application and infrastructure security.
7. DevOps evangelists
Not everyone will understand what DevOps means or why the organization should invest in the new tools, processes and people necessary to support it. A DevOps evangelist can help smooth over objections to the technology and organizational changes that DevOps adoption demands and can also provide general guidance on what it takes to build a DevOps-centric culture.
In most situations, this work is more of a DevOps role than a job description. Select a few team members who fill other DevOps roles and ask them to serve as DevOps champions for the organization. The best ones will step up eagerly.
8. Nontechnical DevOps roles
To get the most out of DevOps, a business should engage other teams within the organization, even those whose members aren't in technical roles. Sales and marketing teams, for example, should understand how DevOps' benefits can reinforce sales and marketing goals. Legal teams may need to plug in to DevOps processes to ensure that software remains compliant even as it is released continuously.
This is not to say that every employee in your organization needs to know the ins and outs of DevOps and software requirements. Nonetheless, it is worth building strategic connections between the core DevOps team and colleagues in nontechnical roles.
