Java is a strongly typed language that allows extensions to check for potential type mismatch problems at compile time. Java requires explicit method declarations, it does not support C-style implicit declarations. These strict requirements ensure that the compiler can catch the call errors, which leads to a more reliable program.
DevOps construction seems to have become a corporate consensus, but when and how to build is still a concern and headache for enterprises. To what extent is the company's technology, talent, and business suitable for building DevOps?
What are the pits of DevOps programming language?
DevOps construction seems to have become a corporate consensus, but when and how to build is still a concern and headache for enterprises. To what extent is the company's technology, talent, and business suitable for building DevOps? Where should I start in the construction process, and how should we deal with the contradiction between the organizational structure, the original technology stack and DevOps? Is there a reference architecture for DevOps construction? After the construction is completed, how should DevOps develop next?
DevOps, a combination of
Development and Operations, refers to a group of processes, methods, and systems, used to promote communication, collaboration, and integration between development, technology operations, and quality assurance departments. According to the "China DevOps Status Report (2019)" released by the China Information and Communications Technology Institute (CAICT): "Over half of enterprises use DevOps for agile engineering practice management development projects, and nearly 60% of enterprises choose coding specifications, unit testing, and continuous integration. "This shows that
DevOps has become the mainstream of enterprise software R&D and has been adopted by many enterprises.
Although companies all expect to get more value through DevOps and are willing to try actively, the successful practice of DevOps is still a problem. According to the survey results of the "China DevOps Status Report (2019)": "Only 31.65% of the companies can actually implement DevOps successfully. In addition, nearly 40% (41.13%) of the companies actually do not know whether they are successful Implement DevOps."
Although this result is unexpected, it is reasonable. After all, there are many ways to succeed in DevOps, but there are more ways to fail. This article will focus on the contradictions and difficulties in the process of
DevOps construction, making everyone's DevOps construction road smoother.
Contradictions and conflicts in DevOps
The emergence and implementation of any new things must always be accompanied by contradictions and conflicts, and DevOps is no exception. As soon as DevOps appeared, many people began to worry: "Traditional operation and maintenance will be killed by DevOps?" Yes, the first conflict of DevOps soon became apparent, that is, the conflict between traditional operation and maintenance and DevOps. Think that the two are incompatible with each other, what is the actual situation?
For traditional operation and maintenance and
DevOps, in essence, operations is the comprehensive use of personnel, processes and tool platforms to manage IT infrastructure and application systems, and the value of platform and system services is continuously maintained according to a certain SLA Provided to internal or external customers. With the continuous development of business objectives, IT infrastructure, application systems, operation and maintenance concepts, operation and maintenance methods, and operation and maintenance tool platforms, operation and maintenance will present certain development characteristics at different stages or from different angles. "
"Traditional O&M and automated O&M can be simply understood as the characteristic tags that the industry puts on O&M at different stages or from different angles. They each have different characteristics. For example, traditional O&M usually has the characteristics of passive, low standardization, and low automation. ; Automated O&M usually has the characteristics of being proactive, highly standardized, and highly automated."
The right node for enterprises to implement DevOps
In the impression of many people, DevOps is an advanced method framework. The use of DevOps can bring unlimited benefits to enterprises, but the fact is that we have seen many companies’ DevOps practices are not successful, and many developers complain that DevOps is just a " burden". The reason for this situation is that most of the reasons are that enterprises are not prepared to practice DevOps. So, what qualities should companies that want to build DevOps have?
"In theory, no matter whether it is a large enterprise or a small and medium-sized enterprise, whether it is a sensitive or steady state business system, DevOps-related methods and practices can be used." Wang Jinlun said, "When enterprises are conducting DevOps transformation or transformation, it is recommended to start from business Starting with products with high agility requirements (such as Internet-based services provided by enterprises for end users) can fully reflect the capabilities of DevOps. Of course, the effective implementation of DevOps cannot be separated from the support of personnel skills, processes and tool chain platforms. It is also closely related to system architecture (such as micro-service architecture, etc.) and system-dependent infrastructure (such as cloud computing, etc.). Therefore, enterprises should use DevOps methods, micro-service architecture, cloud native architecture, cloud computing, automated testing, continuous integration, and continuous delivery. , Grayscale release and other technical reserves. Of course, enterprises should not want to complete these reserves overnight, but should refer to the
DevOps implementation framework, and gradually carry out technical reserves during the software delivery process, and naturally implement DevOps methods and practices. ."
DevOps Practice and Enterprise Organization Structure
During the construction of enterprise DevOps, the adjustment of organizational structure and the change of employee responsibilities always exist, especially the changes between the roles of Dev and Ops. DevOps Topologies has proposed 9 effective DevOps team structures:
Model 1: Dev and Ops work together seamlessly and are suitable for strong technical leadership.
Model 2: Completely share Ops responsibilities, suitable for organizations with a single major web product or service.
Model 3: Ops is IaaS (platform), suitable for organizations with several different products or services, a traditional Ops department, or applications all running on the public cloud.
Model 4: As an external service, DevOps is suitable for small organizations with insufficient operation and maintenance experience.
Model 5: The DevOps group that sets the validity period is the predecessor of Model 1.
Model 6: DevOps evangelist group, suitable for organizations with Dev and Ops alienating trends.
Model 7: SRE group (Google model), suitable for high-level engineers and mature enterprises.
Model 8: Container-driven collaboration, suitable for organizations where containers can function well.
Model 9: Dev and DBA collaborate, suitable for organizations with multiple applications linking one or more large, central databases.
The above 9 are just the more common DevOps team organizational structure, but there is no perfect DevOps organizational structure in the world, Wang Jinlun suggested: "The adjustment of the organizational structure should be based on the organization's product portfolio, technical leadership, team personnel skill level, operating costs, etc. Comprehensive consideration from the perspective. It is recommended that enterprises establish a cross-functional autonomous team around the value stream as much as possible to achieve continuous delivery of value, and continue to adjust the organizational structure as the maturity of DevOps practices increases."
The complete path and technical selection of DevOps
Although each company has its own actual situation and cannot copy the DevOps practices of others, we can have a more standard and complete
DevOps reference architecture.
A complete and ideal DevOps platform should be able to meet the roles of business, demand, architecture, development, testing, deployment, operation and maintenance, etc., and independently complete relevant work on it. "The DevOps platform should provide project management, prototyping, and source code version management. , Code quality analysis, continuous delivery pipeline, compilation and construction, test management, UI automation testing, interface testing, performance testing, mobile app testing, deployment, release, operation and maintenance, Web IDE, document management, Wikipedia, open source mirror station and other functions characteristic."
In theory and practice, using industry open source tools (such as Redmine, GitLab, Jenkins, etc.) to create a basically usable DevOps platform is not a particularly difficult matter. However, it is not an easy task to choose the technical selection of the DevOps platform, because according to XebiaLabs statistics, there are 15 categories of DevOps-related tools, as many as 120 kinds. At the same time, enterprises must also consider reliability, availability, and performance , Security, integration, continuous upgrade, heterogeneous technology stack and other issues.
The
continuous delivery pipeline, code quality, and mobile apps are used as examples to explain in detail how to do technology selection.
For DevOps platforms, continuous delivery pipeline is the most critical core. Currently Gitlab, Jenkins, Alibaba Cloud, and Huawei Cloud DevCloud can all provide related features. For pipelines, the main capabilities are visualization task orchestration capabilities (layering, parallel/serial, manual intervention, access control, etc.), and large-scale parallel scheduling capabilities. If enterprises use open source software, they should pay special attention to the ability to support massive parallel scheduling.
For software delivery, developers are very concerned about code quality. Many companies now use SonarQube, Findbugs, Checkstyle, Infer and other tools to check the code quality, but they all have to face the challenges of how to similarize the rules between different tools and how to unify the inspection results of multiple tools. At the same time, the application of artificial intelligence AI for code quality analysis and automatic repair has become a trend. Whether open source tools can follow up in time and the quality of the follow up is also a concern for enterprises.
