What is the difference between blue-green publishing, rolling publishing and gray publishing?

During project iterations , It is inevitable that ” go online “. Going online corresponds to deployment , Or redeploy ; Deployment corresponds to modification ; Modification means risk . There are a lot of technologies to deploy and release right now , Here is a summary of the common .

It's hard to avoid some abstraction , Take a scenario example , You are the person in charge of the microblog project , Now the new edition is a big change from the old one , This design goes to the service architecture 、 front end UI wait , After testing, there is no obstacle to the function , So how to make users switch to the new version at this time ?

Obvious , There is no such problem in the first application , This kind of thinking about how to publish will only appear in later version iterations .

01、 Blue green release

Blue and green deployment , There are two systems ： One is the system that is providing services ( That's the old version mentioned above ), Marked as “ green ”; The other is the system to be released , Marked as “ Blue ”. Both systems are fully functional , And the running system , Only the system version is different from the external service . The old system that is providing services to the outside world is the green system , The newly deployed system is the blue system .

The blue system does not provide external services , What to do ？

For pre release testing , Any problems found during the test , It can be modified directly on the blue system , Do not interfere with the system the user is using .

The blue system has been tested over and over again 、 modify 、 verification , After confirming that the online standard is met , Switch users directly to the blue system , For a period of time after switching , It's still blue and green , But the user has access to the blue system . Observe the blue system during this time （ New system ） Working state , If something goes wrong , Switch directly back to the green system .

When you are sure that the blue system for external services is working , When the green system that does not provide external services is no longer needed , The blue system has officially become an external service system , Become a new green system . The original green system can be destroyed , Release resources , be used for [ Deploy the next Blue System .

02、 Blue and green release features

1. The purpose of blue-green deployment is to reduce the interruption time during release 、 The ability to quickly retract releases .

2. Only when the two systems are not coupled can they be guaranteed not to interfere

03、 Blue and green release notes

Blue green deployment is just [ One of the online strategies , It's not a panacea for all situations . The premise that blue-green deployment can be implemented simply and quickly is that the target system is very cohesive , If the target system is quite complex , So how to switch 、 Whether the data of the two systems need to be synchronized and so on , You need to think about it .

When you switch to the blue environment , Unfinished business and new business need to be properly handled . If your database back end can't handle it , It will be a troublesome problem ;

• There may be problems that need to be dealt with at the same time “ Microservice architecture application ” and “ Traditional architecture applications ” The situation of , If in blue and green [ The two are not well coordinated in deployment , It's still possible to cause the service to stop .

• Synchronous migration of database and application deployment needs to be considered in advance / The problem of rollback .

• Blue green deployment needs infrastructure support .

• In a non isolated infrastructure （ VM 、 Docker etc. ） Execute blue-green [ Deploy , There is a risk that the blue environment and the green environment will be destroyed .

04、 Rolling release

Generally, one or more servers are taken out to stop the service , Perform the update , And put it back into use . Go round and begin again , Until all instances in the cluster are updated to the new version .

Publishing process :

Compared with the blue-green release, it needs a complete set of machines , Rolling publishing requires only one machine ( Here, this is to understand , It could be more than one ), We just need to deploy part of the functionality on this machine , And then replace the running machine , Pictured above , Deploy the updated functions in Server1 On , then Server1 To replace the running Server, The replaced physical machine can be deployed again Server2 A new version of the , And then replace the one that's working Server2 , And so on , Until all the servers are replaced , thus , Service update complete .

05、 Rolling release features

1. This kind of deployment is relative to the blue-green deployment , Save more resources —— It doesn't need to run two clusters 、 Double the number of instances . We can deploy part of , For example, only clusters are taken out at a time 20% upgrade .

2. Rollback is difficult

06、 Roll to release notes

1. Rolling publishing doesn't have a viable environment . Use blue and green [ Deploy , We can clearly see that the old version is feasible , And use scrolling to publish , We are not sure .

2. Modified the existing environment .

3. Rollback is difficult . for instance , In one release , We need to update 100 An example , Each update 10 An example , Each deployment requires 5 minute . When scrolling to 80 An example , Problems found , Need to roll back , This rollback is a pain , And it's a long process .

4. sometimes , We can also scale the system dynamically , If during deployment , Automatic expansion of the system / It's shrinking , We also need to determine which node uses which code . Although there are some automated operation and maintenance tools , But it's still scary .

5. Because it's a gradual update , So when we go online with the code , There will be a temporary inconsistency between the old and new versions , If there is a high demand for online scenes , Then we need to consider how to do a good job of compatibility .

07、 Grayscale Publishing

Grayscale Publishing , It's also called the canary . Between black and white , A publishing method that can smooth the transition .AB test It's a grayscale publishing method , Let some users continue to use A, Some users began to use B, If the user is right B There is no objection , Then gradually expand the scope , Move all users to B Up here . Gray level release can guarantee the stability of the whole system , It can be found in the initial grayscale 、 Adjustment issues , In order to ensure its impact , And what we usually call Canary [ Deployment is also a way of grayscale publishing .

Specific to the server , More control can be done in practice , for example , For the original update 10 Set a lower weight for each server 、 Control is sent to this 10 Number of requests per server , Then gradually increase the weight 、 Increase the number of requests . A smooth transition idea , This control is called “ Flow segmentation ”.

17 century , British miners found out , Canaries are very sensitive to gas . Even if there is an extremely small amount of gas in the air , Canaries will stop singing ; And when the gas content exceeds a certain limit , Although the blunt human beings are not aware of , Canary has already died of poison . At that time, the mining equipment was relatively simple , Every time the workers go down the well, they bring a canary with them “ Gas detection index ”, In order to evacuate in a dangerous situation .

The process :

1. Be ready to deploy artifacts at all stages , Include ： Build artifacts , The test script , Configuration files and deployment manifest files .

2. take “ The canary ” The server is deployed into the server , test .

3. Remove from the load balancing list “ The canary ” The server .

4. upgrade “ The canary ” application （ Drain the original flow and carry out [ Deploy ）.

5. Automate testing of applications .

6. take “ The canary ” The server is added back to the load balancing list （ Connectivity and health checks ）.

7. If “ The canary ” Online use test succeeded , Upgrade the remaining servers .（ Otherwise, roll back ）

08、A/B test

A/B Testing and blue and green release 、 Rolling release and Canary release , It's totally different .

Blue green release 、 Rolling publishing and Canary are publishing strategies , The goal is to ensure the stability of the new online system , It's about the new system BUG、 hidden danger .

A/B The test is the effect test , There are multiple versions of the service at the same time , These services are well tested , Reached [ Launch standard services , There are differences, but there is no distinction between the old and the new （ they [ Blue and green deployment may be adopted when going online ）.

A/B The test focuses on the actual effect of different versions of the service , For example, conversion rate 、 Orders, etc .

A/B When testing , Running multiple versions of the service online at the same time , These services usually have some differences in experience , For example, page styles 、 Color 、 The operation process is different . By analyzing the actual effect of each version of the service , Choose the best version .