Examkin

Question

Difficulty: MediumRelease Management and Deployment Strategies (Blue-Green, Canary, Rolling)

An enterprise online reservation platform hosts its core booking microservice on Google Kubernetes Engine (GKE) backed by a Cloud SQL for PostgreSQL database. The platform team needs to execute a zero-downtime release featuring a major application update and a breaking database schema migration. What is the correct sequence of steps to safely execute this blue-green deployment without service disruption or data corruption?

  1. 1Execute an 'expand' database migration script to add new columns and tables while retaining all existing columns, constraints, and triggers.
  2. 2Deploy the new application pods (Green deployment) into the GKE cluster alongside the active (Blue) deployment while keeping 100% of ingress traffic directed to Blue.
  3. 3Update the GKE Gateway API HTTPRoute resource to shift 100% of live user traffic from the Blue deployment to the Green deployment.
  4. 4Execute a 'contract' database migration script to drop obsolete columns and legacy schema objects once Green stability is verified and Blue pods are decommissioned.

Answer

The correct sequence of steps is: 1) Execute the expand database migration to add new schema elements without breaking existing logic, 2) Deploy the Green microservice revision to GKE while keeping live traffic on Blue, 3) Update the HTTPRoute resource to shift traffic to Green, and 4) Execute the contract database migration to clean up legacy schema objects once Green stability is confirmed.
Executing a zero-downtime release with breaking database schema changes requires decoupled, backwards-compatible deployment phases. First, the database schema must be expanded by adding new columns as nullable or with defaults, allowing the running Blue version to operate uninterrupted. Next, the Green workload is deployed in parallel on GKE to verify its readiness. Traffic is then shifted instantly using GKE routing controls. Finally, after validating the Green release and draining Blue connections, a contract migration safely removes the legacy database columns.

Step-by-Step Solution

1
Expand Database Schema
Database supports both old and new application versions simultaneously.
Prevents database exceptions in the currently active Blue deployment when new database structures are introduced.
2
Deploy Green Environment
Green application version is running and healthy in GKE, isolated from user traffic.
Allows verification of new container pods without exposing live end-users to unverified pods.
3
Shift Traffic to Green
100% of production traffic is processed by the new Green application release.
Executes a zero-downtime cutover at the networking layer.
4
Contract Database Schema
Legacy schema columns and unused database objects are safely purged.
Completes the schema evolution lifecycle once rollback to the Blue version is no longer required.

Key Concept

Expand-Contract Database Migration Pattern in Blue-Green Deployments
Rate this question

Topics

Release Management and Deployment Strategies (Blue-Green, Canary, Rolling)