Deployment and Testing Strategy

Photo by David Travis on Unsplash
+-------------------------+-------------+------------------------+
| Deployment Strategy | Instance | Blue/Green, Rolling |
+=========================+=============+========================+
| Testing Strategy | User | Canary, A/B, Shadow |
+-------------------------+-------------+------------------------+

Deployment Strategy

  • 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
  • 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

  • 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.

  • 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
  • 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

Enthusiastic about cloud technology, data, clean code, Flutter, and Agile

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store