As part of GitLab’s mission to power the DevOps life cycle, it is laying out its ideal DevOps team model.
“The seamless collaboration between Development and IT operations is a beautiful thing. DevOps was designed to remove silos so that these teams could work together to build, test, and deploy software faster. But there’s a lot more to DevOps than just a philosophy and a catchy abbreviation – the structure component goes much deeper than that,” the company wrote in a blog post.
There are many things that can go wrong when trying to remove silos and get Dev and Ops to work together, according to GitLab. Factors that you need to consider when creating a DevOps team structure including existing silos, technical leadership, IT Operations, and knowledge gaps.
In GitLab’s model, the development teams are divided into stages such as a verify group and a create group because the company says these groups require their own autonomy. It also includes other functional DevOps groups to manage other parts of the product such as a SRE team for managing uptime and reliability.
“Keep in mind that good DevOps doesn’t mean that everybody does everybody’s job. Should developers do Ops? Not necessarily,” the company explained. “Many in the beginning thought the goal of DevOps was to combine the Dev, QA, and Ops departments into a single team: Have everyone do everything and – boom – instant innovation. These strategies, unsurprisingly, failed.”
The way teams build software can also help facilitate a successful DevOps Model, GitLab explained. For instance, microservices and containers enable a DevOps model that iterates quickly and offers more autonomy within certain groups. Successful DevOps companies structure themselves around multiple small teams that are responsible for a small part of the system. Companies with monolithic codebases simply can’t operate that way, according to GitLab.
While a team structure that facilities collaboration and visibility between Dev and Ops teams is important, the use of automation tools is also necessary for an effective DevOps life cycle, the company explained.
Automation in DevOps is about taking once manual processes and placing technology around them so they’re inherently repeatable, according to an article by David Linthicum, Chief Cloud Strategy Officer of Deloitte Consulting.
Automation tools for DevOps span many solutions such as Red Hat’s Ansible, which is an agentless configuration management as well as orchestration tool, Jenkins, which is a Java based continuous integration tool for faster delivery of applications, and Docker, which works on the concept of process level virtualization
Also essential to DevOps is treating Ops as a vital component to the cycle instead of just something that supports the initiatives for software development creates value. GitLab explained that “what Ops brings to the SDLC is reliability, performance, and stability. Devs can help the production environment by using their skills to automate processes, and true DevOps plays to the strengths of each.”
“Specialists can add value, but a lack of cohesion between the Dev and Ops processes leads to unnecessary dysfunction over time. It should not be we and them – it should be us. An organization that communicates like this will inevitably build a structure that operates in much the same way,” the company wrote.
While Willian Holz, research vice president for Gartner, largely agrees with GitLab’s DevOps analysis, he does note that there is no single answer that’s right for every organization. In a research presentation, he explained increasing speed is not the same as being Agile or doing DevOps. Similar to Agile, DevOps requires discipline, collaboration and early feedback. “Being DevOps requires everyone involved in [the] product development lifecycle to change how they currently work and to expand their knowledge and capabilities into new areas,” according to the research.
Matthew Skelton, head of consulting at Conflux, and Manuel Pais, co-founder of the DevOps Lisbon meetup group, recently released Team Topologies to provide nine types of team structures for successful DevOps, along with eight antipatterns. “Remember: There is no ‘right’ team topology, but several ‘bad’ topologies for any one organization,” they wrote. The antipatterns include Dev and Ops silos, team silos and DevOps-as-tools teams, where a team is “set up to work on the tooling required for deployment pipelines, configuration management, environment management,” the Team Topologies authors explained. The successful types of team structures include collaboration, fully shared responsibilities, and DevOps as an external service.
They went on to explain that scenarios in which the Dev and Ops teams are completely siloed or Ops are pushed away in favor of Dev are not conducive to DevOps. Also, it’s no better when companies form a new DevOps team that works independently of the two teams just so companies can then say they hopped on the DevOps bandwagon. This fails to address the underlying collaboration problem, according to the authors.
