<commit_before># Cloud Run Release Manager

The Cloud Run Release Manager provides an automated way to gradually roll out
new versions of your Cloud Run services. By using metrics, it automatically
decides to slowly increase traffic to a new version or roll back to the previous
one.

> **Disclaimer:** This project is not an official Google product and is provided
> as-is.
>
> You might encounter issues in production, since this project is currently in
> **alpha**.

## Table of Contents

<!--
  ⚠️ DO NOT UPDATE THE TABLE OF CONTENTS MANUALLY ️️⚠️
  run `npx markdown-toc -i README.md`.

  Please stick to 80-character line wraps as much as you can.
-->

<!-- toc -->

- [How does it work?](#how-does-it-work)
  * [Examples](#examples)
    + [Scenario 1: Automated Rollouts](#scenario-1-automated-rollouts)
    + [Scenario 2: Automated Rollbacks](#scenario-2-automated-rollbacks)
- [Setup on GCP](#setup-on-gcp)
- [Configuration](#configuration)
  * [Choosing services](#choosing-services)
  * [Rollout strategy](#rollout-strategy)
- [Try it out (locally)](#try-it-out-locally)
- [Observability & Troubleshooting](#observability--troubleshooting)
  * [What's happening with my rollout?](#whats-happening-with-my-rollout)
  * [Release Manager logs](#release-manager-logs)

<!-- tocstop -->

## How does it work?

Cloud Run Release Manager is not a built-in Cloud Run feature. It’s an external
tool deployed to your project. It oversees your Cloud Run services (that have
opted-in for gradual rollouts) periodically, detects newly deployed revisions,
monitors their metrics and makes a rollout or rollback decision.

To opt-in services for gradual rollouts, you should [label your services][label]
with `rollout-strategy=gradual` (default value). If a service has a newly
deployed revision with 0% traffic, the Release Manager automatically assigns
some initial traffic to the new revision (5% [by default](#configuration)).

The Release Manager manages 2 revisions at a time: the last revision that
reached 100% of the traffic (tagged as `stable`) and the newest deployment
(tagged as `candidate`).

Depending on the candidate revision’s health and other configurable factors
(such as served request count or time elapsed), this revision is either
gradually rolled out to a higher percentage of traffic, or entirely rolled back.

### Examples

#### Scenario 1: Automated Rollouts

1. I have version **v1** of an application deployed to Cloud Run
2. I deploy a new version, **v2**, to Cloud Run with `--no-traffic` option (gets
0% of the traffic)
3. The new version is automatically detected and assigned 5% of the traffic
4. Every minute, metrics for **v2** in the last 30 minutes are retrieved.
Metrics show a "healthy" version and traffic to **v2** is increased to 30% only
after 30 minutes have passed since last update
5. Metrics show a "healthy" version again and traffic to **v2** is increased to
50% only after 30 minutes have passed since last update
6. The process is repeated until the new version handles all the traffic and
becomes `stable`

![Rollout stages](assets/rollout-stages.svg "Rollout stages from v1 to v2")

#### Scenario 2: Automated Rollbacks

1. I have version **v1** of an application deployed to Cloud Run
2. I deploy a new version, **v2**, to Cloud Run with `--no-traffic` option (gets
0% of the traffic)
3. The new version is automatically detected and assigned 5% of the traffic
4. Every minute, metrics for **v2** in the last 30 minutes are retrieved.
Metrics show a "healthy" version and traffic to **v2** is increased to 30% only
after 30 minutes have passed since last update
5. Metrics for **v2** are retrieved one more time and show an "unhealthy"
version. Traffic to **v2** is inmediately dropped, and all traffic is redirected
to **v1**

![Rollout stages](assets/rollback-stages.svg "Rollout stages from v1 to v2")

## Setup on GCP

Cloud Run Release Manager is distributed as a service deployed to **your GCP
project**, running on Cloud Run and invoked periodically by [Cloud
Scheduler](https://cloud.google.com/scheduler/).

To set up the Release Manager on Cloud Run, run the following steps on your
shell:

1. Set your project ID in a variable:

    ```sh
    PROJECT_ID=<your-project>
    ```

1. Create a new service account:

    ```sh
    gcloud iam service-accounts create release-manager \
        --display-name "Cloud Run Release Manager"
    ```
<commit_msg>Fix typo in README.md (#111)<commit_after># Cloud Run Release Manager

The Cloud Run Release Manager provides an automated way to gradually roll out
new versions of your Cloud Run services. By using metrics, it automatically
decides to slowly increase traffic to a new version or roll back to the previous
one.

> **Disclaimer:** This project is not an official Google product and is provided
> as-is.
>
> You might encounter issues in production, since this project is currently in
> **alpha**.

## Table of Contents

<!--
  ⚠️ DO NOT UPDATE THE TABLE OF CONTENTS MANUALLY ️️⚠️
  run `npx markdown-toc -i README.md`.

  Please stick to 80-character line wraps as much as you can.
-->

<!-- toc -->

- [How does it work?](#how-does-it-work)
  * [Examples](#examples)
    + [Scenario 1: Automated Rollouts](#scenario-1-automated-rollouts)
    + [Scenario 2: Automated Rollbacks](#scenario-2-automated-rollbacks)
- [Setup on GCP](#setup-on-gcp)
- [Configuration](#configuration)
  * [Choosing services](#choosing-services)
  * [Rollout strategy](#rollout-strategy)
- [Try it out (locally)](#try-it-out-locally)
- [Observability & Troubleshooting](#observability--troubleshooting)
  * [What's happening with my rollout?](#whats-happening-with-my-rollout)
  * [Release Manager logs](#release-manager-logs)

<!-- tocstop -->

## How does it work?

Cloud Run Release Manager is not a built-in Cloud Run feature. It’s an external
tool deployed to your project. It oversees your Cloud Run services (that have
opted-in for gradual rollouts) periodically, detects newly deployed revisions,
monitors their metrics and makes a rollout or rollback decision.

To opt-in services for gradual rollouts, you should [label your services][label]
with `rollout-strategy=gradual` (default value). If a service has a newly
deployed revision with 0% traffic, the Release Manager automatically assigns
some initial traffic to the new revision (5% [by default](#configuration)).

The Release Manager manages 2 revisions at a time: the last revision that
reached 100% of the traffic (tagged as `stable`) and the newest deployment
(tagged as `candidate`).

Depending on the candidate revision’s health and other configurable factors
(such as served request count or time elapsed), this revision is either
gradually rolled out to a higher percentage of traffic, or entirely rolled back.

### Examples

#### Scenario 1: Automated Rollouts

1. I have version **v1** of an application deployed to Cloud Run
2. I deploy a new version, **v2**, to Cloud Run with `--no-traffic` option (gets
0% of the traffic)
3. The new version is automatically detected and assigned 5% of the traffic
4. Every minute, metrics for **v2** in the last 30 minutes are retrieved.
Metrics show a "healthy" version and traffic to **v2** is increased to 30% only
after 30 minutes have passed since last update
5. Metrics show a "healthy" version again and traffic to **v2** is increased to
50% only after 30 minutes have passed since last update
6. The process is repeated until the new version handles all the traffic and
becomes `stable`

![Rollout stages](assets/rollout-stages.svg "Rollout stages from v1 to v2")

#### Scenario 2: Automated Rollbacks

1. I have version **v1** of an application deployed to Cloud Run
2. I deploy a new version, **v2**, to Cloud Run with `--no-traffic` option (gets
0% of the traffic)
3. The new version is automatically detected and assigned 5% of the traffic
4. Every minute, metrics for **v2** in the last 30 minutes are retrieved.
Metrics show a "healthy" version and traffic to **v2** is increased to 30% only
after 30 minutes have passed since last update
5. Metrics for **v2** are retrieved one more time and show an "unhealthy"
version. Traffic to **v2** is immediately dropped, and all traffic is redirected
to **v1**

![Rollout stages](assets/rollback-stages.svg "Rollout stages from v1 to v2")

## Setup on GCP

Cloud Run Release Manager is distributed as a service deployed to **your GCP
project**, running on Cloud Run and invoked periodically by [Cloud
Scheduler](https://cloud.google.com/scheduler/).

To set up the Release Manager on Cloud Run, run the following steps on your
shell:

1. Set your project ID in a variable:

    ```sh
    PROJECT_ID=<your-project>
    ```

1. Create a new service account:

    ```sh
    gcloud iam service-accounts create release-manager \
        --display-name "Cloud Run Release Manager"
    ```

{'fraction_non_alphanumeric': 0.09139237642800588, 'fraction_numerical': 0.014591109602986088, 'mean_word_length': 4.300959232613909, 'pattern_counts': {'":': 0, '<': 11, '<?xml version=': 0, '>': 21, 'https://': 2, 'lorem ipsum': 0, 'www.': 0, 'xml': 0}, 'pii_count': 0, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 0, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
{'dir': 'git-commits-cleaned', 'id': '1934330', 'n_tokens_mistral': 2584, 'n_tokens_neox': 2432, 'n_words': 1224}