Deployment and Testing Strategy

4 min readApr 5, 2021

+-------------------------+-------------+------------------------+
| Deployment Strategy     | Instance    | Blue/Green, Rolling    |
+=========================+=============+========================+
| Testing Strategy        | User        | Canary, A/B, Shadow    |
+-------------------------+-------------+------------------------+

Deployment Strategy

1. Blue/Green pattern

Having two identical environments: V1 and V2, where both V1 and V2 are running, but only V1 has all traffic while V2 is in testing.
V2 is released alongside V1, and traffic is routed to V2 after testing
The load balancer will direct traffic between two environment
Zero downtime and instant rollback
Cost is high to maintain two environments and might lose use session during routing changes between versions.

Applying the Blue/Green deployment strategy is fairly easy with the Google App Engine platform, where it was built in with the “Split Traffic” feature. If you are not very familiar with App Engine, I have this article demo deploying a Flutter WebApp on App Engine.

First, you need a minimum of two versions of the application in App Engine.

Click the “Split Traffic” button to enter the config page:

Now watching traffic being diverged with either version 1 or 2 of your WebApp

On the other hand, if you are using Google Kubernetes Engine, setting up Blue/Green is also easy:

First, deploy the current version of the application on Kubernetes cluster

kubectl apply -f bluegreen/old-version.yaml

Test the deployed application
Deploy a new version alongside the current version

kubectl apply -f bluegreen/new-version.yaml

Switch the traffic from app:old to app:new at load balancer layer
Clean up the deployment and resources

kubectl delete -f bluegreen/ --ignore-not-found

2. Rolling update pattern

Slowly replacing the current running V1 instance with the new version, until V1 is completely moved after V2 has passed a health check.
There is always an N+1 instance running at any given time because the actual deployment occurs over a period of time.
Because V1 and V2 co-exist, users might be routed to both versions, so having V2 backward compatible is very important.
One complete environment at any given time.
Zero downtime and low risk, because Kubernetes ensures at least two pods server the traffic at any time and one pod is replaced at a time.
This is the default deployment strategy with Kubernetes

Testing Strategy

3. Canary pattern

V2 is release alongside the Production version V1, but only to a small group of users, followed by a full rollout.
Use load balancer to split a percentage of traffic from Prod to Canary
Able to test live production traffic with zero downtime and fast rollback

Similar to Blue/Green deployment strategy, if you are using Google App Engine, you can try this testing strategy using the “Split Traffic” feature, instead of switching traffic all at once, you can diverge a small percentage from V1 to V2.

4. A/B pattern

Both V1 and V2 are released to users.
Help businesses to make decisions with collective data. It is beneficial when there are multiple implementation options for one set of features to decide which one is more effective.
Complex validation metric

5. Shadow pattern

Both V1 and V2 are released to users.
V2 will receive real traffic, but features are hidden from users
It won’t impact users on V2 as their requests are the same