Blue and green release
Blue and Green Release Features
Precautions for blue-green release
Rolling Publishing
Rolling Release Features
Rollover Release Notes
Grayscale publishing
A/B testing
Assuming you are the Twitter project manager, the new version has undergone significant changes compared to the old version, including design of service architecture, front-end UI, etc. After testing, there are no obstacles to functionality. How can users switch to the new version at this time?
Blue and Green Release Features
Obviously, there is no such issue with the first release of the application, and this kind of thinking about how to release will only appear in subsequent version iterations.
In the blue-green deployment, there are two systems in total: one is the service system being provided (i.e. the old version mentioned above), marked as "green"; The other set is a system ready for release, marked as "blue". Both systems are fully functional and running, but the system version and external service situation are different. The old system that is providing services to the outside world is a green system, while the newly deployed system is a blue system.
The blue system does not provide external services, what is it used for?
Used for pre release testing. If any issues are found during the testing process, they can be directly modified on the blue system without interfering with the system being used by users.
After repeated testing, modification, and verification, the blue system determines that it meets the online standards and directly switches users to the blue system. After switching, for a period of time, the blue and green systems still coexist, but the user is already accessing the blue system. During this period, observe the working status of the blue system (new system), and if there are any problems, directly switch back to the green system.
When it is confirmed that the blue system that provides services to the outside world is working properly and the green system that does not provide services to the outside world is no longer needed, the blue system officially becomes the new green system that provides services to the outside world. The original green system can be destroyed, releasing resources for deployment of the next blue system.
Blue and Green Release Features
- The purpose of blue-green deployment is to reduce interruption time during publication and enable quick recall of publications.
- Only when the two systems are not coupled can there be 100% guarantee of no interference
Precautions for blue-green release
Blue green deployment is just one of the online strategies, and it is not a universal solution that can handle all situations. The premise for the simple and fast implementation of blue-green deployment is that the target system is very cohesive. If the target system is quite complex, careful consideration should be given to how to switch, whether the data of the two systems needs to be synchronized, and so on.
When you switch to the blue environment, it is necessary to properly handle unfinished business and new business. If your database backend cannot handle it, it will be a relatively troublesome problem;
It may be necessary to process "Microservices architecture application" and "traditional architecture application" at the same time. If the two are not well coordinated in the blue-green deployment, the service may still be stopped.
It is necessary to consider the issue of synchronous migration/rollback between database and application deployment in advance.
Blue green deployment requires infrastructure support.
Performing blue green deployment on non isolated infrastructure (VM, Docker, etc.) poses a risk of destruction for both blue and green environments.
Rolling Publishing
Typically, one or more servers are taken out of service, updated, and put back into use. Cycle through until all instances in the cluster are updated to the new version.
Release process:
Compared to the need for a complete set of machines for blue-green publishing, rolling publishing only requires one machine (for understanding, it may actually be multiple machines). We only need to deploy some functions on this machine, and then replace the running machine, as shown in the figure above. The updated functions are deployed on Server1, and then Server1 replaces the running server. The replaced physical machine can continue to deploy the new version of Server2, Then replace the working Server2, and so on, until all servers are replaced, and the service update is complete.
Rolling Release Features
- This deployment method is more resource efficient compared to blue green deployment - it does not require running two clusters or twice the number of instances. 2.We can partially deploy, for example, upgrading by only taking out 20% of the cluster at a time.
Rollback difficulties
- Rollover Release Notes There is no confirmed feasible environment for rolling publishing. Using blue-green deployment, we can clearly know that the old version is feasible, while using rolling release, we cannot be certain.
- Modified the existing environment.
- Rolling back is difficult. For example, in a certain release, we need to update 100 instances, 10 instances at a time, and each deployment takes 5 minutes. When scrolling to the 80th instance, a problem was discovered and a rollback was needed, which was a painful and lengthy process.
- Sometimes, we may also dynamically scale the system. If the system automatically expands/shrinks during deployment, we also need to determine which node is using which code. Despite some automated operation and maintenance tools, they are still terrifying.
- Because it is a gradual update, there will be a brief inconsistency between the old and new versions when we launch the code. If there are high requirements for online scenarios, we need to consider how to ensure compatibility.
Grayscale publishing
Grayscale publishing, also known as canary publishing. It refers to a publishing method that can smoothly transition between black and white. AB test is a grayscale publishing method that allows some users to continue using A and some users to start using B. If users have no objections to B, gradually expand the scope and migrate all users to B. Grayscale publishing can ensure the overall stability of the system, and problems can be detected and adjusted at the initial grayscale to ensure their impact. What we commonly refer to as canary deployment is also a way of grayscale publishing.
Specifically, on the server, more control can be done in practical operations, such as setting a lower weight for the initial 10 updated servers, controlling the number of requests sent to these 10 servers, and gradually increasing the weight and number of requests. A smooth transition approach, this control is called "traffic segmentation".
Prepare the artifacts for deployment at each stage, including: build artifacts, Test script, configuration files, and deployment Manifest file.
Deploy the 'Canary' server into the server for testing.
Remove the 'Canary' server from the load balancing list.
Upgrade the "Canary" application (eliminate existing traffic and deploy it).
Test automation of applications.
Add the 'Canary' server back to the load balancing list (connectivity and health checks).
If the online usage test of 'Canary' is successful, upgrade the remaining other servers. (Otherwise, roll back)
A/B testing
A/B testing and blue-green release, rolling release, and canary release are completely different things.
Blue green release, rolling release, and canary are release strategies, with the goal of ensuring the stability of the newly launched system and focusing on the bugs and hidden dangers of the new system.
A/B testing is an effectiveness test, where multiple versions of services are available for external service at the same time. These services have undergone sufficient testing and meet the online standards, with differences but no distinction between old and new (they may have been deployed in a blue and green manner when they were launched).
A/B testing focuses on the actual performance of different versions of services, such as conversion rates and order status.
During A/B testing, multiple versions of services are running simultaneously online, and these services often have some differences in experience, such as different page styles, colors, and operational processes. Relevant personnel select the most effective version by analyzing the actual performance of each version of the service.
Top comments (0)