Skip to content

feat: added deployment modes section #4731

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 12 commits into
base: main
Choose a base branch
from
Open
Show file tree
Hide file tree
Changes from 6 commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
98 changes: 98 additions & 0 deletions sites/platform/src/learn/overview/build-deploy.md
Original file line number Diff line number Diff line change
Expand Up @@ -85,6 +85,104 @@ but the file system is read-only.

After the deploy process is over, any commands in your `post_deploy` hook are run.

## Deployment types

{{% vendor/name %}} supports two deployment types - automatic and manual. These types help to provide control over when changes are applied to staging and production environments.

### Automatic deployment (default)

This is the default behavior for all environments. With automatic deployment, changes like code pushes and variable updates are deployed immediately. This type of deployment is best suited for rapid iteration during development.

### Manual deployment

When enabled, manual deployment lets you control when deployments happen. This means that changes will be staged but not deployed until explicitly triggered by the user. This type of deployment is ideal for teams that want to bundle multiple changes and deploy them together in a controlled manner.

When manual deployment is enabled in an environment, the following actions are queued until deployment is triggered:

| Category | Staged Activities |
|----------------------|------------------|
| **Code** | `environment.push`, `environment.merge`, `environment.merge-pr` |

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We are missing on platform.sh docs one activity category Subscription, environment.subscription.update .

It is only on platform.sh not upsun.

| **Variables** | `environment.variable.create`, `update`, `delete` |
| **Resources** | `environment.resources.update` |
| **Domains & Routes** | `environment.domain.*`, `environment.route.*` |
| **Environment Settings** | `environment.update.http_access`, `smtp`, `restrict_robots` |


{{< note theme="info" >}}

Note that development environments **always** use automatic deployment, while manual deployment is only available for staging and production environments.

{{< /note >}}


### Change deployment type

You can adjust deployment behavior in your environment (staging or production only). To switch to manual, navigate to the environment settings in the Console and select the manual deployments option. To revert to automatic deployments, select the automatic deployments option.

{{< note theme="tip" >}}

If manual deployment is enabled, all currently staged changes will be deployed immediately and the environment will resume automatic deployment (default) behavior.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think the wording here is not ideal, it's not clear that it happen when we switch from automatic to manual. Can we say like "when switching from manual to automatic"?


{{< /note >}}

### Trigger deployment manually

Once manual deployment is enabled, eligible changes are staged. You can deploy them in the following ways:

{{< codetabs >}}

+++
title=Using the CLI
+++

List environments with the following command:

```bash
platform environment:list

```
Then deploy the staged changes to a specific environment:

```bash
platform environment:deploy
```

The output should look similar to the example below:

```bash
Deploying staged changes:
+---------------+---------------------------+-----------------------------------------------------------+---------+
| ID | Created | Description | Result |
+---------------+---------------------------+-----------------------------------------------------------+---------+
| 5uh3xwmkh5boq | 2024-11-22T14:01:10+00:00 | Patrick pushed to main | failure |
| fno2qiodq7e3c | 2024-11-22T13:06:18+00:00 | Arseni updated resource allocation on main | success |
| xzvcazrtoafeu | 2024-11-22T13:01:10+00:00 | Pilar added variable HELLO_WORLD to main | success |
| fq73u53ruwloq | 2024-11-22T12:06:17+00:00 | Pilar pushed to main | success |
+---------------+---------------------------+-----------------------------------------------------------+---------+
```

<--->
+++
title=Using the Console
+++

In the Console, a **Deploy** button will appear in the environment whenever changes are staged. You can review a summary of the pending changes before confirming the deployment.

<--->
+++
title=Using the API
+++

Trigger the deployment of staged changes with the following:

```bash

POST /projects/{projectId}/environments/{environmentId}/deploy

```

{{< /codetabs >}}

## Deployment philosophy

{{% vendor/name %}} values consistency over availability, acknowledging that it's nearly impossible to have both.
Expand Down
98 changes: 98 additions & 0 deletions sites/upsun/src/learn/overview/build-deploy.md
Original file line number Diff line number Diff line change
Expand Up @@ -85,6 +85,104 @@ but the file system is read-only.

After the deploy process is over, any commands in your `post_deploy` hook are run.

## Deployment types

{{% vendor/name %}} supports two deployment types - automatic and manual. These types help to provide control over when changes are applied to staging and production environments.

### Automatic deployment (default)

This is the default behavior for all environments. With automatic deployment, changes like code pushes and variable updates are deployed immediately. This type of deployment is best suited for rapid iteration during development.

### Manual deployment

When enabled, manual deployment lets you control when deployments happen. This means that changes will be staged but not deployed until explicitly triggered by the user. This type of deployment is ideal for teams that want to bundle multiple changes and deploy them together in a controlled manner.

When manual deployment is enabled in an environment, the following actions are queued until deployment is triggered:

| Category | Staged Activities |
|----------------------|------------------|
| **Code** | `environment.push`, `environment.merge`, `environment.merge-pr` |
| **Variables** | `environment.variable.create`, `update`, `delete` |
| **Resources** | `environment.resources.update` |
| **Domains & Routes** | `environment.domain.*`, `environment.route.*` |
| **Environment Settings** | `environment.update.http_access`, `smtp`, `restrict_robots` |


{{< note theme="info" >}}

Note that development environments **always** use automatic deployment, while manual deployment is only available for staging and production environments.

{{< /note >}}


### Change deployment type

You can adjust deployment behavior in your environment (staging or production only). To switch to manual, navigate to the environment settings in the Console and select the manual deployments option. To revert to automatic deployments, select the automatic deployments option.

{{< note theme="tip" >}}

If manual deployment is disabled, all currently staged changes will be deployed immediately and the environment will resume automatic deployment (default) behavior.

{{< /note >}}

### Trigger deployment manually

Once manual deployment is enabled, eligible changes are staged. You can deploy them in the following ways:

{{< codetabs >}}

+++
title=Using the CLI
+++

List environments with the following command:

```bash
upsun environment:list

```
Then deploy the staged changes to a specific environment:

```bash
upsun environment:deploy
```

The output should look similar to the example below:

```bash
Deploying staged changes:
+---------------+---------------------------+-----------------------------------------------------------+---------+
| ID | Created | Description | Result |
+---------------+---------------------------+-----------------------------------------------------------+---------+
| 5uh3xwmkh5boq | 2024-11-22T14:01:10+00:00 | Patrick pushed to main | failure |
| fno2qiodq7e3c | 2024-11-22T13:06:18+00:00 | Arseni updated resource allocation on main | success |
| xzvcazrtoafeu | 2024-11-22T13:01:10+00:00 | Pilar added variable HELLO_WORLD to main | success |
| fq73u53ruwloq | 2024-11-22T12:06:17+00:00 | Pilar pushed to main | success |
+---------------+---------------------------+-----------------------------------------------------------+---------+
```

<--->
+++
title=Using the Console
+++

In the Console, a **Deploy** button will appear in the environment whenever changes are staged. You can review a summary of the pending changes before confirming the deployment.

<--->
+++
title=Using the API
+++

Trigger the deployment of staged changes with the following:

```bash

POST /projects/{projectId}/environments/{environmentId}/deploy

```

{{< /codetabs >}}

## Deployment philosophy

{{% vendor/name %}} values consistency over availability, acknowledging that it's nearly impossible to have both.
Expand Down
Loading