Deployment Strategies

Deploy a new Cloud Run revision and route all traffic to it immediately using the Basic deployment strategy.

The Basic deployment strategy deploys a new Cloud Run revision and shifts all traffic to it immediately after the revision is healthy. Use this strategy when you do not need gradual traffic shifting and want the simplest deploy path.

---

What you will learn

• How the Basic strategy step sequence works, including the Deploy and Rollback steps Harness adds automatically.

• How to configure the Deploy step and when to use Skip Traffic Update.

• How rollback behaves on first and subsequent deployments.

• The exact gcloud commands Harness runs during a basic deployment and rollback.

---

Before you begin

• A Google Cloud Run service: Go to Google Cloud Run services to set up a service with a manifest and artifact source.

• A Google Cloud Run infrastructure: Go to Google Cloud Run infrastructure to connect a GCP project and region.

---

Basic strategy step sequence

When you select Google Cloud Run Basic Deploy Strategy, Harness adds a Google Cloud Run Deploy step to your stage execution. The Deploy step:

1. Applies the service manifest using gcloud run services replace.

2. Runs gcloud run services describe to fetch the current revision and traffic configuration, then saves it to rollback data.

3. Shifts all traffic to the new revision immediately (unless Skip Traffic Update is enabled).

4. Fetches instance data using the Google Cloud Monitoring SDK. If no data is available yet, the step retries every 60 seconds, up to 10 times. Factor up to 10 minutes of instance sync into your expected step duration.

A Google Cloud Run Rollback step is automatically added to the stage's rollback phase.

You can optionally add a Google Cloud Run Traffic Shift step after the Deploy step to perform an additional explicit traffic shift to a specific revision or percentage.

No Prepare Rollback step

There is no separate Prepare Rollback step. The Deploy step saves rollback data internally, so Harness can restore the previous state if the stage fails.

---

Stage YAML

A minimal basic deployment stage looks like this. The Deploy step requires no explicit parameter overrides. All fields default to values resolved from the service and infrastructure definition. Add a with: block to the googleCloudRunDeployStep template only if you need to override a specific field such as skip_traffic_update or cmd_options.

- name: google-cloud-run
  id: googleCloudRun
  service:
    type: google-cloud-run
    items:
    - <service-id>
  environment:
    items:
    - id: <environment-id>
      deploy-to: all
  steps:
  - name: Google Cloud Run Deploy
    id: googleCloudRunDeployStep
    template:
      uses: googleCloudRunDeployStep
  rollback:
  - group:
      steps:
      - name: Google Cloud Run Rollback
        id: googleCloudRunRollbackStep
        template:
          uses: googleCloudRunRollbackStep
    id: googleCloudRunBasicRollback
    name: Google Cloud Run Basic Rollback
  on-failure:
    errors: all
    action: stage-rollback

---

Configure the Deploy step

Configure the following fields in the Google Cloud Run Deploy step:

Field	Default	Description
Name	Google Cloud Run Deploy	The step name.
GCP Connector	—	The GCP connector used to authenticate with Cloud Run. Defaults to the connector in the infrastructure definition.
GCP Region	${{infra.region}}	The region of the Cloud Run service. Automatically resolved from the infrastructure definition.
GCP Project	${{infra.project}}	The GCP project of the Cloud Run service. Automatically resolved from the infrastructure definition.
Service Manifest Path	${{runtime.manifestPath}}	The path to the downloaded service manifest. Automatically resolved at runtime.
Service Container Image	${{artifact.image}}	The container image to deploy. Automatically resolved from the artifact source.
Command Options	—	Additional flags passed to gcloud run services replace (for example, --port=8080).
Skip Traffic Update	false	When true, the Deploy step creates a new revision without shifting any traffic. Traffic must be shifted explicitly with a Traffic Shift step.
Command Timeout	10m	Maximum time for the step to complete.
Log Level	info	Log verbosity for the step execution.

Skip Traffic Update on first deployment

Skip Traffic Update applies to subsequent deployments only. On the first deployment of a service, Harness always shifts traffic to the new revision regardless of this setting.

---

Rollback behavior

When the stage failure strategy triggers rollback, the Google Cloud Run Rollback step inside the Google Cloud Run Basic Rollback step group runs automatically.

The Rollback step requires no configuration inputs. Harness automatically reads the revision state from the last successful deployment of the stage.

Rollback behavior differs by deployment history:

• First deployment: Harness deletes the newly created service using gcloud run services delete.

• Subsequent deployments: Harness runs gcloud run revisions list to inspect revision history, then runs gcloud run services update-traffic <service> --to-revisions=<previous-revision>=100 to restore traffic to the revision that was live before the failed deploy.

Rollback does not delete revisions

Google Cloud Run does not support deleting a specific revision. Rollback on subsequent deployments diverts traffic to a previous revision rather than deleting the newly created one.

---

Deployment execution

The following sequence shows what happens when a basic deployment stage runs.

Successful deployment:

1. Harness fetches the service manifest from the configured manifest store and writes it to /harness/manifest/GoogleCloudRun/ServiceManifest.yaml.

2. The Deploy step injects the container image URL from the artifact source into the manifest.

3. The Deploy step runs gcloud run services replace to create the new revision.

4. Cloud Run routes 100% of traffic to the new revision.

5. The Deploy step runs gcloud run services describe to capture the resulting revision name and traffic state and saves them as rollback data.

6. The Deploy step polls Google Cloud Monitoring for instance count. If no data is available, it retries every 60 seconds, up to 10 times. Instance sync adds up to 10 minutes to the step duration.

7. The stage completes successfully.

Failed deployment:

1. If any step fails, the on-failure: action: stage-rollback failure strategy triggers the rollback phase.

2. The Google Cloud Run Rollback step runs inside the Google Cloud Run Basic Rollback group.

3. On first deployment, the step deletes the newly created service. On subsequent deployments, the step restores traffic to the previous revision.

4. The rollback step performs instance sync and the stage ends in a failed state.

---

Next steps

• Go to Google Cloud Run canary deployment to learn how to shift traffic gradually.

• Go to Blank canvas to compose steps manually.