diff options
Diffstat (limited to 'doc/ci/environments')
| -rw-r--r-- | doc/ci/environments/deployment_safety.md | 2 | ||||
| -rw-r--r-- | doc/ci/environments/incremental_rollouts.md | 10 | ||||
| -rw-r--r-- | doc/ci/environments/index.md | 36 | ||||
| -rw-r--r-- | doc/ci/environments/protected_environments.md | 39 |
4 files changed, 46 insertions, 41 deletions
diff --git a/doc/ci/environments/deployment_safety.md b/doc/ci/environments/deployment_safety.md index 033e499d3d0..4e34cc7ce38 100644 --- a/doc/ci/environments/deployment_safety.md +++ b/doc/ci/environments/deployment_safety.md @@ -4,7 +4,7 @@ group: Release info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/engineering/ux/technical-writing/#assignments --- -# Deployment safety +# Deployment safety **(FREE)** Deployment jobs can be more sensitive than other jobs in a pipeline, and might need to be treated with extra care. GitLab has several features diff --git a/doc/ci/environments/incremental_rollouts.md b/doc/ci/environments/incremental_rollouts.md index 39e3dd1ca75..e473d52f957 100644 --- a/doc/ci/environments/incremental_rollouts.md +++ b/doc/ci/environments/incremental_rollouts.md @@ -5,7 +5,7 @@ info: To determine the technical writer assigned to the Stage/Group associated w type: concepts, howto --- -# Incremental Rollouts with GitLab CI/CD +# Incremental rollouts with GitLab CI/CD **(FREE)** When rolling out changes to your application, it is possible to release production changes to only a portion of your Kubernetes pods as a risk mitigation strategy. By releasing @@ -22,9 +22,9 @@ Manual and Timed rollouts are included automatically in projects controlled by [Auto DevOps](../../topics/autodevops/index.md), but they are also configurable through GitLab CI/CD in the `.gitlab-ci.yml` configuration file. -Manually triggered rollouts can be implemented with your [Continuously Delivery](../introduction/index.md#continuous-delivery) +Manually triggered rollouts can be implemented with your [Continuous Delivery](../introduction/index.md#continuous-delivery) methodology, while timed rollouts do not require intervention and can be part of your -[Continuously Deployment](../introduction/index.md#continuous-deployment) strategy. +[Continuous Deployment](../introduction/index.md#continuous-deployment) strategy. You can also combine both of them in a way that the app is deployed automatically unless you eventually intervene manually if necessary. @@ -37,8 +37,6 @@ use as examples to build your own: ## Manual Rollouts -> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/5415) in GitLab 10.8. - It is possible to configure GitLab to do incremental rollouts manually through `.gitlab-ci.yml`. Manual configuration allows more control over the this feature. The steps in an incremental rollout depend on the number of pods that are defined for the deployment, which are configured when the Kubernetes @@ -77,8 +75,6 @@ available, demonstrating manually triggered incremental rollouts. ## Timed Rollouts -> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/7545) in GitLab 11.4. - Timed rollouts behave in the same way as manual rollouts, except that each job is defined with a delay in minutes before it deploys. Clicking the job reveals the countdown. diff --git a/doc/ci/environments/index.md b/doc/ci/environments/index.md index e647a704a87..1b4d8890c6e 100644 --- a/doc/ci/environments/index.md +++ b/doc/ci/environments/index.md @@ -31,7 +31,8 @@ Prerequisites: To view a list of environments and deployments: -1. Go to the project's **Deployments > Environments** page. +1. On the top bar, select **Menu > Projects** and find your project. +1. On the left sidebar, select **Deployments > Environments**. The environments are displayed.  @@ -57,7 +58,8 @@ You can create an environment and deployment in the UI or in your `.gitlab-ci.ym In the UI: -1. Go to the project's **Deployments > Environments** page. +1. On the top bar, select **Menu > Projects** and find your project. +1. On the left sidebar, select **Deployments > Environments**. 1. Select **New environment**. 1. Enter a name and external URL. 1. Select **Save**. @@ -326,7 +328,8 @@ If there is a problem with a deployment, you can retry it or roll it back. To retry or rollback a deployment: -1. Go to the project's **Deployments > Environments**. +1. On the top bar, select **Menu > Projects** and find your project. +1. On the left sidebar, select **Deployments > Environments**. 1. Select the environment. 1. To the right of the deployment name: - To retry a deployment, select **Re-deploy to environment**. @@ -353,12 +356,12 @@ For example:  -#### Going from source files to public pages +#### Go from source files to public pages With GitLab [Route Maps](../review_apps/index.md#route-maps), you can go directly from source files to public pages in the environment set for Review Apps. -### Stopping an environment +### Stop an environment When you stop an environment: @@ -465,7 +468,8 @@ GitLab automatically triggers the `stop_review_app` job to stop the environment. You can view a deployment's expiration date in the GitLab UI. -1. Go to the project's **Deployments > Environments** page. +1. On the top bar, select **Menu > Projects** and find your project. +1. On the left sidebar, select **Deployments > Environments**. 1. Select the name of the deployment. In the top left, next to the environment name, the expiration date is displayed. @@ -474,7 +478,8 @@ In the top left, next to the environment name, the expiration date is displayed. You can manually override a deployment's expiration date. -1. Go to the project's **Deployments > Environments** page. +1. On the top bar, select **Menu > Projects** and find your project. +1. On the left sidebar, select **Deployments > Environments**. 1. Select the deployment name. 1. On the top right, select the thumbtack (**{thumbtack}**). @@ -486,12 +491,13 @@ The `auto_stop_in` setting is overwritten and the environment remains active unt > [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/20620) in GitLab 12.10. -You can delete [stopped environments](#stopping-an-environment) in the GitLab UI or by using +You can delete [stopped environments](#stop-an-environment) in the GitLab UI or by using [the API](../../api/environments.md#delete-an-environment). To delete a stopped environment in the GitLab UI: -1. Go to the project's **Deployments > Environments** page. +1. On the top bar, select **Menu > Projects** and find your project. +1. On the left sidebar, select **Deployments > Environments**. 1. Select the **Stopped** tab. 1. Next to the environment you want to delete, select **Delete environment**. 1. On the confirmation dialog box, select **Delete environment**. @@ -519,7 +525,7 @@ build: url: https://staging.example.com ``` -This gives you access to [environment-scoped variables](#scoping-environments-with-specs), +This gives you access to [environment-scoped variables](#scope-environments-with-specs), and can be used to [protect builds from unauthorized access](protected_environments.md). ### Group similar environments @@ -596,11 +602,13 @@ Limitations of GitLab Auto Rollback: GitLab Auto Rollback is turned off by default. To turn it on: -1. Go to **Project > Settings > CI/CD > Automatic deployment rollbacks**. +1. On the top bar, select **Menu > Projects** and find your project. +1. On the left sidebar, select **Settings > CI/CD**. +1. Expand **Automatic deployment rollbacks**. 1. Select the checkbox for **Enable automatic rollbacks**. 1. Select **Save changes**. -### Monitoring environments +### Monitor environments To monitor the behavior of your app as it runs in each environment, enable [Prometheus for monitoring system and response metrics](../../user/project/integrations/prometheus.md). @@ -619,7 +627,7 @@ It may take a minute or two for data to appear after initial deployment.  -#### Embedding metrics in GitLab Flavored Markdown +#### Embed metrics in GitLab Flavored Markdown Metric charts can be embedded in GitLab Flavored Markdown. See [Embedding Metrics in GitLab Flavored Markdown](../../operations/metrics/embed.md) for more details. @@ -672,7 +680,7 @@ fetch line: fetch = +refs/environments/*:refs/remotes/origin/environments/* ``` -### Scoping environments with specs +### Scope environments with specs > - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/2112) in [GitLab Premium](https://about.gitlab.com/pricing/) 9.4. > - [Environment scoping for CI/CD variables was moved to all tiers](https://gitlab.com/gitlab-org/gitlab-foss/-/merge_requests/30779) in GitLab 12.2. diff --git a/doc/ci/environments/protected_environments.md b/doc/ci/environments/protected_environments.md index 9bc3c97837c..3cd4ebdbdf1 100644 --- a/doc/ci/environments/protected_environments.md +++ b/doc/ci/environments/protected_environments.md @@ -30,18 +30,19 @@ To protect, update, or unprotect an environment, you need to have at least the To protect an environment: -1. Navigate to your project's **Settings > CI/CD**. -1. Expand the **Protected environments** section. -1. From the **Environment** dropdown menu, select the environment you want to protect. -1. In the **Allowed to Deploy** dropdown menu, select the role, users, or groups you +1. On the top bar, select **Menu > Projects** and find your project. +1. On the left sidebar, select **Settings > CI/CD**. +1. Expand **Protected environments**. +1. From the **Environment** list, select the environment you want to protect. +1. In the **Allowed to deploy** list, select the role, users, or groups you want to give deploy access to. Keep in mind that: - There are two roles to choose from: - - **Maintainers**: Allows access to all maintainers in the project. - - **Developers**: Allows access to all maintainers and all developers in the project. - - You can only select groups that are already associated with the project. - - Only users that have at least the Developer role appear in - the **Allowed to Deploy** dropdown menu. -1. Click the **Protect** button. + - **Maintainers**: Allows access to all of the project's users with the Maintainer role. + - **Developers**: Allows access to all of the project's users with the Maintainer and Developer role. + - You can select groups that are already associated with the project only. + - Users must have at least the Developer role to appear in + the **Allowed to deploy** list. +1. Select **Protect**. The protected environment now appears in the list of protected environments. @@ -121,7 +122,7 @@ access to a protected environment through any of these methods: If the user also has push or merge access to the branch deployed on production, they have the following privileges: -- [Stopping an environment](index.md#stopping-an-environment). +- [Stop an environment](index.md#stop-an-environment). - [Delete a stopped environment](index.md#delete-a-stopped-environment). - [Create an environment terminal](index.md#web-terminals). @@ -134,10 +135,10 @@ appears in the dropdown menu for deployment-only access. To add deployment-only access: -1. Add a group with Reporter permissions. -1. Add user(s) to the group. +1. Add a group with the Reporter role. +1. Add users to the group. 1. Invite the group to be a project member. -1. Follow the steps outlined in [Protecting Environments](#protecting-environments). +1. Follow the steps in [Protecting Environments](#protecting-environments). Note that deployment-only access is the only possible access level for groups with [Reporter permissions](../../user/permissions.md). @@ -163,7 +164,7 @@ For more information, see [Deployment safety](deployment_safety.md). > - To use in GitLab self-managed instances, ask a GitLab administrator to [enable it](#enable-or-disable-group-level-protected-environments). **(FREE SELF)** This in-development feature might not be available for your use. There can be -[risks when enabling features still in development](../../user/feature_flags.md#risks-when-enabling-features-still-in-development). +[risks when enabling features still in development](../../administration/feature_flags.md#risks-when-enabling-features-still-in-development). Refer to this feature's version history for more details. Typically, large enterprise organizations have an explicit permission boundary @@ -214,7 +215,7 @@ configured: - Operators should be assigned the [maintainer role](../../user/permissions.md) (or above) to the top-level group. They can maintain CI/CD configurations for the higher environments (such as production) in the group-level settings page, - wnich includes group-level protected environments, + which includes group-level protected environments, [group-level runners](../runners/runners_scope.md#group-runners), [group-level clusters](../../user/group/clusters/index.md), etc. Those configurations are inherited to the child projects as read-only entries. @@ -231,9 +232,9 @@ configured: cannot override it. - [Project-level protected environments](#protecting-environments) can be combined with the group-level setting. If both group-level and project-level - environment configurations exist, the user must be allowed in **both** - rulesets in order to run a deployment job. - - Within a project or a sub-group of the top-level group, developers can be + environment configurations exist, to run a deployment job, the user must be allowed in **both** + rulesets. + - In a project or a subgroup of the top-level group, developers can be safely assigned the Maintainer role to tune their lower environments (such as `testing`). |