DevOps - a new level of interaction between development and operation teams
Creating applications is a complex process that includes several elements: writing code, testing, troubleshooting, checking and, finally, commissioning. It can be said that three independent “states” are involved in this process - developers, testers and employees of the operations department. Each of these groups performs its own tasks and uses different criteria for evaluating the effectiveness of its work. For developers, this is the speed of writing and the number of functions implemented in the program code, for testers, the number of errors found, for the operations department, the stability of the systems and the minimum number of incidents. Such a model of work often leads to a conflict of interest: the first try to write the code as soon as possible and send it for review, the second is ready to check and test for as long as possible to identify all the bugs, and the third hardly accepts the code because any changes entail potential risks for the entire IT infrastructure. As a result, the entire process of creating applications stretches for a long time, which, given the difficult economic situation, is completely unacceptable, because the business should be as flexible and customer-oriented as possible, and the release of new products and services is timely.
Of course, many companies have long realized the ineffectiveness of this model of application release and began searching for ways to optimize it. One of such methods is the Agile model, which provides for fruitful interaction between the development and testing departments, which is carried out in accordance with the general goals, general rules and general performance criteria. At the same time, the operations department is still “beyond the scope” of the Agile model. If developers and testers are interested in creating a workable code as quickly as possible, with no errors, then exploitation, as before, is not ready for new approaches. After all, any change made with the advent of the new program code is fraught with potential emergencies and other undesirable incidents in the work of the IT infrastructure. There is a possibility that with the installation of a new version of the software, everything will simply “collapse”. This is precisely what the specialists of the maintenance services fear, and often such concerns are not unreasonable.
It is necessary to remove the last obstacle between developers and testers, on the one hand, and operational services, on the other. This task is designed to solve the methodology DevOps, which, in fact, expands the scope of Agile, involving them in the unit for operation, but not only. It can be implemented in the traditional classical model of the development of Waterfall. There are options when one part of the team works according to the methodology of Agile, and the other - on Waterfall. At the same time, the transition to DevOps will allow to take into account common interests and criteria in order to establish joint effective interaction between literally all divisions - developers, testers and operation specialists. After all, the essence of DevOps is not only in formalized processes, but in changing the culture of software development.
')
What will help implement the DevOps methodology in the company? First of all, we need such approaches that maximally automate all processes and the development cycle as a whole. Since the development cycle is large and multifaceted, it uses a wide range of products to automate, including HPE solutions and third-party applications, including free software.
Ho DevOps is not only about technology. An equally important role is played by the interaction of people and processes. According to Gartner, published at the end of last year, 50% of the success of DevOps projects lies precisely in the human factor, 37% in processes, and only 8% in technology. Often, customers hope that after installing and integrating all the necessary software products DevOps will work for them, but such projects fail most often. Until people become a single team with common interests and performance criteria, DevOps will not be able to function. As long as the operation specialists do not realize their responsibility at the stage of setting requirements, and the developers will not be responsible for the quality of the code in operation, the DevOps methodology will remain unclaimed.
What needs to be undertaken for creation of a uniform team by the rules DevOps? First of all, you need to find out how employees work, what helps them and what hinders them. There are many different educational courses on building DevOps, and HPE has such courses. If your organization uses not only classic Waterfall approaches to development, but also Agile methods, you should consider scaling the entire process, in which several teams participate. As the most effective tool for solving this problem, HPE recommends the Scaled Agile Framework.
HPE is actively preparing and has already launched part of the training courses on the transition and development of the DevOps methodology. One of them, DevOps Awareness, is also available in Russia; It describes the general principles of the methodology and the specialized approaches of HPE. In addition, other courses are almost ready for Russian users: in-depth on DevOps, on its use in practice, as well as on related software products.
What is the real economic benefit for the customer is able to bring the transition to the model of DevOps? Methodologically, it is based on the Scaled Agile Framework, which allows you to calculate the benefits in rubles and percentages when switching to DevOps from Waterfall, Agile, and in the case of mixed options. In fact, DevOps can be compared to a car conveyor that quickly removes the finished car from the engineer to the consumer. Compared to Waterfall, for example, DevOps has an undeniable advantage: maximum risk reduction during deployment by automating all processes. When developing according to the Waterfall model, about a third of all errors are due to the human factor: people make mistakes when making changes, preparing infrastructure, etc. Most often, these errors arise from the fact that the various departments involved in the creation of software do not have common tools and there is no opportunity to share the acquired knowledge. Another important point is the erosion of responsibility, when each specialist is responsible only for his own narrow area.
Now it is a little how product support of DevOps is implemented. First, changes are planned in HPE Project Portfolio Manager and Service Manager. This includes the needs and requests reported by the business.
In addition, with the help of Service Manager, the maintenance service can report what changes need to be made to the program code to eliminate a specific incident, and these changes are immediately transformed into a task for the Project Portfolio Manager. Another product with which Project Portfolio Manager integrates is HPE Agile Manager, in which a task is associated with a User story. Thus, by assigning a task to the Project Portfolio Manager, we can indicate that this task will be implemented according to a flexible methodology in Agile Manager, that is, we will integrate them, and as a result, all of the Agile Manager user stories are displayed in the Project Portfolio Manager.
The next stage is development. You can use absolutely any development environment - Visual Studio, Eclipse, etc. All of these products also integrate with Agile Manager and have access to User Story. The developer in a familiar environment receives notifications from the Agile Manager about the assignment of one or another User Story to him, after which he takes it into operation and begins to change the program code in accordance with the task set. After changing the code, you can perform security monitoring using HPE Fortify Static Code Analyzer and, if necessary, perform other auxiliary operations, and then issue a command to perform subsequent operations. The generated code is stored in the repository (Git or any other), and then automatically compiled with saving compilation artifacts. At the same time, the Universal Configuration Management Database (UCMDB) is updated, which automatically switches to the new version of the software being developed. The entire process, as a rule, is managed by Jenkins or another Continuous Integration Tool, an integration platform that ensures the continuity of software development processes.
Next, Jenkins prepares environments for testing. Here you can use HPE Codar, VMware, Docker or other products. The most common static test circuits, in which changes are made in automatic mode. If necessary, test environments — both physical and virtual, or mixed — can be created entirely from scratch. It is at this stage that one third of the configuration errors that occur when performing this procedure in manual mode can be avoided. Monitoring is built into the test environment, which allows to detect possible errors as soon as possible. Further monitoring scripts will be applied in the industrial environment.
After deploying the test environment, Jenkins runs an automated test procedure: functional, load, performance, integration, regression, or other types of tests. In the case of their successful passage on all circuits, the code is automatically deployed on the industrial environment and is last checked for operability.
According to many customers, the value of the described approach is that it allows you to get a complete picture of the development model - with the participation of absolutely all stakeholders, with clearly defined processes and integration mechanisms. In conclusion, it should be emphasized that the strategy of Hewlett Packard Enterprise in relation to DevOps implies the use of not only HPE products, but also any other solutions, because the main thing, as mentioned above, is not technology, but people and processes.
Of course, many companies have long realized the ineffectiveness of this model of application release and began searching for ways to optimize it. One of such methods is the Agile model, which provides for fruitful interaction between the development and testing departments, which is carried out in accordance with the general goals, general rules and general performance criteria. At the same time, the operations department is still “beyond the scope” of the Agile model. If developers and testers are interested in creating a workable code as quickly as possible, with no errors, then exploitation, as before, is not ready for new approaches. After all, any change made with the advent of the new program code is fraught with potential emergencies and other undesirable incidents in the work of the IT infrastructure. There is a possibility that with the installation of a new version of the software, everything will simply “collapse”. This is precisely what the specialists of the maintenance services fear, and often such concerns are not unreasonable.
It is necessary to remove the last obstacle between developers and testers, on the one hand, and operational services, on the other. This task is designed to solve the methodology DevOps, which, in fact, expands the scope of Agile, involving them in the unit for operation, but not only. It can be implemented in the traditional classical model of the development of Waterfall. There are options when one part of the team works according to the methodology of Agile, and the other - on Waterfall. At the same time, the transition to DevOps will allow to take into account common interests and criteria in order to establish joint effective interaction between literally all divisions - developers, testers and operation specialists. After all, the essence of DevOps is not only in formalized processes, but in changing the culture of software development.
')
What will help implement the DevOps methodology in the company? First of all, we need such approaches that maximally automate all processes and the development cycle as a whole. Since the development cycle is large and multifaceted, it uses a wide range of products to automate, including HPE solutions and third-party applications, including free software.
Ho DevOps is not only about technology. An equally important role is played by the interaction of people and processes. According to Gartner, published at the end of last year, 50% of the success of DevOps projects lies precisely in the human factor, 37% in processes, and only 8% in technology. Often, customers hope that after installing and integrating all the necessary software products DevOps will work for them, but such projects fail most often. Until people become a single team with common interests and performance criteria, DevOps will not be able to function. As long as the operation specialists do not realize their responsibility at the stage of setting requirements, and the developers will not be responsible for the quality of the code in operation, the DevOps methodology will remain unclaimed.
What needs to be undertaken for creation of a uniform team by the rules DevOps? First of all, you need to find out how employees work, what helps them and what hinders them. There are many different educational courses on building DevOps, and HPE has such courses. If your organization uses not only classic Waterfall approaches to development, but also Agile methods, you should consider scaling the entire process, in which several teams participate. As the most effective tool for solving this problem, HPE recommends the Scaled Agile Framework.
HPE is actively preparing and has already launched part of the training courses on the transition and development of the DevOps methodology. One of them, DevOps Awareness, is also available in Russia; It describes the general principles of the methodology and the specialized approaches of HPE. In addition, other courses are almost ready for Russian users: in-depth on DevOps, on its use in practice, as well as on related software products.
What is the real economic benefit for the customer is able to bring the transition to the model of DevOps? Methodologically, it is based on the Scaled Agile Framework, which allows you to calculate the benefits in rubles and percentages when switching to DevOps from Waterfall, Agile, and in the case of mixed options. In fact, DevOps can be compared to a car conveyor that quickly removes the finished car from the engineer to the consumer. Compared to Waterfall, for example, DevOps has an undeniable advantage: maximum risk reduction during deployment by automating all processes. When developing according to the Waterfall model, about a third of all errors are due to the human factor: people make mistakes when making changes, preparing infrastructure, etc. Most often, these errors arise from the fact that the various departments involved in the creation of software do not have common tools and there is no opportunity to share the acquired knowledge. Another important point is the erosion of responsibility, when each specialist is responsible only for his own narrow area.
Now it is a little how product support of DevOps is implemented. First, changes are planned in HPE Project Portfolio Manager and Service Manager. This includes the needs and requests reported by the business.
In addition, with the help of Service Manager, the maintenance service can report what changes need to be made to the program code to eliminate a specific incident, and these changes are immediately transformed into a task for the Project Portfolio Manager. Another product with which Project Portfolio Manager integrates is HPE Agile Manager, in which a task is associated with a User story. Thus, by assigning a task to the Project Portfolio Manager, we can indicate that this task will be implemented according to a flexible methodology in Agile Manager, that is, we will integrate them, and as a result, all of the Agile Manager user stories are displayed in the Project Portfolio Manager.
The next stage is development. You can use absolutely any development environment - Visual Studio, Eclipse, etc. All of these products also integrate with Agile Manager and have access to User Story. The developer in a familiar environment receives notifications from the Agile Manager about the assignment of one or another User Story to him, after which he takes it into operation and begins to change the program code in accordance with the task set. After changing the code, you can perform security monitoring using HPE Fortify Static Code Analyzer and, if necessary, perform other auxiliary operations, and then issue a command to perform subsequent operations. The generated code is stored in the repository (Git or any other), and then automatically compiled with saving compilation artifacts. At the same time, the Universal Configuration Management Database (UCMDB) is updated, which automatically switches to the new version of the software being developed. The entire process, as a rule, is managed by Jenkins or another Continuous Integration Tool, an integration platform that ensures the continuity of software development processes.
Next, Jenkins prepares environments for testing. Here you can use HPE Codar, VMware, Docker or other products. The most common static test circuits, in which changes are made in automatic mode. If necessary, test environments — both physical and virtual, or mixed — can be created entirely from scratch. It is at this stage that one third of the configuration errors that occur when performing this procedure in manual mode can be avoided. Monitoring is built into the test environment, which allows to detect possible errors as soon as possible. Further monitoring scripts will be applied in the industrial environment.
After deploying the test environment, Jenkins runs an automated test procedure: functional, load, performance, integration, regression, or other types of tests. In the case of their successful passage on all circuits, the code is automatically deployed on the industrial environment and is last checked for operability.
According to many customers, the value of the described approach is that it allows you to get a complete picture of the development model - with the participation of absolutely all stakeholders, with clearly defined processes and integration mechanisms. In conclusion, it should be emphasized that the strategy of Hewlett Packard Enterprise in relation to DevOps implies the use of not only HPE products, but also any other solutions, because the main thing, as mentioned above, is not technology, but people and processes.
Source: https://habr.com/ru/post/301976/
All Articles