Let’s start with the emergence story
Development Operations emerged as another step to streamline collaboration in small teams to increase the speed of product production, as an expected consequence. The idea was to strengthen the development team with knowledge of procedures and approaches in managing the product environment. In other words, the developer needs to understand and know how his product works under certain conditions, needs to understand how to deplocate his product, what characteristics of the environment to tweak to improve performance.
Thus, for some time, developers with DevOps approach appeared, devops as a service. DevOps developers wrote build and packaging scripts to simplify their activities and the performance of the productive environment. However, the complexity of solution architecture and mutual influence of infrastructure components over time began to degrade the performance of environments, with each iteration requiring deeper and deeper understanding of certain components, reducing the developer’s own productivity due to the additional cost of understanding components and tuning systems for a particular task.
The developer’s own cost grew, the cost of the product along with it, the requirements to new developers in the team DataArt rose sharply, because they also needed to cover the duties of the “star” of the development and, naturally, the “stars” were becoming less and less available. It is also worth noting that, in my experience, few developers were interested in the specifics of how the operating system kernel processes packets, the rules of packet routing, the security aspects of the host. The logical step was to bring in an administrator who is familiar with these things and put this type of responsibility on him, which, thanks to his experience, allowed to achieve the same results at a lower cost compared to the cost of “star” development.
Such admins were placed in a team, and his main task was to manage the test and productive environments, on the rules of a particular team, with the resources allocated specifically to that team. This is how DevOps came to be perceived by the majority.DevOps is the Future. Many businesses are aware and are either planning or implementing this development approach. It is your responsibility to develop your abilities to meet the requirements. You can get started by enrolling in Post Graduate Program in DevOps.
DevOps is (in theory) a person who understands all processes of the development cycle – development, testing, understands product architecture, can assess security risks, is familiar with automation approaches and tools, at least at a high level, and also understands pre- and post-release support of the product. Capable of being an advocate for both Operations and Development, allowing for a beneficial collaboration between the two pillars. An understanding of team planning processes and managing customer expectations.
In order to perform this type of work and responsibilities, this person must have the means to manage not only the development and testing processes, but also the product infrastructure and resource planning. DevOps in this sense cannot be in IT, R&D or even PMO, it must have influence in all these areas – the company’s Technical Director.
Lack of funds and ability to influence at least one of these three areas of activity will shift the weight of issues to where these changes are easier to apply, such as applying technical restrictions on releases due to “dirty” code according to static analyzer systems. That is, when PMO set a deadline for release of functionality, R&D cannot provide a quality result within these deadlines and releases it as they can, leaving refactoring for later, DevOps related to IT technically blocks the release. Lack of authority to change the situation, in the case of responsible employees, leads to hyper-responsibility for what they cannot influence, especially if these employees understand and see errors and how to fix them – “Happiness in ignorance”, and as a consequence, burnout and loss of these employees.
AIMS AND OBJECTIVES OF DEVOPS
As devops processes cover the entire software delivery cycle, there are several main objectives of this approach:
- reducing the time to market;
- reducing the failure rate of new releases;
- a reduction in the time it takes to implement patches;
- reducing the amount of time to recover from new release failures or other failures of the current system.
These goals are achieved through the following objectives:
- aligning software development and delivery processes with operations;
- automation of development, testing and deployment processes;
- continuous application quality testing;
- management of IT infrastructure as code;
- change management;
- continuous monitoring of application performance and infrastructure health.
DevOps thus focuses on the predictability, efficiency, security and maintainability of operational processes, as well as the regular delivery of a reliably working product, its updates and maintenance.