Blue-Green Deployment for MIG
This guide explains how to configure and execute deployments for Google Cloud Managed Instance Groups using the Blue-Green strategy in Harness.
Prerequisites for Blue-Green deployment
Before setting up your Blue-Green deployment, ensure you have the following GCP resources already provisioned:
- Backend Service: A GCP backend service configured with appropriate health checks
- Instance Group: At least one Managed Instance Group must be pre-configured with your MIG service already running
- Cloud Service Mesh: HTTPRoute or GRPCRoute resources configured for traffic management. The route must be configured with the backend service as a destination
These resources form the foundation of your Blue-Green deployment infrastructure. Harness will manage the deployment lifecycle, but these core GCP resources must exist beforehand.
Select deployment strategy
After configuring your service, environment, and infrastructure, navigate to the Execution tab and select the Blue-Green execution strategy. Harness automatically adds a pre-configured step group containing all the necessary deployment steps. This automated setup eliminates manual configuration and ensures best practices for zero-downtime deployments with instant rollback.
Blue-Green deployment step group
When you select the Blue-Green strategy, Harness automatically configures the Google MIG Blue Green Deploy step group with four essential steps that orchestrate the entire deployment lifecycle:
- Download Manifests - Downloads your MIG configuration files from the specified manifest store
- Google MIG Blue Green Deploy - Creates or updates the MIG and orchestrates the Blue-Green deployment
- Google MIG Steady State - Verifies that all instances reach a healthy, stable state
- Google MIG Traffic Shift - Manages traffic distribution between stable and stage environments using Cloud Service Mesh
These steps execute sequentially, ensuring each phase completes successfully before proceeding to the next.
How Blue-Green deployment works
This section assumes you have already configured your backend service, at least one Managed Instance Group with your service running, and Cloud Service Mesh (HTTPRoute or GRPCRoute) in GCP as outlined in the Prerequisites section.
Blue-Green deployment maintains two identical environments that alternate roles with each deployment, ensuring zero downtime and instant rollback capabilities. Harness supports two deployment scenarios based on your existing infrastructure.
Scenario 1: Starting with One Backend Service and MIG
This is the most common starting point: you have one backend service and one MIG, with your service already running. Harness sets up the Blue-Green infrastructure on the first deployment, and subsequent deployments follow an alternating pattern.
Prerequisites:
- One backend service with appropriate health checks configured
- One MIG with your service running on it
- Cloud Service Mesh route (HTTPRoute or GRPCRoute) configured
What you provide in the Blue-Green Deploy step:
- Backend service path (e.g.,
projects/my-project/regions/us-central1/backendServices/ABC) - MIG name (e.g.,
my-app-mig)
First Deployment
During the first deployment, Harness creates the Blue-Green infrastructure.
Step 1: Blue-Green Deploy
Harness performs the following operations:
- Clones the backend service and appends
-1suffix (e.g.,ABCbecomesABC-1) - Creates a second MIG based on your configuration (
ABC-1) - Labels the initial service/MIG as
harness-blue-green-version: stable(primary/production) - Labels the newly created service/MIG as
harness-blue-green-version: stage(secondary/deployment target)
This step only creates the infrastructure and adds labels. No deployment or traffic shifting occurs in this step.
Step 2: Steady State Check
This step checks the steady state of the MIG specified in its configuration. You should configure this step to check the newly created MIG (the one labeled stage), since it's not currently handling traffic. Harness verifies that the specified MIG has reached a stable, healthy state before proceeding with traffic shifting.
Step 3: Traffic Shift
Harness shifts traffic from stable to stage based on configured weights (e.g., 0% → 20% → 50% → 100%). Once the stage service reaches 100% traffic weight, the labels automatically swap:
- Stage service becomes the new
stable(now serving production traffic) - Stable service becomes the new
stage(ready for next deployment)
After the first deployment, you have two backend services and two MIGs that will alternate between stable and stage roles for all future deployments.
Subsequent Deployments
After the first deployment completes, all subsequent deployments follow this pattern. Harness uses the existing labels to identify which environment is stable (production) and which is stage (deployment target).
Step 1: Blue-Green Deploy
Harness does NOT create any new services or MIGs. Instead, it:
- Identifies which service has the
stablelabel (primary/production) - Identifies which service has the
stagelabel (secondary/deployment target) - Deploys the new version only to the service labeled as
stage. - Production traffic continues flowing to the
stableservice (zero downtime)
Step 2: Steady State Check
This step checks the steady state of the MIG specified in its configuration. You should configure this step to check the secondary MIG (the one labeled as stage) since it contains the new deployment and is not currently handling production traffic.
Step 3: Traffic Shift
Harness shifts traffic from the primary (stable) to the secondary (stage) based on configured weights. Once the secondary reaches 100% traffic, the labels swap:
- Secondary becomes the new
stable(now primary/production) - Primary becomes the new
stage(now secondary/deployment target)
This pattern repeats for every subsequent deployment, with services alternating roles indefinitely.
Scenario 2: Two Existing Services
If you already have two backend services and two MIGs set up, you can configure them directly in the Blue-Green Deploy step. However, you must manually add labels to the MIGs before running the deployment.
Prerequisites:
- Two backend services already exist (e.g.,
ABCandABC-1) - Two MIGs already exist with services running
- Labels manually configured on both MIGs (see below)
Adding Labels Manually
Before running the Blue-Green deployment, you must add labels to your MIGs in GCP. Navigate to your MIG's All Instances Configuration section and add the following labels:
- Add
harness-blue-green-version: stableto the MIG you want as your primary/production environment - Add
harness-blue-green-version: stageto the MIG you want as your secondary/deployment target
What you provide in the Blue-Green Deploy step:
- Blue Environment: Backend service path and MIG name for your stable service
- Green Environment: Backend service path and MIG name for your stage service
Step 1: Blue-Green Deploy
Harness does NOT create new services, MIGs, or labels. Instead, it:
- Recognizes both services already exist with labels configured
- Identifies the stable-labeled MIG as primary and the stage-labeled MIG as secondary
- Deploys the new version to the stage-labeled MIG (green environment)
Step 2: Steady State Check
This step checks the steady state of the MIG specified in its configuration. You should configure this step to check the green environment MIG (the one labeled stage), since it's not currently handling traffic.
Step 3: Traffic Shift
Harness shifts traffic from stable (blue) to stage (green) based on configured weights. Once the stage reaches 100% traffic, labels are swapped, and subsequent deployments follow the same pattern as in Scenario 1.
Deployment steps overview
The Blue-Green deployment workflow consists of four coordinated steps that work together to achieve zero-downtime deployments. Each step performs a specific function in the deployment lifecycle, from downloading configurations to shifting production traffic. Understanding these steps helps you troubleshoot deployments and customize the workflow for your exact requirements.
1. Download Manifests
This step downloads all manifest files specified in your service configuration and makes them available for subsequent deployment steps. Harness fetches the files from your configured manifest store (Harness File Store, Git, or other supported sources), validates their JSON structure, and stages them for use by the deployment steps.
Step parameters:
- Name: Display name for the step (default: Download Manifests)
- Timeout: Maximum time allowed for downloading manifests (default: 10m)
YAML Example
- step:
type: DownloadManifests
name: DownloadManifests
identifier: DownloadManifests
spec: {}
failureStrategies: []
2. Google MIG Blue Green Deploy
This step orchestrates the Blue-Green deployment and behaves differently based on your deployment scenario:
- Scenario 1 (Starting with one service): On the first deployment, creates a second backend service (with
-1suffix) and MIG, then labels both environments (stableandstage). On subsequent deployments, identifies existing labels and deploys only to thestagelabeled service without creating new resources - Scenario 2 (Two existing services with manual labels): Recognizes both services already exist with labels you've manually configured. Does not create services or add labels—deploys to the stage-labeled MIG (green environment)
The step handles instance template creation or updates, MIG updates, backend service configuration, and environment labeling based on the scenario.
Important: This step only deploys the infrastructure and does not shift production traffic. Traffic shifting happens exclusively in the Google MIG Traffic Shift step, giving you control over when to expose the new version to users.
Step parameters:
Blue Environment (First Environment):
Backend Service: This field specifies the full GCP resource path to your backend service for the first environment. The format should be: projects/PROJECT_ID/regions/REGION/backendServices/SERVICE_NAME. You should ensure the backend service exists and is correctly configured with health checks before deployment.
Enter MIG Name: This field specifies the name of the Managed Instance Group for your first environment (e.g., my-app-mig). This should be a simple name, not a full resource path. You should choose a meaningful name that reflects your application or service.
Green Environment (Second Environment) (Optional for first deployment):
Backend Service: This field specifies the full GCP resource path to your backend service for the second environment. The format should be: projects/PROJECT_ID/regions/REGION/backendServices/SERVICE_NAME.
This field behavior depends on your deployment scenario:
- Scenario 1 (First deployment): Optional. If left empty, Harness automatically creates a second backend service by cloning your first environment configuration with a -1 suffix. On subsequent deployments, this is automatically populated based on existing labeled services
- Scenario 2 (Two existing services): Provide the path to your second existing backend service. You must manually add the
stagelabel to the MIG before deployment
Both backend services work together to enable zero-downtime Blue-Green deployments with instant rollback capability.
Enter MIG Name: This field specifies the name of the Managed Instance Group for your second environment.
This field behavior depends on your deployment scenario:
- Scenario 1 (First deployment): Optional. If not provided, Harness creates it automatically by appending -1 to your first MIG name (e.g., my-app-mig-1). On subsequent deployments, this is automatically identified based on existing labeled MIGs
- Scenario 2 (Two existing MIGs): Provide the name of your second existing MIG. You must manually add the
stagelabel to this MIG before deployment
This second MIG forms the other half of your Blue-Green setup, alternating with the first MIG between stable and stage roles.
Type: This field determines how traffic is shifted between stable and stage environments. Currently, only the CSM (Cloud Service Mesh) option is supported, which uses HTTPRoute or GRPCRoute resources for advanced, granular traffic control, including weighted routing, header-based routing, and service-to-service communication. CSM is ideal for microservice architectures and service-mesh deployments.
Route Type: This field specifies the Cloud Service Mesh route resource type that controls traffic distribution. The HTTPRoute option is for HTTP and HTTPS traffic and supports path matching, header matching, and query parameter routing. The GRPCRoute option is for gRPC services with method-level routing. This field is only applicable when the Type field is set to CSM. The route resource must exist in your GCP project and be configured appropriately to reference both backend services before deployment.
Enter Route: This field specifies the full GCP resource path to your Cloud Service Mesh route resource. The format should be: projects/PROJECT_ID/locations/global/httpRoutes/ROUTE_NAME (for HTTPRoute) or projects/PROJECT_ID/locations/global/grpcRoutes/ROUTE_NAME (for GRPCRoute). This route controls how traffic is distributed between your stable and stage environments by adjusting weights. Harness updates this route during traffic shifting to gradually move traffic from the current stable version to the newly deployed stage version.
Target Size: This field specifies the desired number of instances to maintain in the newly deployed MIG. You can select a specific number to control deployment size (e.g., 3, 5, 10). This allows you to deploy with a particular capacity requirement. This is useful when you want to validate a new version with fewer instances before scaling up, or when you need to adjust capacity for specific deployments.
Container Configuration:
Container Registry: This field specifies the Harness connector that provides authentication to your container registry (e.g., Docker Hub, GCR, GAR, ECR). This connector pulls the deployment plugin image, which executes the deployment operations. The plugin runs in a containerized environment and needs access to pull its image from the registry. You should select a connector with appropriate read permissions to the registry where your plugin images are stored. This is part of Harness's containerized step execution model.
Image: This field specifies the full path to the deployment plugin container image used to execute this deployment step. This image contains the deployment logic and tools needed to interact with GCP APIs, create and update MIGs, configure backend services, and manage Cloud Service Mesh routes. Use the official Harness image: harness/google-mig-bluegreen-deploy:0.0.1-linux-amd64 for Blue-Green deployments.
Harness supports two deployment scenarios:
Scenario 1 - Starting with one backend service and MIG: Provide only the blue environment (backend service + MIG where your service is running). On the first deployment, Harness automatically clones the backend service (adds -1 suffix) and creates a second MIG with appropriate labels (stable and stage). Subsequent deployments use these labels to identify environments—no new services are created.
Scenario 2 - Two existing services with manual labels: If you already have two backend services and two MIGs, provide both blue and green environments. You must manually add labels (stable to blue MIG, stage to green MIG) in GCP before running the deployment. Harness does not create services or add labels in this scenario.
YAML Example
- step:
type: GoogleMigBlueGreenDeploy
name: BlueGreen_Deploy
identifier: BlueGreen_Deploy
spec:
blueEnvironment:
backendService: projects/PROJECT_ID/locations/global/backendServices/BACKEND_SERVICE_NAME
mig: MIG_NAME
trafficConfig:
type: CSM
spec:
type: GRPCRoute
route: projects/PROJECT_ID/locations/global/grpcRoutes/ROUTE_NAME
targetSize: 1
connectorRef: GCP_CONNECTOR_ID
image: harness/google-mig-bluegreen-deploy:0.0.1-linux-amd64
imagePullPolicy: Always
resources:
limits:
memory: 512Mi
cpu: 0.5
outputVariables: []
timeout: 10m
3. Google MIG Steady State
This step verifies that the newly deployed MIG (the one labeled as stage or secondary service) has reached a stable, healthy state before proceeding with traffic shifting. Harness checks that the MIG status is stable and that all instances use the correct instance template version.
The step only monitors the secondary (stage) service, not the primary (stable) service, since the primary is already running and serving production traffic. The step fails if the secondary MIG doesn't achieve steady state within the configured timeout. This validation prevents premature traffic shifting to an unhealthy environment and is critical for zero-downtime deployments.
Step parameters:
MIG Name: Specify the name of the Managed Instance Group that Harness should monitor for steady state. This should be the secondary (stage-labeled) MIG where the new version was just deployed. Harness continuously polls this MIG's status to verify that the status is stable and all instances are using the expected instance template. This ensures your new deployment is fully ready before allowing traffic to reach it.
Use this expression to fetch the MIG name from the Blue-Green Deploy step:
<+pipeline.stages.BlueGreen_Traffic_shift.spec.execution.steps.blueGreenDeployment.steps.GoogleMigBlueGreenDeploy.GoogleMigBlueGreenDeployOutcome.rollbackData.deploymentMetadata.stage.mig>
Instance Template: Specify the instance template name that Harness should verify. Harness checks that the MIG is using this specific template version. Note that during a rolling update, a MIG can temporarily have multiple templates, which is expected behavior. Once the rolling update completes, the MIG will be fully updated with the latest applied template. The template name typically includes version information or timestamps (e.g., my-app-template-v2-20260120).
Use this expression to fetch the instance template name from the Blue-Green Deploy step:
<+steps.blueGreenDeployment.steps.GoogleMigBlueGreenDeploy.GoogleMigBlueGreenDeployOutcome.rollbackData.deploymentMetadata.stage.instanceTemplate>
Polling Interval (optional): Specify how frequently Harness checks the MIG status during steady state verification (e.g., 30s, 1m, 2m). Shorter intervals (10-30 seconds) provide faster detection of steady state and quicker deployments but generate more API calls to GCP. Longer intervals (1-2 minutes) reduce API load but slow down deployment feedback. The default is typically 30 seconds. Balance between deployment speed and API rate limits based on your requirements.
Container Configuration:
Container Registry: Harness connector for authenticating to your container registry (Docker Hub, GCR, GAR, ECR). This connector pulls the deployment plugin image that executes the deployment operations.
Image: Full path to the deployment plugin container image for this step. Use the official Harness image: harness/google-mig-steady-state:0.0.1-linux-amd64 for steady state verification.
Timeout: The default timeout is 10 minutes. If your MIG requires more time to reach steady state, increase this value accordingly.
YAML Example
- step:
identifier: mig_steady_state_check
type: GoogleMigSteadyState
name: Steady_State_Check
spec:
mig: <+pipeline.stages.Deploy.spec.execution.steps.STEP_GROUP_ID.steps.DEPLOY_STEP_ID.GoogleMigBlueGreenDeployOutcome.stageMig>
instanceTemplate: <+pipeline.stages.Deploy.spec.execution.steps.STEP_GROUP_ID.steps.DEPLOY_STEP_ID.GoogleMigBlueGreenDeployOutcome.rollbackData.deploymentMetadata.stage.instanceTemplate>
connectorRef: GCP_CONNECTOR_ID
image: harness/google-mig-steady-state:0.0.1-linux-amd64
imagePullPolicy: Always
resources:
limits:
memory: 512Mi
cpu: 0.5
outputVariables: []
4. Google MIG Traffic Shift
This step shifts production traffic from the primary (stable) service to the secondary (stage) service. It enables safe, controlled rollouts by allowing you to move traffic incrementally (e.g., 10% → 25% → 50% → 100%) while monitoring application metrics, error rates, and performance.
Traffic flows from the primary (currently serving production) to the secondary (newly deployed). Once the secondary service reaches 100% traffic weight, Harness automatically swaps the labels—the secondary becomes the new stable (primary) and the previous primary becomes the new stage (secondary).
If issues arise at any traffic percentage, you can halt the shift or roll back. This step supports multiple traffic shift steps in sequence for phased rollouts, making it the key step that enables safe Blue-Green deployments in production.
Step parameters:
Type: This field specifies the mechanism used to control traffic distribution between your stable and stage environments. Currently, only CSM (Cloud Service Mesh) is supported, which adjusts weights on your HTTPRoute or GRPCRoute resources, providing fine-grained control ideal for service-to-service (east-west) traffic and microservice architectures. CSM supports advanced features like header-based routing and A/B testing.
Route Type: Specify the type of Cloud Service Mesh route resource that Harness will update with new traffic weights. The HTTPRoute option works for HTTP and HTTPS services, allowing path-based and header-based routing in addition to weighted traffic distribution. The GRPCRoute option specifically serves gRPC services with support for method-level routing. This field only applies when you set the Type field to CSM. The route must be properly configured with both backend services (stable and stage) as destinations before traffic shifting. Harness modifies the weight values while preserving other route configurations.
Enter Route: Specify the full GCP resource path to the Cloud Service Mesh route that controls traffic flow to your application (format: projects/PROJECT_ID/locations/global/httpRoutes/ROUTE_NAME or projects/PROJECT_ID/locations/global/grpcRoutes/ROUTE_NAME). Harness updates the weights in this route's rule configuration to shift traffic between stable and stage environments. The route must already exist, be properly configured with both backend services as weighted destinations, and have appropriate mesh associations. Verify the route path is correct before deployment to avoid traffic disruption.
Destinations: Define the traffic distribution percentages between your environments by adding multiple destinations with weight values that total 100%. For destinations, you can provide the full backend service path (e.g., projects/PROJECT_ID/regions/REGION/backendServices/SERVICE_NAME) or use placeholders like stable (primary) and stage (secondary).
For example, setting Stable=90 and Stage=10 sends 90% of requests to the primary environment and 10% to the secondary. Use gradual shifts across multiple traffic shift steps (e.g., Step 1: 80/20, Step 2: 50/50, Step 3: 0/100) to safely validate new versions under increasing load.
When the secondary (stage) reaches 100% traffic weight, Harness automatically swaps the labels—the secondary becomes the new primary (stable) and serves production traffic going forward. Monitor application metrics between shifts to catch issues early.
Container Configuration:
Container Registry: Harness connector for authenticating to your container registry (Docker Hub, GCR, GAR, ECR). This connector pulls the deployment plugin image that executes the deployment operations.
Image: Full path to the deployment plugin container image for this step. Use the official Harness image: harness/google-mig-traffic-shift:0.0.1-linux-amd64 for traffic shifting operations.
YAML Example
- step:
identifier: traffic_shift_100
type: GoogleMigTrafficShift
name: Traffic_Shift_100
spec:
trafficConfig:
type: CSM
spec:
type: GRPCRoute
route: projects/PROJECT_ID/locations/global/grpcRoutes/ROUTE_NAME
destinations:
- destination: stable
weight: 0
- destination: stage
weight: 100
connectorRef: GCP_CONNECTOR_ID
image: harness/google-mig-traffic-shift:0.0.1-linux-amd64
imagePullPolicy: Always
resources:
limits:
memory: 512Mi
cpu: 0.5
outputVariables: []
Gradual traffic shifting
For safe production rollouts, you can add multiple Google MIG Traffic Shift steps with increasing traffic percentages:
Example phased rollout:
- Traffic Shift 1: 10% to stage, 90% to stable (validation with minimal risk)
- Traffic Shift 2: 50% to stage, 50% to stable (balanced load testing)
- Traffic Shift 3: 100% to stage, 0% to stable (full cutover)
Between each shift, you can:
- Monitor application metrics and error rates
- Run verification steps or manual approvals
- Add custom scripts or API calls for validation
- Roll back if issues are detected
YAML example with gradual shift:
- step:
name: Traffic Shift - 10%
type: GoogleMigTrafficShift
spec:
destinations:
- environment: stable
weight: 90
- environment: stage
weight: 10
- step:
name: Approval - Validate 10%
type: HarnessApproval
spec:
approvalMessage: Validate metrics before proceeding to 50%
- step:
name: Traffic Shift - 50%
type: GoogleMigTrafficShift
spec:
destinations:
- environment: stable
weight: 50
- environment: stage
weight: 50
- step:
name: Traffic Shift - 100%
type: GoogleMigTrafficShift
spec:
destinations:
- environment: stable
weight: 0
- environment: stage
weight: 100
Rollback Step
One of the most powerful features of Blue-Green deployment is instant rollback capability. With Harness, you're never more than 30 seconds away from a working state, providing a critical safety net for production deployments.
When to rollback
Rollback is triggered automatically when a deployment step fails. This can occur due to:
- Failed health checks for the new instances
- Deployment step failures or timeouts
- Infrastructure issues preventing successful deployment
- Any critical errors during the deployment process
The advantage of Blue-Green deployment is that your previous version remains running and ready to receive traffic again immediately.
How rollback works
Harness provides the GoogleMigBlueGreenRollback step that you configure in your pipeline's rollback section. This step triggers automatically when any deployment step fails. The step uses the rollback data captured during the Blue Green Deploy step, which includes a complete snapshot of your previous configuration state.
Rollback execution process
When you execute a rollback, Harness performs the following operations:
Phase 1: Retrieve rollback data
Harness retrieves the deployment state captured during the Blue Green Deploy step, including the previous MIG configuration, backend service settings, autoscaler policy, and traffic routing configuration.
Phase 2: Restore traffic routing
Harness immediately updates the HTTPRoute or GRPCRoute to shift 100% of traffic back to the stable environment (the version that was working before). This traffic shift happens in seconds, quickly routing users away from the problematic version.
Phase 3: Restore environment configuration
Harness restores the stage MIG to the previous instance template version, updates the autoscaler restores The configuration returns to its original settings and reverts the MIG labels that identify stable versus stage environments. Optionally, you can configure the step to delete any newly created resources by setting the deleteNewResources parameter.
Configuring rollback
Configure the GoogleMigBlueGreenRollback step in the Rollback Steps section of your pipeline. The step triggers automatically when any deployment step fails.
Configuration options:
- deleteNewResources: Set to
trueto remove any resources created during the failed deployment - preserveCapacity: Set to
trueto maintain the stage environment capacity for troubleshooting, orfalseto scale it down and save costs
Container Configuration:
- Container Registry: Harness connector for authenticating to your container registry
- Image: Use the official Harness image:
harness/google-mig-bluegreen-rollback:0.0.1-linux-amd64for rollback operations
YAML example:
rollbackSteps:
- step:
type: GoogleMigBlueGreenRollback
name: Rollback on Failure
identifier: rollback_on_failure
spec:
deleteNewResources: true
preserveCapacity: false
connectorRef: GCP_CONNECTOR_ID
image: harness/google-mig-bluegreen-rollback:0.0.1-linux-amd64
imagePullPolicy: Always
resources:
limits:
memory: 512Mi
cpu: 0.5
timeout: 15m
Complete pipeline examples
Basic Blue-Green deployment pipeline
This example shows a complete Blue-Green deployment pipeline with automatic rollback configuration. The pipeline deploys a new version to the stage environment, verifies it reaches steady state, and shifts 100% traffic in a single step.
Complete Pipeline YAML Example
pipeline:
projectIdentifier: PROJECT_ID
orgIdentifier: ORG_ID
tags: {}
stages:
- stage:
name: Deploy
identifier: Deploy
description: Blue-Green MIG Deployment
type: Deployment
spec:
deploymentType: GoogleManagedInstanceGroup
service:
serviceRef: MIG_SERVICE_REF
serviceInputs:
serviceDefinition:
type: GoogleManagedInstanceGroup
spec:
artifacts:
primary:
primaryArtifactRef: <+input>
sources: <+input>
environment:
environmentRef: ENVIRONMENT_REF
deployToAll: false
infrastructureDefinitions:
- identifier: INFRA_ID
execution:
steps:
- stepGroup:
steps:
- step:
type: DownloadManifests
name: DownloadManifests
identifier: DownloadManifests
spec: {}
failureStrategies: []
- step:
type: GoogleMigBlueGreenDeploy
name: BlueGreen_Deploy
identifier: BlueGreen_Deploy
spec:
blueEnvironment:
backendService: projects/PROJECT_ID/locations/global/backendServices/BACKEND_SERVICE_NAME
mig: MIG_NAME
trafficConfig:
type: CSM
spec:
type: GRPCRoute
route: projects/PROJECT_ID/locations/global/grpcRoutes/ROUTE_NAME
targetSize: 1
connectorRef: GCP_CONNECTOR_ID
image: harness/google-mig-bluegreen-deploy:0.0.1-linux-amd64
imagePullPolicy: Always
resources:
limits:
memory: 512Mi
cpu: 0.5
outputVariables: []
timeout: 10m
- step:
identifier: mig_steady_state_check
type: GoogleMigSteadyState
name: Steady_State_Check
spec:
mig: <+pipeline.stages.Deploy.spec.execution.steps.Google_MIG_Step_Group.steps.BlueGreen_Deploy.GoogleMigBlueGreenDeployOutcome.stageMig>
instanceTemplate: <+pipeline.stages.Deploy.spec.execution.steps.Google_MIG_Step_Group.steps.BlueGreen_Deploy.GoogleMigBlueGreenDeployOutcome.rollbackData.deploymentMetadata.stage.instanceTemplate>
connectorRef: GCP_CONNECTOR_ID
image: harness/google-mig-steady-state:0.0.1-linux-amd64
imagePullPolicy: Always
resources:
limits:
memory: 512Mi
cpu: 0.5
outputVariables: []
- step:
identifier: traffic_shift_100
type: GoogleMigTrafficShift
name: Traffic_Shift_100
spec:
trafficConfig:
type: CSM
spec:
type: GRPCRoute
route: projects/PROJECT_ID/locations/global/grpcRoutes/ROUTE_NAME
destinations:
- destination: stable
weight: 0
- destination: stage
weight: 100
connectorRef: GCP_CONNECTOR_ID
image: harness/google-mig-traffic-shift:0.0.1-linux-amd64
imagePullPolicy: Always
resources:
limits:
memory: 512Mi
cpu: 0.5
outputVariables: []
name: Google MIG Step Group
identifier: Google_MIG_Step_Group
stepGroupInfra:
type: KubernetesDirect
spec:
connectorRef: K8S_CONNECTOR_ID
namespace: NAMESPACE
serviceAccountName: SERVICE_ACCOUNT_NAME
automountServiceAccountToken: true
rollbackSteps:
- stepGroup:
name: Google Mig Rollback
identifier: Google_Mig_Rollback
steps:
- step:
type: GoogleMigBlueGreenRollback
name: GoogleMigBlueGreenRollback_1
identifier: GoogleMigBlueGreenRollback_1
spec:
connectorRef: GCP_CONNECTOR_ID
image: harness/google-mig-bluegreen-rollback:0.0.1-linux-amd64
timeout: 10m
stepGroupInfra:
type: KubernetesDirect
spec:
connectorRef: K8S_CONNECTOR_ID
namespace: NAMESPACE
serviceAccountName: SERVICE_ACCOUNT_NAME
automountServiceAccountToken: true
tags: {}
failureStrategies:
- onFailure:
errors:
- AllErrors
action:
type: StageRollback
delegateSelectors:
- DELEGATE_SELECTOR
identifier: PIPELINE_ID
name: Blue-Green MIG Deployment Pipeline
Gradual traffic shifting pipeline
This example demonstrates a phased rollout approach with gradual traffic shifting. The pipeline deploys to the stage environment and then gradually shifts traffic: 20% → 50% → 100%. This allows you to validate the new version at each traffic level before increasing exposure, making it ideal for production deployments that aim to minimize risk.
Complete Pipeline YAML Example for Gradual Traffic Shifting
pipeline:
projectIdentifier: PROJECT_ID
orgIdentifier: ORG_ID
tags: {}
stages:
- stage:
name: Deploy
identifier: Deploy
description: Gradual Traffic Shift (20% -> 50% -> 100%)
type: Deployment
spec:
deploymentType: GoogleManagedInstanceGroup
service:
serviceRef: MIG_SERVICE_REF
serviceInputs:
serviceDefinition:
type: GoogleManagedInstanceGroup
spec:
artifacts:
primary:
primaryArtifactRef: <+input>
sources: <+input>
environment:
environmentRef: ENVIRONMENT_REF
deployToAll: false
infrastructureDefinitions:
- identifier: INFRA_ID
execution:
steps:
- stepGroup:
steps:
- step:
type: DownloadManifests
name: DownloadManifests
identifier: DownloadManifests
spec: {}
failureStrategies: []
- step:
type: GoogleMigBlueGreenDeploy
name: BlueGreen_Deploy
identifier: BlueGreen_Deploy
spec:
blueEnvironment:
backendService: projects/PROJECT_ID/locations/global/backendServices/BACKEND_SERVICE_NAME
mig: MIG_NAME
trafficConfig:
type: CSM
spec:
type: GRPCRoute
route: projects/PROJECT_ID/locations/global/grpcRoutes/ROUTE_NAME
targetSize: 1
connectorRef: GCP_CONNECTOR_ID
image: harness/google-mig-bluegreen-deploy:0.0.1-linux-amd64
imagePullPolicy: Always
resources:
limits:
memory: 512Mi
cpu: 0.5
outputVariables: []
timeout: 10m
- step:
identifier: mig_steady_state_check
type: GoogleMigSteadyState
name: Steady_State_Check
spec:
mig: <+pipeline.stages.Deploy.spec.execution.steps.Google_MIG_Step_Group.steps.BlueGreen_Deploy.GoogleMigBlueGreenDeployOutcome.stageMig>
instanceTemplate: <+pipeline.stages.Deploy.spec.execution.steps.Google_MIG_Step_Group.steps.BlueGreen_Deploy.GoogleMigBlueGreenDeployOutcome.rollbackData.deploymentMetadata.stage.instanceTemplate>
connectorRef: GCP_CONNECTOR_ID
image: harness/google-mig-steady-state:0.0.1-linux-amd64
imagePullPolicy: Always
resources:
limits:
memory: 512Mi
cpu: 0.5
outputVariables: []
- step:
identifier: traffic_shift_20
type: GoogleMigTrafficShift
name: Traffic_Shift_20_Percent
spec:
trafficConfig:
type: CSM
spec:
type: GRPCRoute
route: projects/PROJECT_ID/locations/global/grpcRoutes/ROUTE_NAME
destinations:
- destination: stable
weight: 80
- destination: stage
weight: 20
connectorRef: GCP_CONNECTOR_ID
image: harness/google-mig-traffic-shift:0.0.1-linux-amd64
imagePullPolicy: Always
resources:
limits:
memory: 512Mi
cpu: 0.5
outputVariables: []
- step:
identifier: traffic_shift_50
type: GoogleMigTrafficShift
name: Traffic_Shift_50_Percent
spec:
trafficConfig:
type: CSM
spec:
type: GRPCRoute
route: projects/PROJECT_ID/locations/global/grpcRoutes/ROUTE_NAME
destinations:
- destination: stable
weight: 50
- destination: stage
weight: 50
connectorRef: GCP_CONNECTOR_ID
image: harness/google-mig-traffic-shift:0.0.1-linux-amd64
imagePullPolicy: Always
resources:
limits:
memory: 512Mi
cpu: 0.5
outputVariables: []
- step:
identifier: traffic_shift_100
type: GoogleMigTrafficShift
name: Traffic_Shift_100_Percent
spec:
trafficConfig:
type: CSM
spec:
type: GRPCRoute
route: projects/PROJECT_ID/locations/global/grpcRoutes/ROUTE_NAME
destinations:
- destination: stable
weight: 0
- destination: stage
weight: 100
connectorRef: GCP_CONNECTOR_ID
image: harness/google-mig-traffic-shift:0.0.1-linux-amd64
imagePullPolicy: Always
resources:
limits:
memory: 512Mi
cpu: 0.5
outputVariables: []
name: Google MIG Step Group
identifier: Google_MIG_Step_Group
stepGroupInfra:
type: KubernetesDirect
spec:
connectorRef: K8S_CONNECTOR_ID
namespace: NAMESPACE
serviceAccountName: SERVICE_ACCOUNT_NAME
automountServiceAccountToken: true
rollbackSteps: []
tags: {}
failureStrategies:
- onFailure:
errors:
- AllErrors
action:
type: StageRollback
delegateSelectors:
- DELEGATE_SELECTOR
identifier: PIPELINE_ID
name: Gradual Traffic Shift MIG Pipeline