When the application does not work, the least you want to hear from colleagues is the phrase “problem on your side”. As a result, users suffer – and they don’t care which part of the team is responsible for the breakage. The DevOps culture came into being just to unite development and support and unite them around a common responsibility for the end product.
What is DevOps?
The question is good and controversial: it has not been finally agreed in the world. DevOps unites technologies, processes and culture of interaction within a team. This union is aimed at continuous delivery of values to end users.
Developers write code, testers check it, and administrators install the final product on the production environment. For a long time, these parts of the team were somewhat fragmented, and then the idea to combine them in a common process appeared. This is how DevOps practices came into being.
The day has come when developers and system engineers were interested in each other’s work. The barrier between production and support began to blur. So appeared DevOps, which includes practices, culture and order of interaction in the team.
What is the essence of DevOps culture?
That the responsibility for the final result lies with each of the team members. The most interesting and difficult thing in DevOps philosophy is to understand that a particular person is not just responsible for his or her stage of work, but is responsible for how the whole product will work. The problem is not on someone’s side – it is common and each team member helps to solve it.
The most important point of DevOps culture is to solve the problem, not just to apply DevOps practices. Moreover, these practices are implemented not “on someone’s side” but in the whole product. The project does not need a DevOps-engineer by itself – it needs to solve the problem, and the role of a DevOps-engineer can be divided into several team members with different specializations.
What are the DevOps practices?
DevOps-practices cover all stages of the software life cycle. The ideal case is when we start using devops services right at project initiation. Together with architects, we plan what kind of architectural landscape the application will have, where it will be located and how it will scale, we choose the platform. Now the microservice architecture is in fashion – for it, we choose an orchestration system: you need to be able to manage each element of the application separately and update it independently of others. Another practice is “infrastructure as code”. This is the approach where the project infrastructure is created and managed with the help of code rather than through direct interaction with servers.
Next, we move on to the development stage. One of the biggest practices here is CI/CD building: you need to help developers integrate changes into the product quickly, in small portions, more often and painlessly. CI/CD covers both code validation and wizard filling in the code base, and deployment of the application on test and productive environments.
During the CI/CD stages, the code goes through quality gates. They make sure that the code that came out of the developer workstation meets the specified quality criteria. Here we add unit and UI testing. For a quick, painless and focused deployment of the product, you can choose the appropriate type of deployment.
DevOps practitioners have a place at the support stage of the finished product. They are used for monitoring, feedback, security, change implementation. DevOps looks at all these tasks in terms of continuous improvement. We minimize repetitive operations and automate them. This also includes migrations, application extensions, performance support.
