Introduction: the full line column “RESEARCH and development efficiency improvement 36 count _ continuous delivery” online! Through 10-20 articles, this column will systematically share how enterprises can land and deliver in the era of cloud native. This is the second installment of this column. What is continuous delivery?

Editor’s note: The full column “R&D performance improvement 36 count _ continuous delivery” online! Through 10-20 articles, this column will systematically share how enterprises can land and deliver in the era of cloud native. This is the second installment of this column.

What is continuous delivery?

First, let’s look at what continuous delivery is. In our opinion, continuous delivery should contain at least four points:

● Persistence: As the name implies, it is uniform and scattered. Specifically, to:

Small granularity: The granularity of a continuous release must be small; it is difficult to be “continuous” when it is large.

** Frequency: ** frequency should be very high.

● Fast: The whole delivery process in continuous delivery is fast and the delivery frequency is very high. To be fast requires.

** Short process: ** Be “short” in testing, release, development, etc. In order to achieve rapid feedback, rapid response.

Less waiting: The waiting between processes and processes and between processes and other processes should be “less”.

Fast feedback: after submitting the code, the submitted problem should be fed back within a short time, and the problem should be fixed as soon as possible and then get another repair feedback as soon as possible.

● High quality: ** Continuous delivery is to be able to ensure quality, must achieve high quality. High quality needs to be guaranteed:

Quality visibility: To judge a job well done, we need to see it first, so visibility is very important.

Fewer bugs: Software should work as intended, not with lots of potential bugs in it.

Fewer failures: Each software failure costs not only the customer, but also the software team. Many customer opportunities and business assets can be lost because of too many failures.

● Low risk: In today’s Internet environment, risk is everywhere, so we need to be safe, compliant and trusted.

Software observability: The most important thing to know about software risk is to be observable and know what the software is currently like.

Controllable release: We’ll cover that later.

Problem traceable: If there is a release problem or software glitch, we can trace the entire problem back to its source. Where it started, where it was introduced, it needs to be able to go back.

System rollback: If there is a problem that really cannot be resolved or resolved quickly, we need to be able to roll it back quickly to avoid greater risk.

The above are the four key points of continuous delivery. Continuous delivery can only be achieved by meeting the four points of continuous, fast, high quality and low risk. All four are indispensable. Small particle size, high frequency, is the premise of fast. Correspondingly, only when the quality is high, can the risk be lower.

The question is: how?

Continuous delivery based on cloud and cloud native technologies

In our view, continuous delivery in the cloud native era requires three things: immutable infrastructure, continuous delivery pipeline, and secure and trusted release.

1. Immutable infrastructure

There is a book called The Container Changed the World. The book describes how the invention of the container transformed the fragmented system of transporting goods into a container-based unit, and thus brought about a 95 percent reduction in freight costs.

If we look at software delivery, in the past our development language is built in a variety of ways, programs are packaged, run, management are also different, these differences make our software delivery is facing great risks.

Before the advent of containers, many attempts were made on operation and maintenance tools and deployment tools, but they were not very successful and were not as popular as containers as a whole. The reason is that containers do what containers do — standardize.

Based on the container, we also made K8S, the distribution of the container and the whole deployment operation and maintenance system, and the operating environment was also done. On this basis, the birth of a variety of cloud – born databases, cloud – born middleware. So the overall standard for cloud native comes out. Just as the container changed, r&d systems were standardized so that we could treat programs written by different technology stacks in the same way.

Overall, immutable infrastructure offers the following “dividends” :

(1) The uncertainty caused by inconsistency is eliminated: a program may not be able to run in a different environment in the past. The problem is that there are bugs caused by inconsistency at the bottom.

(2) Reduce inconsistent risks: Risks are difficult to predict. Like in a Java program, most of what you do is right, but in some cases, it will get exceptions, and small version differences will create the risk of more exceptions. In this case, you will find that the risks are very difficult to identify, and the consequences of the risks are very serious.

(3) Reduce maintenance costs: because many low-level things have been standardized, we do not need to do. The K8S, for example, does a lot of this.

(4) Deployment is simplified: it’s all the same thing, just like a container.

(5) The cost of environmental maintenance is reduced: after the standardization of universal use, there is no need to have too much burden, just follow this standard.

(6) The cost of tool development and learning is reduced.

Immutable infrastructure gives us a huge technological dividend, and our ecology is becoming more and more intact. It’s just that our old habits, ways of thinking, or ways of working have to change.

2. Continuous delivery to the assembly line

The continuous delivery pipeline is, in part, our entire software delivery process strung together.

The diagram above shows a very typical pipeline: from code submission to merge, build, build an artifact, interface test, functional verification, class production environment deployment verification, final acceptance, live.

The assembly line is a complete process. There is no break, no skip, one layer after another.

With this pipeline, if the code is of good quality and the automation rate is high, the whole thing will automatically tell us in a very short period of time that we have gone live. It’s a wonderful experience, fluid and labor-saving.

In order to achieve the above smooth experience, we have requirements for the assembly line, which are as follows:

(1) Descriptive

An assembly line is a figurative representation of the r&d pattern: an assembly line should be something that can be described. The research and development model is actually described through the pipeline or some other means.

Consistency of release process: With pipelining, the release process is the same every time.

Best practices can be copied quickly: within a company, the r&d practices of different teams often vary greatly, because many things are word-of-mouth or documented, and different people have different ways of understanding and interpreting them. But pipelining allows for rapid replication. It’s not as good to write a process as it is to put it on an assembly line.

(2) observability

Development and release process visibility: In the pipeline, not only the current release and development process can be seen, but also the historical release and development process. You can see what phases each release goes through and what the results of each phase are. So you know what the whole process looks like, what the quality of the whole process looks like, and which nodes in the middle are likely to have problems.

The release process is assured: throughout the pipeline we see a lot of validation nodes, interface tests, pre-release acceptance. All of these nodes cost a lot of money, but they guarantee a successful, stable release. In this way, with the use of assembly line, the whole release process is guaranteed.

(3) automation

Automation, by definition, minimizes human intervention in the process. If the connection between each stage is manually completed, the waiting time and its synergistic cost will be relatively high, which will bring various risks, so we should make the whole release process fully automated. The entire process is driven by the assembly line, from code submission to final release. Even if some steps in the process need to be accepted or tested, it is just a process. After this process is finished, the executor points to confirm that I have successfully accepted, and then it will be automatically delivered. Therefore, the whole process is an automated process.

3. Secure and reliable release

In software delivery, a change in code, configuration, or even a dependency can result in a change in artifacts. Product changes pass through a series of nodes in the pipeline. Among these nodes, there are many points that need to be verified, focused and controlled, such as code review, test verification, review and release control. There will also be a lot of rules, testing items, such as code quality compliance, security testing.

These rules, along with the checks, eventually form a feedback that indicates whether the release is trustworthy or not. If the feedback is wrong, it shouldn’t be published, and if the feedback is good, it can move on.

As a secure and trusted release, it should reduce the risk of release and prevent the loss of business caused by defects. It is more important to reduce the mental burden of publishing and not be afraid to publish.

At the same time, we can get quality feedback and make quality visible through safe and trusted releases. Let us do timely feedback, timely repair, the overall development efficiency will be higher.

Enjoy the continuous delivery of dividends

Continuous delivery provides many benefits, such as:

(1) Eliminate personal dependence: All information is shared, visible, controllable, measurable and accelerated

(2) Reduce the loss between teams: the process is consistent, all versions are consistent, and it is easier to deal with failure.

(3) Reduce the cost of testing and improve the quality: automated tests can be regressive, can be continuously run, can also be repeated, the cost is much lower than manual testing. In the microservices architecture, problems can be located more clearly and easily.

(4) Reduce release risk: Versions can be backtracked and consistent, so release risk can be well controlled. In addition, with the support of trusted releases, the overall release success rate will be more assured.

In this series of articles, we will explain each of the three aspects: immutable infrastructure, continuous delivery pipeline, and secure and trusted release.

The original link

This article is the original content of Aliyun and shall not be reproduced without permission.