Merge branch 'docs-anchors-19-environments' into 'master'
Docs: Fix anchors related to environments doc See merge request gitlab-org/gitlab-ce!27082
This commit is contained in:
commit
b2f81eaf2c
|
@ -664,7 +664,7 @@ fetch = +refs/environments/*:refs/remotes/origin/environments/*
|
|||
### Scoping environments with specs **[PREMIUM]**
|
||||
|
||||
Some GitLab [Enterprise Edition](https://about.gitlab.com/pricing/) features can behave differently for each
|
||||
environment. For example, you can [create a secret variable to be injected only into a production environment](variables/README.md#limiting-environment-scopes-of-variables-premium).
|
||||
environment. For example, you can [create a secret variable to be injected only into a production environment](https://docs.gitlab.com/ee/ci/variables/#limiting-environment-scopes-of-environment-variables-premium).
|
||||
|
||||
In most cases, these features use the _environment specs_ mechanism, which offers
|
||||
an efficient way to implement scoping within each environment group.
|
||||
|
|
|
@ -511,7 +511,7 @@ Errors can be easily debugged through GitLab's build logs, and within minutes of
|
|||
you can see the changes live on your game.
|
||||
|
||||
Setting up Continuous Integration and Continuous Deployment from the start with Dark Nova enables
|
||||
rapid but stable development. We can easily test changes in a separate [environment](../../../ci/environments.md#introduction-to-environments-and-deployments),
|
||||
rapid but stable development. We can easily test changes in a separate [environment](../../environments.md),
|
||||
or multiple environments if needed. Balancing and updating a multiplayer game can be ongoing
|
||||
and tedious, but having faith in a stable deployment with GitLab CI/CD allows
|
||||
a lot of breathing room in quickly getting changes to players.
|
||||
|
|
|
@ -127,7 +127,7 @@ displayed by GitLab:
|
|||
![pipeline status](img/pipeline_status.png)
|
||||
|
||||
At the end, if anything goes wrong, you can easily
|
||||
[roll back](../environments.md#rolling-back-changes) all the changes:
|
||||
[roll back](../environments.md#retrying-and-rolling-back) all the changes:
|
||||
|
||||
![rollback button](img/rollback.png)
|
||||
|
||||
|
|
|
@ -295,7 +295,7 @@ You can do this straight from the pipeline graph. Just click on the play button
|
|||
to execute that particular job.
|
||||
|
||||
For example, your pipeline start automatically, but require manual action to
|
||||
[deploy to production](environments.md#manually-deploying-to-environments). In the example below, the `production`
|
||||
[deploy to production](environments.md#configuring-manual-deployments). In the example below, the `production`
|
||||
stage has a job with a manual action.
|
||||
|
||||
![Pipelines example](img/pipelines.png)
|
||||
|
@ -313,7 +313,7 @@ For example, if you start rolling out new code and:
|
|||
|
||||
- Users do not experience trouble, GitLab can automatically complete the deployment from 0% to 100%.
|
||||
- Users experience trouble with the new code, you can stop the timed incremental rollout by canceling the pipeline
|
||||
and [rolling](environments.md#rolling-back-changes) back to the last stable version.
|
||||
and [rolling](environments.md#retrying-and-rolling-back) back to the last stable version.
|
||||
|
||||
![Pipelines example](img/pipeline_incremental_rollout.png)
|
||||
|
||||
|
|
|
@ -33,7 +33,7 @@ In this example, you can see a branch was:
|
|||
|
||||
## How do Review Apps work?
|
||||
|
||||
The basis of Review Apps in GitLab is [dynamic environments](../environments.md#dynamic-environments), which allow you to dynamically create a new environment for each branch.
|
||||
The basis of Review Apps in GitLab is [dynamic environments](../environments.md#configuring-dynamic-environments), which allow you to dynamically create a new environment for each branch.
|
||||
|
||||
Access to the Review App is made available as a link on the [merge request](../../user/project/merge_requests.md) relevant to the branch. Review Apps enable you to review all changes proposed by the merge request in live environment.
|
||||
|
||||
|
@ -60,14 +60,14 @@ To get a better understanding of Review Apps, review documentation on how enviro
|
|||
1. Learn about [environments](../environments.md) and their role in the development workflow.
|
||||
1. Learn about [CI variables](../variables/README.md) and how they can be used in your CI jobs.
|
||||
1. Explore the [`environment` syntax](../yaml/README.md#environment) as defined in `.gitlab-ci.yml`. This will become a primary reference.
|
||||
1. Additionally, find out about [manual actions](../environments.md#manually-deploying-to-environments) and how you can use them to deploy to critical environments like production with the push of a button.
|
||||
1. Additionally, find out about [manual actions](../environments.md#configuring-manual-deployments) and how you can use them to deploy to critical environments like production with the push of a button.
|
||||
1. Follow the [example tutorials](#examples). These will guide you through setting up infrastructure and using Review Apps.
|
||||
|
||||
### Configuring dynamic environments
|
||||
|
||||
Configuring Review Apps dynamic environments depends on your technology stack and infrastructure.
|
||||
|
||||
For more information, see [dynamic environments](../environments.md#dynamic-environments) documentation to understand how to define and create them.
|
||||
For more information, see [dynamic environments](../environments.md#configuring-dynamic-environments) documentation to understand how to define and create them.
|
||||
|
||||
### Creating and destroying Review Apps
|
||||
|
||||
|
|
|
@ -756,7 +756,7 @@ Manual actions are a special type of job that are not executed automatically,
|
|||
they need to be explicitly started by a user. An example usage of manual actions
|
||||
would be a deployment to a production environment. Manual actions can be started
|
||||
from the pipeline, job, environment, and deployment views. Read more at the
|
||||
[environments documentation](../environments.md#manually-deploying-to-environments).
|
||||
[environments documentation](../environments.md#configuring-manual-deployments).
|
||||
|
||||
Manual actions can be either optional or blocking. Blocking manual actions will
|
||||
block the execution of the pipeline at the stage this action is defined in. It's
|
||||
|
|
|
@ -955,7 +955,7 @@ required to go from `10%` to `100%`, you can jump to whatever job you want.
|
|||
You can also scale down by running a lower percentage job, just before hitting
|
||||
`100%`. Once you get to `100%`, you cannot scale down, and you'd have to roll
|
||||
back by redeploying the old version using the
|
||||
[rollback button](../../ci/environments.md#rolling-back-changes) in the
|
||||
[rollback button](../../ci/environments.md#retrying-and-rolling-back) in the
|
||||
environment page.
|
||||
|
||||
Below, you can see how the pipeline will look if the rollout or staging
|
||||
|
|
Loading…
Reference in New Issue