How is the transition from "classic" to DevOPS going?

Question

System administration

Smack everyone in this chat (c)
Colleagues, I have a question about the transition of the methodology of our office to the notorious DevOps
introductory:
There is a software office, development is carried out according to the Agile methodology. There are all necessary groups (QA, Release Management, ArchTeam, project managers, product managers, etc.).
Regular releases, automated, update deployment is on schedule, weekly release briefings (what can be rolled out, what can be rolled out early, etc.).
The engineering group (infrastructure) is responsible for maintaining hardware, networks, OS, DBMS, application servers and other internals. We are also responsible for the automated deployment of the release.
What can change when moving from our principle of work to the notorious DevOps? I would like to hear from those who switched to DevOps (and took off).
Also karma to those who will advise suitable materials (both in Russian and in English) and literature (except for the Phoenix project).

Answer 1

There are no suitable materials. More precisely, they are only suitable for experienced DevOps. Because it is a culture of approach, not a toolkit.
The transition to DevOps is done in three stages:
1) First, everything is fully automated. Questions about code delivery are unlikely to arise - Jenkins and Maven are known even to children. Well, they don't have to. Each language has its own tools. gradle, grunt, waf... But everything needs to be automated, including SQL deployment (LiquidBase, dbMaintain, sqitch, etc.). This part is covered very well on the internet.
2) Then all bottlenecks in the work of admins and programmers are removed. For example, a Green / Blue deployment is being implemented. At deployment points of own software, provisioning tools (puppet/ansible/chef) are replaced with deployment tools (uDeploy for example). Monitoring and logging is established. All this also has its own tools (Sensu for example).
3) Work with people begins - involving programmers in responsibility for the result on the Ops side and involving system administrators (operations) in the result on the Dev side (fitting for FHS and all that). The key point is that people will have to understand that their responsibility comes echoing from where they did not touch it with their own hands (for this, new environments are even automatically created by all sorts of dockers and vagrants). I committed the crooked code in the IDE, did not take into account the dependency in the properties, corrected the configs for not all environments - you will be responsible for static code analysis and for failed integration tests and for unsuccessful deployment. The same is true in the opposite direction. Then people will begin to act according to the standards and the desired result will come.
Well, of course, you need to find a strong release engineer. Because DevOps is not "build and go". Someone has to watch all the time for new organizational problems and so that the trunk does not get to UAT, for example, and the same tagged code that was smoke tested on DEV goes to SIT, and not updated by a couple of harmful commits that ran during the smoke.
First, say what the final task sounds like and what is already there and what is not. Maybe I can give you more details.