Use azure SQL Data sync to implement a blue-green deployment on Azure

Rapid rollout of products through agile development automation has become a consensus among most product teams. However, each time we talk about deployment automation with a blue-green deployment, the development and operations team will ask the same question, and the system's Web and app tiers can easily be deployed into two separate systems to reduce business disruption and quickly release products using existing product technology. The application upgrades the common database schema upgrade as well as data convention, this time how to implement the blue-green deployment? Here we use SQL PAAs on Azure as an example to illustrate the entire implementation

As mentioned above, the blue-green deployment usually refers to the same system of two parallel and completely independent production environment, accept the real user traffic environment is blue stack. Another environment is the green stack. Usually the green stack carries the latest version of the system, after the test passes the blue stack flow to the green stack, the green stack will become a new production blue stack after stable operation. The original blue stack was destroyed to achieve cost savings.

Let's look at the most common release process:

1. The same green stack that triggers the CD's task creation and production environment infrastructure (staging)
2. The task that triggers the CD deploys a new version of the application on the green stack
3. The task that triggers the CD is automatically tested on the green stack.
4. The task that triggers the CD smoothly switches the traffic from the blue stack to the green stack, and the green stack becomes the new blue stack
5. The green stack (formerly Blue Stack staging) is destroyed when the new blue stack runs stably

The entire process is as follows:

This solution, while meeting the 0 outage requirements, has the following problems

1. A new version of the application deployment when the database upgrade is from version 0 to the latest version, the above STEP3 test does not overwrite the production environment database version to the latest version of the path test, so that the new version in the production environment to run smoothly is a hidden problem

2. Similarly, the STEP3 test is based on a clean, empty database that does not test new versions on real or real-world data.

For the above questions, let's look at the second common release process

1. The same green stack that triggers the CD's task creation and production environment infrastructure (staging)

The environment does not contain a database

1. The task that triggers the CD points the green stack application to the production environment database and performs the required schema upgrade and other transactions
2. The task that triggers the CD deploys a new version of the application on the green stack
3. The task that triggers the CD is automatically tested on the green stack.
4. The task that triggers the CD smoothly switches the traffic from the blue stack to the green stack, and the green stack becomes the new blue stack
5. The green stack (formerly Blue Stack staging) is destroyed when the new blue stack runs stably

The entire process is as shown.

This scenario has the following issues

1. While testing is based on real data, there are risks of direct testing on production environments that lead to downtime

2. The released rollback can only be rolled back to the database backup point before the Step2 node, and the transaction data STEP2 until the rollback is not preserved

Okay, let's take a look at the third common release process

1. The same green stack that triggers the CD's task creation and production environment infrastructure (staging)

2. Trigger CD task on green stack data import to the latest backup of the production environment database

3. The task that triggers the CD deploys a new version of the application on the green stack

4. The task that triggers the CD is automatically tested on the green stack.

5. The task that triggers the CD points the green-stack database to the production database and performs the required schema upgrade and other transactions

6. The task that triggers the CD smoothly switches the traffic from the blue stack to the green stack, and the green stack becomes the new blue stack

7. The green stack (formerly Blue Stack staging) is destroyed when the new blue stack runs stably

The entire process is as shown.

This solution still has the following problems

1. Although there is no longer a risk of polluting real-world data, the transaction data for the corresponding time period will still be lost when the release is rolled back

2. Once a rollback occurs, the business cannot meet the needs of 0 downtime

Summarizing the processes and known issues of the three blue-green deployments above, you can conclude that the key requirements for a blue-green deployment are:

• App Release 0 outage
• Real Data testing
• No loss of transactional data
• Apply rollback 0 Downtime

Let's take an example of an azure SQL PAAs system and see how we can meet the requirements to solve the problems of the above three scenarios

1. The same green stack that triggers the CD's task creation and production environment infrastructure (staging)

2. Trigger CD task on green stack data import to the latest backup of the production environment database

3. Enable data sync from the blue stack database to the green stack database Azure SQL PAAs to replicate the production database real-time re to the green stack

4. The task that triggers the CD deploys a new version of the application on the green stack

5. The task that triggers the CD is automatically tested on the green stack.

6. The task that triggers the CD smoothly switches the traffic from the blue stack to the green stack, and the green stack becomes the new blue stack

7. Enable the Data sync feature of Azure Sql PAAs from the new blue stack database to the green stack database

8. The green stack (formerly Blue Stack staging) is destroyed when the new blue stack runs stably

The entire process is as shown.

You can see that after STEP3 joins the data sync function, the test applied is in the non-production environment but with the production environment data is real-time synchronization of the real data, there is no test path coverage is not the problem of the production environment will lead to the risk of downtime. At the same time, after STEP7 joins the data sync function in another direction, any transaction data that occurs on the new blue stack by the end user is written back to the original blue stack. Once you need to roll back, it is no longer necessary to take the time to create a new database and import the backup, only the CD task to switch traffic from the new blue stack to the original blue stack, rollback can also achieve zero downtime.

Then let's look at how to configure data sync to achieve the above functionality (the principle of data sync can be consulted Docs.microsoft.com/en-us/azure/sql-database/sql-database-sync-data)

1. Create 2 Azure SQL PaaS First, one of the production environment's database contains the real data, the other one we will use the empty database to show the function of data sync

Demotest1 is the production library blue stack

Stagingdb is the green stack

2. Enable Sync to other databases functions in Demotest1

Demotest1 is the hub for data sync, which synchronizes data from the hub to the member database every 300 seconds stagingdb

3. Configure the Data Sync Group's member database Stagingdb

4. Next, configure the tables and columns that need to be synchronized to the green stack, where we select all the tables and columns

5. Let's look at the production database and now use the Query Editor feature in Azure Portal to directly query the database

6. Then query the green stack database, when the green stack only the database metadata

7. After 5 minutes, make a query again, you can see the data began to synchronize gradually to the green stack database. New app to start testing

· 8. Smooth migration of production environment traffic after testing is complete

9. You need to delete the original data Sync group and configure the data sync from the new production database (hub) to the old production database (member) for rollback switching

The following points need to be noted throughout the process:

1, when configuring data sync, conflict resolution must be based on the hub database that hosts the production environment to avoid sequence conflicts

2, in the blue-green deployment process, there is no need to configure data sync for all tables, considering that the member database is the most recent backup in the production database as source, systems like audit tail do not need to configure sync, except for security audit requirements.

3, in the configuration of the new production database to the old production database of data sync, the newly upgraded schema can not be directly sync back to the old production library, the complex schema upgrade scenario is recommended to use data sync, need to adopt support table Third-party software for mapping and transformation rule.

4, in addition, the data sync has some restrictions docs.microsoft.com/en-us/azure/sql-database/sql-database-sync-data, contains not applicable to the data Sync's data tables and columns database also does not recommend data sync for blue-green deployments