In the simplest terms, DevOps is a culture that brings together developers and operations/support staff. This can mean cooperating, bridging the gap, or even full integration. That’s in contrast to traditional IT set-ups that keep the two completely separate. Supporters of the DevOps approach argue that it can cut costs, reduce risks, and make an IT operation more responsive.
Some of the more heated debates over DevOps stem from differing definitions of the term and associated concepts. You’ll occasionally see “DevOps” used to refer to a specific development operations team or department that exists alongside a traditional IT department. It’s up to every company to define their own structure and departments, but this situation isn’t the one that DevOps supporters are talking about.
DevOps as a concept is a counter to the traditional IT support philosophy. That’s where an organization has a dedicated development team responsible for producing software, systems, and solutions. A separate IT operations team is responsible for keeping things running: managing networks, fixing bugs, maintaining hardware, and dealing with any software problems.
In contrast, DevOps brings these two together. How this works administratively isn’t as important as the principle that development and operations work closely together for best results.
Most commonly, traditional IT setups involve department or teams based on a particular activity, be that software development, testing, implementation, support or maintenance.
DevOps allows for a merged department that brings together the people who possess these various skills; the communed team is now united by a specific project such as developing an application.
The traditional set-up is more likely to have a new application go through a lengthy development process, passing through different departments in sequence. It’s designed to finish with a “complete” release that’s as near to perfect as possible.
DevOps is more suited to a faster, more agile development process with more frequent releases. The logic is that although bug fixes or feature improvements may be needed more often, DevOps teams can make these changes more quickly. Indeed, there’s more scope for holding back a new feature to test it fully, without delaying the entire project.
The way departments think and operate under different set-ups is something of a subjective point. DevOps supporters criticize traditional IT operations as being too driven by a desire to minimize the risk of failure and too defined by a culture where individual staff or teams concentrate solely on achieving their specific siloed tasks.
In contrast, the argument goes that the DevOps approach accepts that failures will happen and that it’s best if they happen early and on a smaller scale so the damage is limited and the fixes are more viable. DevOps can also mean people performing different tasks will pay more attention to the overall success of a project rather than only caring about their specific responsibilities.