When industrial software development began, each developer was a business analyst, developer, architect, layout designer, tester, DevOps and 24/7 support in one person. What kind of flaws did this system have? Sometimes it wasn’t understandable product for user. It was hard to imagine what was in the head of one or another individual. And one more minus - all ’’sacred’’ knowledge is concentrated in one bright head, which could get sick, go to competitors, or just go to rest on Bali.
However, it had advantages as well. The engineer immediately thought about ‘full life cycle’ of his product. There was no high expectations in all-powerful admin, who would come and decide everything for you. You had to be responsible for all of the mistakes by yourself.
Then happened the thing that always happens during the transition to mass production — sectoral separation. There are admins, who managed the application infrastructure, and the developers who, in fact, developed this application. I’m not talking about layout designers, quality engineers, business analysts and others, without diminishing their merit in the development process. The situation was also influenced by the specifics of the business - outsourcing became dominant. Many companies delivered the code as raw material, not thinking about the result, how and where it will be placed. It could go on forever, but the process started to falter.
In this way appeared a culture of DevOps. Yes, yes, it is culture. Why not a role? - you ask. Because DevOps practices, which will be discussed below, should be implemented at the company level, not at the department or group level. People in the company should be aware of the software development and using infrastructure subtleties. DevOps culture, in my opinion, is the next step in the evolution of the FullStack paradigm, in which teams do not individual parts of the application but solve the whole problem. It is quite difficult for one person to do all these tasks, and the process must be carried out in the whole company or group.
And why is it so important to try the devOps in your organization? This kind of work culture has its huge benefits:
- increase organizational effectiveness
- quick entry to the market
- quality improvement (increased availability, fewer failures, and so on)
In case of successful implementation of DevOps, companies can in the future rely on: automation (reducing the risk of human error), accelerate and simplify development and release processes, getting quick feedback from users (metrics, monitoring), and, of course, profit :)
DevOps has evolved big time since many of us thought it was just a buzzword. Now we know that is a myth. DevOps has become a main focus and has been shaping the world of software for the last few years. Experts say that DevOps is going to be the mainstream and its popularity is going to reach its peak in 2019.
Now let's talk about the practices of DevOps. They are pretty well described in the book "DevSecOps The Road to Faster, Better and Stronger Software."
This is not all practices that explain the culture of DevOps. However, as we can see, they are a set of methods and tools, using which you can solve the problem of fast and high-quality software delivery to the end user, as well as get feedback from them as soon as possible.
In conclusion, DevOps culture is something that should be cultivated at the company level. Teams should not only be able to implement their features, but also organize the process of testing, delivery feedback from the end user. DevOps practices are designed to make life easier for everyone - developers, operators, businesses, because they are like thin threads between seemingly incompatible industries.