"DevOps (development and operations) is an enterprise software development phrase used to mean a type of agile relationship between Development and IT Operations. The goal of DevOps is to change and improve the relationship by advocating better communication and collaboration between the two business units."
Development, in the context of DevOps, refers to the Development Team, or Teams within business or enterprise. Normally, Development Teams will be practising some form of Agile methodology such as scrum. They will be using backlog tools such as kanban and task boards. They will engage in automated testing practices, Test Driven Development. Hopefully, the teams will have a strong culture of pair programming and code reviews.
The Development Team's ultimate goal is to produce reliable software that meets the wants and needs of the software's users. To this end, the Development Team considers Configuration Management, Build, Deployment and Release practices of said software, and potentially the environment to support the software.
IT Operations manage and are responsible for the businesses IT systems. This includes managing of infrastructure and resources of IT as well as providing support to the business. IT Operations ensures that systems are stable. available and reliable. In many organisations, Request Management, Change Management, Incident Management and Problem Management will all be handled by IT Operations to some extent. Given all this activity, IT Operations departments tend to be busy and complex places.
IT Operations can usually be broken down into sub-teams. For example, a typical set of teams could be VM (virtual machine) Management, Network Management, Database Admins, IS BaU (Business as Usual).
Traditionally, software development has gone something like this:
Sounds simple enough - where is the issue?
There are a number of "contentions" with this. Firstly, the lack of integration between IT Operations and Development Teams. This "throw it over the wall" approach means that IT Operations are often burdened with releasing software they do not necessarily understand. The Development Team has to provide a perfect runbook in order for the release to go smoothly. Bugs and issues raised are thrown back over the wall to the Development Team, but without the context of the live environment, developers may struggle to debug the issues. With the introduction of continuous delivery and deployment practices, this cycle must be performed at pace to keep up with shorter release cycles. So on and so forth. Ultimately, IT Operations and Development Teams sit as two separate silos in most businesses not practising DevOps.
DevOps is different for each company. It really depends on the frameworks and cultures of a company. Ultimately it should be about bringing two sets of people from different worlds together to support each other in achieving a common goal. That is, a friction free, reliable, sustainable and repeatable process to develop, configure, build, deploy and release software and its supporting environment.
In one company, DevOps may mean the freedom for Developers to self service infrastructure, and Ops to provide consultancy only. In another, it may be the integration of IT Operations into cross-functional teams - making IT Operations part of the Development Team. In yet another, it may still mean passing deployment packages to IT Operations. What is important in every case is the culture. That the boundaries for each group are understood, and worked with rather than being seen as a blocker. If developers know they have to provide a deployment package to IT Operations, they should make it as easy as possible for the Ops guys to deploy. Why not provide it as a script that Ops can just run. If the Ops guys know they will be sending bug reports to the dev guys, why not provide all available environment monitoring data up front with the bug report.