The purpose of the article is to give basic ideas about DevOps and the practices used in this methodology. There will be no difficult terms, specific products and the road map of DevOps implementation, but I hope it will be interesting to read.



As such, there is no definition of DevOps, and everyone understands this methodology differently. The declared goal is to remove the barriers between DEV elopment and OP erations. Therefore, DevOps are often understood as the fact that operations, QA and development are in the same team, sit in the same room, hold general meetings, communicate. In itself, the convergence and informal communication of team members is always useful and this can already lead to improved results. But there are also formal practices, following which helps to improve the delivery of releases, and hence the satisfaction of the business.

The following are described here:
')

• Continuous integration
• Automated Testing
• Infrastructure as Code
• Continuous deployment
• Configuration management
• Load testing
• Application Performance Monitoring

The following practices are taken from the Microsoft DevOps-Fundamentals series. Very interesting and useful webinars, however, with an emphasis on Microsoft technology.

The structure of the article is structured as follows: practices are listed, their descriptions are given, the Business Meaning of the practice is presented (how this approach will improve the life of the business) and Measurability (how to measure the improvement). Both Business Value and Measurable are also taken from the DevOps-Fundamentals presentations.

Well, let's get started. The software development and delivery process consists of the following steps:



It all starts with planning. Planning release, development, testing, deployment. We will skip this step, since development and operations are not involved in this step. After the developer has finished the implementation of a certain piece of code, he saves (commit) it to the version control system. After this, the first practice comes into play:

Continuous Integration

Continuous Integration is a software development practice that consists of merging working copies into a common main branch of development several times a day and performing frequent automated project builds to quickly identify and solve integration problems. Wiki

Actually, what is Continuous Integration? The process goes something like this: the developer, after completing his task and debugging, saves his changes to the working copy (TFS, SVN, Git). Then a certain robot (TFS, TeamCity, anything else) comes into effect, tracking the changes in the working version. He sees that the working copy has changed and starts the project build. According to the results of the assembly, the developer (and other interested persons) is notified of whether everything has passed successfully or not. The notification can be through a letter, a message in the tray, or displayed on a web page. Thus, if the build failed, the developer will immediately know about it.

Business value

• Accelerate Delivery - is achieved by the fact that we immediately know about the build error and, accordingly, we can quickly start to fix it.
• Repeatability - the entire process is repeated, that is, if no changes have occurred, then the assembly will also be successful (or not successful). There is no such problem as the fact that one developer is going to, and another is not.
• Optimized Resources - there is no need to manually run the assembly, on a person’s computer or build server, there’s no need to prepare an assembly — download the source from the source control, etc.

Measurability

• Deployment Lead Time - the time it takes to build a project.
• MTTR (Mean Time To Repair - average recovery time). You can measure the time elapsed from the message about the erroneous assembly, before the correction, to remove the error.
• MTTD (Mean Time To Detect - average failure detection time). measures the time that elapsed from making an error, to determining what the problem was and what it is.

Automated Testing

Automated testing is the process of software verification, in which the basic functions and steps of the test, such as starting, initializing, executing, analyzing and issuing the result, are performed automatically using automated test tools © .

After the assembly is assembled, it needs to be checked. This can be done most quickly with the help of automated tests. Various tools are used for this: it can be Unit tests, UX tests, integration tests. The main condition is that they should not require human participation. With the help of auto-tests, we immediately get information about whether there are errors in our assembly. And we can immediately begin to correct them, without waiting for the results of manual testing.

Business value

• Accelerate Delivery. We quickly get information about whether the assembly is valid and whether it can be released.
• Repeatability - the test is always run in the same sequence, according to the same scenario, therefore the result will be the same.
• Resource Optimization (Optimized Resources). Automatic tests are cheaper than manual ones due to the fact that they are much cheaper to perform than testing using manual testing.

Measurability

• Deployment Lead Time - the time required for deployment (assembly, validation).
• MTTR - In this case, the time is measured from diagnosing the error to correcting it (successfully passing the test).
• MTTD - since the tests are automatic, it is possible to measure the time from assembling a project to receiving an error report on the results of testing.

Infrastructure as a code (Infrastructure as Code)

Infrastructure-as-code is the process of managing and preparing the computing infrastructure (processes, physical servers, virtual servers, etc.) and their configuration through machine-processed definition files, rather than physical hardware configuration or the use of Wiki configuration tools .

The approach to configuring applications should be the same as for the code. That is, configuration files, environment variables, something else should be stored in a centralized repository or version control system, possibly in the same as the code is stored. And when configuring the application, they should be taken from there. Accordingly, if it is necessary to change the configuration on the server, the responsible employee does not enter it and changes, for example, the connection to the database, but changes the desired variable in the storage, and from there it automatically appears on the server.

For variables that are specific to different environments (Dev, Stage, Production), synonyms are used that are substituted for real values ​​when deployed. An example of such a substitution is the transform technology used to modify the configuration files of .NET applications.

Habits

• Production first mindset - first of all - production (industrial thinking). Production is at the heart of any organization, software vendor, and the best of them recognize that production should be the top priority of every team member, every role, and not just IT. Intermediate artifacts such as documentation and pre-Prod environments are not enough. Highly motivated performers always keep track of life status, eliminate life problems and root causes, and actively identify problems in software performance and performance.
  
• Infrastructure as a flexible resource - Infrastructure as flexible resource.

Business value

• Optimized Resources - Optimize resources through faster deployment: there is no need to manually edit configurations, especially if there are many servers.
• Accelerate Delivery. The computer will quickly change and adjust the configuration.

Measurability

• Deployment Rate (Deployment Rate). Measured application deployment time.
• MTTR - (Mean Time To Repair). Time to recover.

Continuous Deployment

Continuous deployment - Continuous Integration (Continuous Integration) and Continuous Delivery (Continuous Delivery). This is the next step after successful assembly and successful completion of automatic tests (and, perhaps, the installation is ticked “assembly is ready for deployment” by a responsible person). If you are confident in your tests, their recruitment and coverage, if they succeed, the automatic installation starts on the appropriate environment, test or product. The difference between Continuous Integration, Delivery, Deployment is well described here: http://blogs.atlassian.com/2014/04/practical-continuous-deployment/

Business value

• Resource Optimization (Optimized Resources). Human involvement is minimized.
• Accelerate Delivery. The machine will install everything faster than man.

Measurability

• Frequency of delivery (Deployment Frequency). The number of installations per unit of time (day, week, month, year) is measured.
• MTTR
• Availability.

Release Management

Release management is that we define the formal criteria for whether the assembly is ready for installation on the appropriate environment. An example of the criteria by which the assembly is ready, and, if they are fulfilled, the delivery (Continuous Deployment) starts automatically:

• DEV environment - the assembly passed without errors.
• STAGE environment - the build was installed on the DEV environment and unit tests were successful.
• PROD environment - the assembly was tested on the STAGE environment, there are no more than 5% minor bugs, there are no major bugs, QA Lead and Dev Lead have set Confirm the build of readiness for the PROD environment.

Useful link: Release Management in Visual Studio 2013 .

Business value

• Resource Optimization (Optimized Resources). The resources required to determine when the assembly is ready (and its installations) are always known and can be optimized.
• Accelerate Delivery. We can quickly and regularly (according to strictly defined rules) determine whether an assembly is ready for delivery.

Measurability

• Frequency of delivery (Deployment Frequency).
• MTTR
• Availability (avaibility).

Configuration Management

Configuration Management (Configuration Management) - is a detailed record and update information that describes the software and equipment of the enterprise. Such information typically includes the versions and updates that were applied to the installed software, as well as the location and network addresses of the equipment. ©

Here to the formal definition to add too much and nothing. Everything must be recorded and counted.

Business value

• Faster Detection & Remediation - faster problem determination and recovery.
• Resource Optimization (Optimized Resources).
• Greater flexibility.

Measurability

• MTTD
• MTTR
• Availability

Load Testing

Load testing - a subtype of performance testing, collecting indicators and determining the performance and response time of a software system or device in response to an external request in order to establish compliance with the requirements for this system (device) Wiki

It often happens that, for example, for web applications, when one user (developer or tester) quickly opens a page and responds well to working with it. But as soon as the changes get to the grocery server, and hundreds, thousands of people start watching the same page at the same time, the page loads for a long time and stops responding.
Conducting load testing, we determine the presence of problems at an early stage, even before the problem assembly gets on the product server. Load testing is implemented by generating a large flow of server requests and analyzing server behavior.

Business value

• Improved deployment quality. We can always be sure that the installed assembly meets the performance criteria and does not degrade them.
• Find performance bottlenecks. Diagnosing what place is problematic from the point of view of performance and how it can be solved at an early stage, before customer complaints.
• Cater for demand - customer satisfaction from the constant quality of the product.
• Maintaining application quality (Maintain application quality).

Measurability

• Availability - the availability of the application.
• MTTD
• MTTR

Monitoring Application Performance Monitoring Performance

Monitoring application performance (application performance management) is monitoring and managing software performance and availability. APM seeks to identify and diagnose performance problems in a comprehensive manner to maintain the expected level of service. Wiki

Load testing reveals many problems even before the assembly hit the product servers and the clients started working with it. But, unfortunately, it is not always possible to predict both user actions and the impact of the difference in server resources on test and product environments. Therefore, it is necessary to monitor the status and operation of the application on the product environment. This is what the application performance monitoring serves.

Business value

• Faster Detection & Remediation - faster problem determination and recovery. We quickly learn about the bottlenecks that have arisen in the product system.
• Optimized Resources - optimization of resources. We can redistribute computing resources from services where they are little involved to loaded services.
• More Resilience - great flexibility. Same as in previous paragraph: load balancing.

Measurability

• MTTD
• MTTR
• Availability

I hope this article gave you an idea of ​​what DevOps is and what needs to be done to improve the lives of developers, operations and business.