At first, the understanding of the concept of DevOps only stayed in the "use Bamboo to automate the deployment of services to the specified environment", when we began to try to do the promotion of the DevOps process, the first to determine the program is to promote the use of Bamboo to do the integration of CI/CD in the groups, the second is to address the current project management pain points faced by the project release using semantic version management. The second is to adopt semantic version management for project release in response to the current pain point of confusing project management. But as Conway's Law says, "The organization that designs a system produces a design equivalent to the structure of inter-organizational communication." We can't attempt to change years-long inter-organizational communication and collaboration habits with just one solution identified in a single discussion. And DevOps isn't simply a universal solution, it's an organic integration of Platform, Process, and People.

According to martinfowler's blog post on DevOps culture (below), the most important principles of a DevOps culture are responsibility*** and quality orientation. At this point, I think our company has a natural advantage, in the early stage of the project, including the current project operation lifecycle, R & D took over most of the operation and maintenance work. It can be said that we are never short of "warriors" who dare to take responsibility. But at the same time, in our company's significant expansion of the status quo, to strengthen process management, to ensure the continuation of this culture, while in the mobility of personnel can dynamically strengthen the cultural orientation, which is an important part of the DevOps guiding principles.

Tools = platform + process, first of all, the most significant significance of the platform is to carry the standardized process within the enterprise, the platform solidified each process, can be used to solve certain practical problems, so that the formation of the following characteristics:

Empowered by the platform, all people can be the same operation, to obtain the same results. In this way, handoffs and experts across domains are replaced by the platform, and when something no longer relies on individuals, the waste of waiting is greatly reduced, and the platform becomes a collection of capabilities within the organization.

Any methodology not combined with the actual status of the enterprise to analyze are rogues (ubiquitous Conway's Law), then the actual status of our company, the establishment of this system can solve what problems? In the discussion with the R & D children's shoes, I can see that they are often in the state of only see the trees and not see the forest, the whole "forest" is often mastered by a few people, this point in the quarterly duty visit has been put forward by a number of people. It is true that as a security company, some of our products are sensitive and need to be kept secret, but in terms of the whole hierarchy and architecture, we need to adapt a set of processes to achieve open to technology, encrypted data, and secure processes are exactly the problems that need to be solved by SecDevOps. At the same time, this is also very suitable for the "three-step working method" in the flow principle, only to simplify the complex process, visualization we have the opportunity to let more people see the forest. And the current combination of ecological, software delivery efficiency and quality into the core value of today's enterprises and core competitiveness, DevOps as the third revolution in software engineering, summed up its value is reflected in the following two points:

Let all the manual aspects of the software delivery process, are the future can try to optimize the direction of the DevOps advocate responsibility **** burden, continuous improvement is needed to build rules into the tools and use the tools to guide practice. The real value of DevOps can't be realized if you just move offline processes to online execution. In the end, tools don't solve people problems, and this seemingly tricky path doesn't solve the fundamental problems of the organization. This is where culture comes in.

To summarize, culture and tools in DevOps are two sides of the same coin. We can't blindly follow the tool determinism, and come up with a big effort to purchase and build tools, nor can we blindly talk about culture and create a culture of detachment within the organization. What we want to do is focus on value, focus on status quo, interactive processes and feedback, collaboration and visualization, automation and continuous optimization, minimalist principles, and focus on practice.

Agile management is not just about being agile with R&D, but also for business agility, developing fewer features, focusing on user value, and continuous rapid validation becomes the core idea of product requirements management.

Another way to see this is through the R&D Integration Process diagram. In our company, we are currently using JIRA's Kanban form of requirements management in our products, and this process has a good natural advantage in agile business management. What we need to do is to open up the barrier of communication between product and development, and this part of the process as well as the functionality, in our scheduling is temporarily backed up by a lack of concrete implementation plans, which are only given as follows BizDevOps core concepts:

On the continuous delivery function, is the initial stage of our focus on the stage, which is also as the R & D of the real use of the place, first faced with the first problem, self-research OR open source? Before we started to do DevOps, there are already some excellent open source tools in use as a support point, Jira, Bamboo, BitBucket. these tools to a certain extent to reduce our initial workload, in the subsequent project plan, we have done the basic storage, permissions, DevOps process and so on many aspects of the research. On the storage and permissions of such infrastructure currently have mature open source solutions. But the DevOps process is related to the nature of the business of the company TOG, as well as the current status of the project, we chose to self-research platform, the main planning direction are:

1. version control, change management

The main core idea is:

The main core idea is:

version of the changes in the standardization of the version of the control of everything into the version of the full process traceability and a single trusted data source. , a standardized set of rules and behavioral habits, can reduce the cost of communication in the collaboration process, one-time to do things right, which is also the importance of standards and norms.

2. Continuous build and continuous integration, deployment and release model

The main core idea is: to use automation to complete the process from the project compilation to the release

3. Environment building management, metadata, initial data management

4. Metrics and Feedback

For the delivery efficiency, delivery capability, delivery quality to do metrics statistics, as well as the establishment of a visualization platform. The main metrics include requirements lead time, development lead time, release frequency, release lead time, delivery throughput, online defect density, online defect distribution, and so on.

5. Built-in quality, guaranteed testing

There are two core principles of built-in quality:

In nearly four months of DevOps practice, we did three main things, integration of some of the projects in the Bamboo, the construction of infrastructure, and the development of DevOps platform. development .

Initially, we did some research and practice on DevOps, and based on the principle of using open source projects as much as possible, and relying on the existing technical structure, we worked out a set of procedures for using Bamboo

Open source or self-research? This is always a question of trade-offs, and we've already talked about what we need to do for continuous delivery. When open source components can't cover our current processes, it's only natural that we need to build our own platform

Based on the diagram above, we can see the basic interactions and flow of the FlowDevOps platform. Platform development has now experienced four small version of the iteration, mainly contains the following features:

It is worth mentioning that we selected the Jinja2 as a configuration module unified management of the various environments of the public **** components of the address stored with the platform, to ensure that the service offline deployment of various types of connection errors. At the same time, this approach to the business of less invasive, in line with our short-term to improve the deployment efficiency of the expected.

Admittedly, the construction of DevOps has done a considerable amount of work in the short term, but there is still a certain degree of problems. These include the following:

According to the Global Cloud Summit maturity model predictions

In my division cloud native seems to be very far away from us, unfamiliar technology stack, all kinds of counter-intuitive failures. But why do I still insist that cloud native is the best practice for us to build DevOps in the future, and to evolve our infrastructure design? To quote the CNCF's official definition of cloud native:

The keywords are open source software, microservices applications, containerized deployment, and dynamic orchestration , although some of our current business scenarios have transport-related bottlenecks, and containerization may bring about larger storage volumes. However, from a macro perspective, this is not the status quo for most projects, and the core problem for more of our projects lies in large data volumes, complex business and configuration, and many dependent modules. Cloud-native apps are a perfect match for DevOps, with an aura of high availability, easy maintenance, high scalability, and continuous delivery, as well as native support for microservices, immutable infrastructures, and service grids, which naturally address the complexity of the business and the number of dependent modules.

This is also the reason why I insist on accumulating cloud-native technology solutions in my infrastructure work, cloud-native technology solutions, I always think it can greatly advance the efficiency of our company's construction and technology development. Even if we are in the cloud native program technology accumulation is not enough, for example, can not confirm the efficiency of big data running in containers and such technical issues, but when we build a more efficient operations integration process, there will be more capital to trial and error, this starry sea waiting for us to explore.

We all expect perfection, but most of the time, nothing is perfect. This is especially true for software, and it's also true for DevOps. What we can do is to improve the process a little bit based on each feedback, and reflect on it again and again. In the process of continuous improvement, we may never reach perfection, but as the famous American actress Lily Tomlin said in a classic quote: The road to success is always under construction. .