DevOps - speed? Yes speed
If you look at the nineties of the last century, they gave a large number of methodologies (if anyone likes frameworks) for software development: FDD (Feature driven development), Scrum, Rup, XP. But the most popular were not technical approaches, but people-oriented. In 2001, this all led to the emergence of an Agile manifest. We don’t need quality, we don’t need support for change, give us quickly what we can look at, and we will decide what to do next. Currently, one gets the feeling that social factors have exhausted themselves and that they are no longer enough to further increase the speed. The approach, which includes not only “about people”, but also “about technologies”, is called DevOps. Let's look at what else we can win in the speed of delivery of utility.
If you look at the Agile manifesto, what is included in Scrum, Kanban, then everything is about people. About interaction within the team, about interaction with the customer, about organizational processes. No, in FDD and XP, which are also referred to as flexible methodologies, there are also engineering things (who, by the way, can immediately recall what is from engineering to FDD?). And it works. Gathering smart people in one place, giving them organizational templates, helping to organize interaction with the customer, you can get an acceptable, and often excellent result.
Only now, with the increasing complexity of the developed systems, it turns out that not everything is so rosy. Even smart people need engineering practices to continue to produce acceptable results in the shortest possible time. It is clear that everything has already been invented for a long time, take the same "Joel Test: 12 Steps to Better Code, ”and discover that nothing needs to be invented. But for some reason, you can still find organizations that do not use build servers. And as part of the fight against this bias towards socio-organizational issues, DevOps appeared. Unlike other methodologies that have ancestors, and often entire institutes involved in their development (PMBOK develops PMI, ITIL develops AXELOS, and there are specific surnames under the Agile manifest, signed in February 2001 in Utah, USA), what DevOps is still causing controversy and misunderstanding. No, there is a wikipedia article , conferences are held, but there is no formal description of what is included in DevOps, with which the entire community, or at least the majority of developers, agreed.
Gartner tried to systematize the approaches used in DevOps:
* Gartner image source .
As you can see from the picture, DevOps includes what Agile stands for: stand-alone, cross-functional teams; culture of trust; joint rallies. But with all this, the main emphasis is on technology. Can you deploy your application in one click? Do you use continuous integration and testing? If there are no answers to these and many other questions that can be asked in blocks from the picture, then these are the options for improving teams, processes, products in the organization.
Take ChatOps as an example. This practice implies that the team chat collects not only correspondence, but also information about running builds, changes made to the code and requirements, errors that have occurred in the product. Those. the developer no longer needs to track a bunch of places (mail, BuildAgent pop-up messages, team chat). Everything is going in one place. But in the chat there may be a bot that, on the developer's command, can: initiate deployments to a test or even a combat environment, give information about the progress of the iteration, give a list of critical errors, etc. Most modern messengers have an API and implementing such a bot is not a big problem.
Or infrastructure as code. Regularly there is a problem that the developer has a “light on”, but not in the test or even in the product environment. The ability to store information about the infrastructure in a high-level language, the ability to deploy completely identical environments upon request, the ability to modify and test environments, the ability to have versioned environments. All this allows you to significantly save the time of developers, testers, operators. And how significantly this reduces problems during reconfiguration of the product environment and the layout of releases.
Colleagues, share in the comments what you use from the above practices to save time? Or maybe you have something not included in the Gartner scheme, but really very useful? Yes, if you want to talk about this not only on Habré, then you can register as a speaker on DevOpsDays and discuss your approach also in personal communication with people who are very interested in this. The conference will be held March 11 this year, and the official sale of tickets has already begun. See ticket prices here . And here is a small gift from me personally. The first 5 people who write to me in the PM or in the comments will receive a discount promotional code for buying tickets.
If you look at the Agile manifesto, what is included in Scrum, Kanban, then everything is about people. About interaction within the team, about interaction with the customer, about organizational processes. No, in FDD and XP, which are also referred to as flexible methodologies, there are also engineering things (who, by the way, can immediately recall what is from engineering to FDD?). And it works. Gathering smart people in one place, giving them organizational templates, helping to organize interaction with the customer, you can get an acceptable, and often excellent result.
Only now, with the increasing complexity of the developed systems, it turns out that not everything is so rosy. Even smart people need engineering practices to continue to produce acceptable results in the shortest possible time. It is clear that everything has already been invented for a long time, take the same "Joel Test: 12 Steps to Better Code, ”and discover that nothing needs to be invented. But for some reason, you can still find organizations that do not use build servers. And as part of the fight against this bias towards socio-organizational issues, DevOps appeared. Unlike other methodologies that have ancestors, and often entire institutes involved in their development (PMBOK develops PMI, ITIL develops AXELOS, and there are specific surnames under the Agile manifest, signed in February 2001 in Utah, USA), what DevOps is still causing controversy and misunderstanding. No, there is a wikipedia article , conferences are held, but there is no formal description of what is included in DevOps, with which the entire community, or at least the majority of developers, agreed.
Gartner tried to systematize the approaches used in DevOps:
* Gartner image source .
As you can see from the picture, DevOps includes what Agile stands for: stand-alone, cross-functional teams; culture of trust; joint rallies. But with all this, the main emphasis is on technology. Can you deploy your application in one click? Do you use continuous integration and testing? If there are no answers to these and many other questions that can be asked in blocks from the picture, then these are the options for improving teams, processes, products in the organization.
Take ChatOps as an example. This practice implies that the team chat collects not only correspondence, but also information about running builds, changes made to the code and requirements, errors that have occurred in the product. Those. the developer no longer needs to track a bunch of places (mail, BuildAgent pop-up messages, team chat). Everything is going in one place. But in the chat there may be a bot that, on the developer's command, can: initiate deployments to a test or even a combat environment, give information about the progress of the iteration, give a list of critical errors, etc. Most modern messengers have an API and implementing such a bot is not a big problem.
Or infrastructure as code. Regularly there is a problem that the developer has a “light on”, but not in the test or even in the product environment. The ability to store information about the infrastructure in a high-level language, the ability to deploy completely identical environments upon request, the ability to modify and test environments, the ability to have versioned environments. All this allows you to significantly save the time of developers, testers, operators. And how significantly this reduces problems during reconfiguration of the product environment and the layout of releases.
Colleagues, share in the comments what you use from the above practices to save time? Or maybe you have something not included in the Gartner scheme, but really very useful? Yes, if you want to talk about this not only on Habré, then you can register as a speaker on DevOpsDays and discuss your approach also in personal communication with people who are very interested in this. The conference will be held March 11 this year, and the official sale of tickets has already begun. See ticket prices here . And here is a small gift from me personally. The first 5 people who write to me in the PM or in the comments will receive a discount promotional code for buying tickets.