Rollout strategies

This document describes the rollout strategies available in App Lifecycle Manager for managing how releases are deployed across units in your app offering.

When you manage distributed SaaS applications, deploying updates simultaneously across all customer environments can lead to widespread outages if an unexpected regression occurs. Rollout strategies protect your service availability by controlling the pace, sequence, and blast radius of software releases across logical and physical failure domains. By configuring rollout strategies in App Lifecycle Manager, you can automate gradual rollouts, introduce soak times between deployment waves, and define error budgets that halt problematic releases before they impact all your customers.

Overview of rollout strategies

App Lifecycle Manager provides configurable rollout strategies to manage how units in your app offering are updated. These rollout strategies follow Google Cloud's approach to change by applying consistent, staged deployment practices across your app offering.

Use rollout strategies to minimize negative customer impact and isolate issues to individual logical and physical failure domains. You define your rollout strategy by creating a rollout kind that specifies one of the following strategies:

  • One location at a time (simple) (Google.Cloud.Simple.OneLocationAtATime): One location is updated at a time, with no wait between locations. Units are selected arbitrarily within a location, with a maximum of 5% of the location's units updated at a given time.

    This strategy is recommended for development environments and emergency scenarios.

  • All at once (simple) (Google.Cloud.Simple.AllAtOnce): All locations begin updating at the same time.

    This strategy is recommended for development environments and emergency scenarios.

  • Progressive (gradual) (Google.Cloud.Progressive.Gradual.v1): Within each location, units are updated in static percentage-based batches (for example, 1%, 10%, 20%, 30%, and ~40%) with soak times between batches. Across locations, the rollout progresses with an exponential increase in the number of concurrent locations (for example, one location, then two, then four) with soak times (for example, 18 hours) between waves. Units within a location are selected randomly.

    This strategy is designed for safe and predictable rollouts across multiple locations. It starts with a small footprint and gradually expands as confidence grows. We recommend this strategy in production environments with more than one location.

  • Progressive (single location) (Google.Cloud.Progressive.SingleLocation.v1): Units are updated in static percentage-based batches (for example, 1%, 10%, 20%, 30%, and ~40%) with longer soak times (for example, 18 hours) between batches to allow ample time for issue detection and to limit the adverse impact of rollout changes.

    This strategy is tailored for app offerings operating in a single location, prioritizing safety and caution. We recommend this strategy in production environments with one location.

Configure rollout kinds and safeguards

When you create a rollout kind, you associate a rollout strategy with a target UnitKind and can configure additional safeguards:

  • Error budget (error_budget): Automatically pauses a rollout if the number or percentage of failed unit updates exceeds your configured threshold (allowed_count or allowed_ratio).

  • Unit filter (unit_filter): Applies a Common Expression Language (CEL) filter string when using Google Cloud CLI to restrict the eligible population of units targeted by the rollout.

  • Regional scope: Supported rollout locations are determined by the available regions configured on your app offering. For details on how regions affect rollout propagation, see App Lifecycle Manager regionalization.

What's next