DevOps - speed? Yes speed
If you look at the nineties of the last century, then they gave a large number of methodologies (if anyone would prefer frameworks) of 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 appearance of the Agile Manifesto. We do not need quality, we do not need support for changes, give us quickly what you can see, and we will decide what to do next. At present, it seems that social factors have exhausted themselves and are not enough to further increase their speed. The approach, which includes not only “pro people”, but also “pro technologies”, is called DevOps. Let's look at what else we can gain in utility delivery speed.
If you look at the Agile-manifesto, at 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 also belong to flexible methodologies, there are also engineering things (who, by the way, can immediately recall what is there from engineering in 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 systems being developed, it turns out that not everything is so rosy. Even smart people need engineering practices to continue to produce acceptable results as soon as possible. It is clear that everything has been invented long enough, to take the same “ Joel 's test: 12 steps to a better code, ” and find that it is not necessary to invent anything. But for some reason you can still find organizations that do not use build servers. And within the framework of the struggle against this bias towards social and 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 under Agile-Manivest signed in February 2001 in Utah USA, there are specific last names) What DevOps is still controversial and misunderstanding. No, there is an article in Wikipedia , conferences are held, but there is no formal description of what is included in DevOps, with which the entire community, or at least most of the 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: autonomous, cross-functional teams; trust culture; joint meetings. But with all this, the main focus 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 image, then these are the options for improving teams, processes, products in the organization.
Take for example ChatOps. This practice implies that not only correspondence is collected in the team chat, but also information about running builds, changes made to the code and requirements, errors that have occurred in production. Those. the developer no longer needs to keep track of a bunch of places (email, BuildAgent pop-up messages, team chat). Everything is going in one place. But a bot can be present in the chat, which by the developer’s team can: initiate deployments to the test or even the combat environment, give information about the progress of the iteration, produce 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 a code. The problem regularly arises that the developer has a “light bulb on,” and in the test or even in the product environment there is no. The ability to store information about the infrastructure in a high-level language, the ability to deploy absolutely identical environments on request, the ability to change 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 it reduces the problems in reconfiguring the product environment and laying out releases.
Colleagues, share in the comments, what do 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 there is a desire to talk about it not only on Habré, then you can register as a speaker at DevOpsDays and discuss your approach also in personal contact with people who are interested in all this. The conference will be held on March 11 of this year, and the official sale of tickets has already begun. You can see the cost of tickets here . And here is a small gift from me personally. The first 5 people who write to me in BOS or in the comments will receive a promotional code for a discount for buying tickets.
If you look at the Agile-manifesto, at 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 also belong to flexible methodologies, there are also engineering things (who, by the way, can immediately recall what is there from engineering in 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 systems being developed, it turns out that not everything is so rosy. Even smart people need engineering practices to continue to produce acceptable results as soon as possible. It is clear that everything has been invented long enough, to take the same “ Joel 's test: 12 steps to a better code, ” and find that it is not necessary to invent anything. But for some reason you can still find organizations that do not use build servers. And within the framework of the struggle against this bias towards social and 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 under Agile-Manivest signed in February 2001 in Utah USA, there are specific last names) What DevOps is still controversial and misunderstanding. No, there is an article in Wikipedia , conferences are held, but there is no formal description of what is included in DevOps, with which the entire community, or at least most of the 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: autonomous, cross-functional teams; trust culture; joint meetings. But with all this, the main focus 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 image, then these are the options for improving teams, processes, products in the organization.
Take for example ChatOps. This practice implies that not only correspondence is collected in the team chat, but also information about running builds, changes made to the code and requirements, errors that have occurred in production. Those. the developer no longer needs to keep track of a bunch of places (email, BuildAgent pop-up messages, team chat). Everything is going in one place. But a bot can be present in the chat, which by the developer’s team can: initiate deployments to the test or even the combat environment, give information about the progress of the iteration, produce 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 a code. The problem regularly arises that the developer has a “light bulb on,” and in the test or even in the product environment there is no. The ability to store information about the infrastructure in a high-level language, the ability to deploy absolutely identical environments on request, the ability to change 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 it reduces the problems in reconfiguring the product environment and laying out releases.
Colleagues, share in the comments, what do 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 there is a desire to talk about it not only on Habré, then you can register as a speaker at DevOpsDays and discuss your approach also in personal contact with people who are interested in all this. The conference will be held on March 11 of this year, and the official sale of tickets has already begun. You can see the cost of tickets here . And here is a small gift from me personally. The first 5 people who write to me in BOS or in the comments will receive a promotional code for a discount for buying tickets.
Source: https://habr.com/ru/post/318216/
All Articles