This article explains from a development and operation and maintenance perspective at multiple levels what scenarios should be Dev and Ops and what scenarios should be
DevOps, that is, the division and integration of DevOps, and uses a Demo example to tell you how to implement continuous deployment of key steps in DevOps.
Two perspectives of DevOps
DevOps is literally development and operation and maintenance, and there are also translations for development, operation and maintenance (operation) integration. Our two perspectives here are nothing other than development and operation and maintenance. The development here cannot be simply understood as a development engineer. It refers to all the elements contained in the entire software development process, covering requirements analysis, development, testing, etc. The end point is a deliverable software product. Similarly, O&M is not only an O&M engineer, but also refers to a series of processes such as the commissioning process after software delivery and subsequent operations and feedback. The starting point is the acceptance of delivered software products.
The distinction between these two perspectives implies the logic behind software engineering. Like a building, his builder is a construction and design company, and his operator is a property company. There is a relatively clear relationship between the two. limit.
DevOps division and cooperation
We need to review the development of the software industry to see why
DevOps was proposed and why we should now emphasize the close integration of Dev and Ops and what scenarios should be closely integrated and what scenarios are not needed.
The following four aspects prompted the software industry to realize the role of DevOps:
Networking: The typical traditional software represents the Office series. Most of Photoshop and the like do not require network support, and can be used on a single computer. This type of software does not involve operation and maintenance, so there is no
DevOps concept. New types of Internet-based software, such as WeChat and Tencent conferences, are built on the network. This is a typical C/S architecture. The server-side software status in the C/S architecture is extremely important. The server-side software is The invisible hidden behind many users, requiring stability, security and other operation and maintenance requirements, led to a collaborative development and operation and maintenance work.
Web-based: Compared with C/S software, B/S software has a higher frequency of update releases on the user side (C/S is a desktop or mobile application, B/S is a web page), and needs to support the update process. Discontinuation of service, non-informative updates and other features have higher requirements for the speed and quality of software delivery, which has also led to a collaborative demand for development and operation and maintenance.
Cloudization: Traditional ERP, CRM, HRM, and video conferencing systems are all implemented independently by software vendors to customers, and these softwares are also gradually clouding, resulting in sales such as Yishang, Tencent Meeting, Dingding, and WeChat. Such as SaaS application software, such SaaS-based software is more urgent for
DevOps.
Agile: The traditional outsourcing software delivery model has begun to shift to agile, small-step and high-speed iteration modes due to its long feedback cycle and high implementation costs. Higher delivery speed requires development and operation and maintenance. Build a collaborative culture, processes, standards, and tools.
If your software does not meet the above four development directions, it is enough to see here, you do not need to
practice DevOps, and trying will only cause you unnecessary trouble.
DevOps is gradually blurring the line between development and operation and maintenance:
DevOps division and cooperation
After discussing two perspectives, two-way mobile, and four levels, this article will elaborate the biggest problem of DevOps practice with the theme of the middle overlap of development and operation and maintenance (software delivery).
Development perspective
The information and concepts concerned in the development phase are quite different from the operation and maintenance operation phases and partially overlap:
DevOps division and cooperation
Operation and maintenance perspective
Similarly, the information and concepts that the operation and maintenance stage focuses on are quite different from the development stage, and there is some overlap:
DevOps division and cooperation
Focusing of perspective
When understanding the DevOps concept and considering it globally, it is necessary to understand the broadness of the development phase and the operation and maintenance phase as mentioned above. However, due to space limitations, the continuous deployment topic designed in this article will focus on the development phase. At the end of the operation and O&M phase, consider the narrowly defined O&M concept (ie, the traditionally understood scope of O&M engineers’ work) and discuss the division and integration of DevOps by analyzing the changes in O&M engineers’ work content.
So for the basic work of operation and maintenance engineers, the model can be simplified into the following two aspects:
DevOps division and cooperation
Left shift of business operation and maintenance
In the scenario of high-frequency program release and explosive business growth, the operation and maintenance team is becoming more and more painful. In addition, many teams do not have suitable tool systems and standardized deployment processes, and often see two-way complaints within the team:
The development team says:
Why can't we fix the bug on my side today? Do I need to check the production environment log for 3 hours? Can operation and maintenance students always copy the wrong configuration items?
The operation and maintenance team said:
Please use the document to write clearly the release steps and precautions and carefully evaluate the release risks. The operation and maintenance team has filled all the release plans. Your repair problem is not serious. Please wait until next week.
The operation and maintenance team is caught in infinite mechanical repetitive labor, and most of the work is low-leveraged execution and release, query logs, and perform rollbacks.
This is a separate scenario of DevOps. There are problems such as uneven work pressure, lack of trust, and inconsistent goals between teams. It is recommended to try to move some business operations to the left, that is, to put the business on the basis of a suitable tool system. Part of the operation and maintenance power or personnel are assigned to the development team, so that they can complete most of the program release, configuration update, log query and other tasks, liberating operation and maintenance.
The personnel can be part-time business operation and maintenance, or the development team has full-time business operation and maintenance personnel. The essence is that the main work of business operation and maintenance is closed within the development team to achieve efficient operation.
DevOps division and cooperation
In this way, the integration of Dev and Ops is realized to some extent.
Right shift of infrastructure operation and maintenance
The development of information and data security, and the development of virtualized, flexible, and even coded infrastructure represented by the cloud have also brought new challenges and opportunities to the operation and maintenance of the infrastructure of the operation and maintenance team. We will find that the infrastructure operation and maintenance team has gradually shifted to the right under the development of the cloud (the trust of the infrastructure is given to the cloud for processing).
In an era when there was no cloud hosting, the operation and maintenance team had to carry heavy servers to the computer room, install the operating system and configure the network strategy according to the official guide; in the cloud hosting era, when the container had not arrived, the operation and maintenance team got rid of Physical servers, but have to maintain a lot of server software, install, uninstall, batch release, etc., to maintain the basic software environment for business operations; after having container technology such as Kubernetes, Docker, operation and maintenance engineers from the maintenance software operation basic environment Relieve and switch to a higher-level infrastructure: monitoring system, load balancing, etc.; in the near future, when Serverless reconstructs the cloud computing system, the operation and maintenance personnel need not pay attention to the monitoring system, load balancing, etc. Hand it to the cloud to solve it.
The continuous development of the cloud is also a process of gradually engulfing the work of infrastructure operation and maintenance personnel. Now that the operation and maintenance personnel have cloud LB on the basis of the cloud, there is no need to operate and maintain HAProxy, Nginx, etc., and the cloud database does not need to be operated. Dimension MySQL, Redis, etc. As mentioned above, the operation of infrastructure operation and maintenance has been moved to the right by the cloud.
Of course, this right shift is not a one-time process, it is a gradual process, which requires the industry to slowly accept it, but also the maturity and development of the cloud. The recent ups and downs of the Weimeng operation and maintenance personnel deleting and running the library is a good evidence. They used Tencent Cloud. Tencent Cloud finally helped them retrieve the data, but their infrastructure operation and maintenance were not moved to the right enough. In other words, cloud native penetration is not deep enough. If you use a database infrastructure such as cloud database, you may not need to use hard disk recovery technology to retrieve data.
It is true that cloud products still have a long way to go, but with the existing cloud capabilities, you can think about how much your team’s infrastructure operation and maintenance has moved to the right, what is the problem that hinders the right movement, and the right movement is not enough How much personnel energy is wasted and how much risk is brought.
Four important aspects of DevOps
Carefully assessing the delivery mechanism of your software and the degree to which the O&M team moves left and right are the key factors for choosing which DevOps split-up strategy to use and the success of DevOps practices.
The division and integration of DevOps has a great relationship with the left and right movement of operation and maintenance work, the development of cloud technology, and the unification of cloud native standards. The concept of DevOps can be reflected on many levels. This article is the main one that can make DevOps A brief introduction to the four levels of the team’s true perception:
Looking at DevOps from the perspective of personnel management
To practice the division and integration of DevOps, you must configure the appropriate team configuration. There are several categories of configurations:
Viewing DevOps from the perspective of information flow
DevOps is a collaborative culture, collaborative process, and the essence of collaboration is smooth and accurate information flow.
A simplified typical DevOps information flow model is roughly as follows:
DevOps division and cooperation
The smooth and accurate flow of information lies in whether the information is structured, process-oriented and standardized. All information transfer depends on the form of chat groups, meetings, emails, etc. The seemingly one-touch information transfer often has problems that are not focused, information is missing, information relies on human follow-up, etc. It is actually not smooth. not accurate.
The core should grasp whether the following nodes of the
DevOps practice team have smooth and accurate information transmission:
