@@ -285,7 +285,7 @@ The following documentation relates to the DevOps **Release** stage:
| [Auto Deploy](topics/autodevops/stages.md#auto-deploy) | Configure GitLab for the deployment of your application. |
| [Canary Deployments](user/project/canary_deployments.md)**(PREMIUM)** | Employ a popular CI strategy where a small portion of the fleet is updated to the new version first. |
| [Deploy Boards](user/project/deploy_boards.md)**(PREMIUM)** | View the current health and status of each CI environment running on Kubernetes, displaying the status of the pods in the deployment. |
| [Environments and deployments](ci/environments.md) | With environments, you can control the continuous deployment of your software within GitLab. |
| [Environments and deployments](ci/environments/index.md) | With environments, you can control the continuous deployment of your software within GitLab. |
| [Environment-specific variables](ci/variables/README.md#limit-the-environment-scopes-of-environment-variables) | Limit the scope of variables to specific environments. |
| [GitLab CI/CD](ci/README.md) | Explore the features and capabilities of Continuous Deployment and Delivery with GitLab. |
| [GitLab Pages](user/project/pages/index.md) | Build, test, and deploy a static site directly from GitLab. |
@@ -134,7 +134,7 @@ The following table lists basic ports that must be open between the **primary**
See the full list of ports used by GitLab in [Package defaults](https://docs.gitlab.com/omnibus/package-information/defaults.html)
NOTE: **Note:**
[Web terminal](../../../ci/environments.md#web-terminals) support requires your load balancer to correctly handle WebSocket connections.
[Web terminal](../../../ci/environments/index.md#web-terminals) support requires your load balancer to correctly handle WebSocket connections.
When using HTTP or HTTPS proxying, your load balancer must be configured to pass through the `Connection` and `Upgrade` hop-by-hop headers. See the [web terminal](../../integration/terminal.md) integration guide for more details.
@@ -100,7 +100,7 @@ Learn how to install, configure, update, and maintain your GitLab instance.
-[Mattermost](https://docs.gitlab.com/omnibus/gitlab-mattermost/): Integrate with [Mattermost](https://mattermost.com), an open source, private cloud workplace for web messaging.
-[PlantUML](integration/plantuml.md): Create simple diagrams in AsciiDoc and Markdown documents
created in snippets, wikis, and repositories.
-[Web terminals](integration/terminal.md): Provide terminal access to your applications deployed to Kubernetes from within GitLab's CI/CD [environments](../ci/environments.md#web-terminals).
-[Web terminals](integration/terminal.md): Provide terminal access to your applications deployed to Kubernetes from within GitLab's CI/CD [environments](../ci/environments/index.md#web-terminals).
@@ -376,7 +376,7 @@ You might want to create another Envoy task to do that for you.
We also create the `.env` file in the same path to set up our production environment variables for Laravel.
These are persistent data and will be shared to every new release.
Now, we would need to deploy our app by running `envoy run deploy`, but it won't be necessary since GitLab can handle that for us with CI's [environments](../../environments.md), which will be described [later](#setting-up-gitlab-cicd) in this tutorial.
Now, we would need to deploy our app by running `envoy run deploy`, but it won't be necessary since GitLab can handle that for us with CI's [environments](../../environments/index.md), which will be described [later](#setting-up-gitlab-cicd) in this tutorial.
Now it's time to commit [Envoy.blade.php](https://gitlab.com/mehranrasulian/laravel-sample/blob/master/Envoy.blade.php) and push it to the `master` branch.
To keep things simple, we commit directly to `master`, without using [feature-branches](../../../topics/gitlab_flow.md#github-flow-as-a-simpler-alternative) since collaboration is beyond the scope of this tutorial.
A Review App is a mapping of a branch with an [environment](../environments.md).
A Review App is a mapping of a branch with an [environment](../environments/index.md).
Access to the Review App is made available as a link on the [merge request](../../user/project/merge_requests.md) relevant to the branch.
The following is an example of a merge request with an environment set dynamically.
...
...
@@ -49,7 +49,7 @@ After adding Review Apps to your workflow, you follow the branched Git flow. Tha
## Configuring Review Apps
Review Apps are built on [dynamic environments](../environments.md#configuring-dynamic-environments), which allow you to dynamically create a new environment for each branch.
Review Apps are built on [dynamic environments](../environments/index.md#configuring-dynamic-environments), which allow you to dynamically create a new environment for each branch.
The process of configuring Review Apps is as follows:
...
...
@@ -58,7 +58,7 @@ The process of configuring Review Apps is as follows:
1. Set up a job in `.gitlab-ci.yml` that uses the [predefined CI environment variable](../variables/README.md)`${CI_COMMIT_REF_NAME}`
to create dynamic environments and restrict it to run only on branches.
Alternatively, you can get a YML template for this job by [enabling review apps](#enable-review-apps-button) for your project.
1. Optionally, set a job that [manually stops](../environments.md#stopping-an-environment) the Review Apps.
1. Optionally, set a job that [manually stops](../environments/index.md#stopping-an-environment) the Review Apps.
### Enable Review Apps button
...
...
@@ -82,7 +82,7 @@ you can copy and paste into `.gitlab-ci.yml` as a starting point. To do so:
## Review Apps auto-stop
See how to [configure Review Apps environments to expire and auto-stop](../environments.md#environments-auto-stop)
See how to [configure Review Apps environments to expire and auto-stop](../environments/index.md#environments-auto-stop)
after a given period of time.
## Review Apps examples
...
...
@@ -100,7 +100,7 @@ See also the video [Demo: Cloud Native Development with GitLab](https://www.yout
> Introduced in GitLab 8.17. In GitLab 11.5, the file links are available in the merge request widget.
Route Maps allows you to go directly from source files
to public pages on the [environment](../environments.md) defined for
to public pages on the [environment](../environments/index.md) defined for
Review Apps.
Once set up, the review app link in the merge request
...
...
@@ -301,4 +301,4 @@ automatically in the respective merge request.
## Limitations
Review App limitations are the same as [environments limitations](../environments.md#limitations).
Review App limitations are the same as [environments limitations](../environments/index.md#limitations).
@@ -9,7 +9,7 @@ info: To determine the technical writer assigned to the Stage/Group associated w
> - [Introduced](https://gitlab.com/gitlab-org/gitlab/issues/13392) for group-level clusters in [GitLab Premium](https://about.gitlab.com/pricing/) 12.3.
> - [Introduced](https://gitlab.com/gitlab-org/gitlab/issues/14809) for instance-level clusters in [GitLab Premium](https://about.gitlab.com/pricing/) 12.4.
Cluster environments provide a consolidated view of which CI [environments](../../ci/environments.md) are
Cluster environments provide a consolidated view of which CI [environments](../../ci/environments/index.md) are
deployed to the Kubernetes cluster and it:
- Shows the project and the relevant environment related to the deployment.
- If you have managed Prometheus applications installed on multiple Kubernetes
clusters at the **same** level, the Prometheus application of a cluster with a
matching [environment scope](../../../ci/environments.md#scoping-environments-with-specs) is used.
matching [environment scope](../../../ci/environments/index.md#scoping-environments-with-specs) is used.
## Monitoring CI/CD Environments
...
...
@@ -154,7 +154,7 @@ environment which has had a successful deployment.
GitLab will automatically scan the Prometheus server for metrics from known servers like Kubernetes and NGINX, and attempt to identify individual environments. The supported metrics and scan process is detailed in our [Prometheus Metrics Library documentation](prometheus_library/index.md).
You can view the performance dashboard for an environment by [clicking on the monitoring button](../../../ci/environments.md#monitoring-environments).
You can view the performance dashboard for an environment by [clicking on the monitoring button](../../../ci/environments/index.md#monitoring-environments).
### Adding custom metrics
...
...
@@ -764,7 +764,7 @@ receivers:
...
```
In order for GitLab to associate your alerts with an [environment](../../../ci/environments.md), you need to configure a `gitlab_environment_name` label on the alerts you set up in Prometheus. The value of this should match the name of your Environment in GitLab.
In order for GitLab to associate your alerts with an [environment](../../../ci/environments/index.md), you need to configure a `gitlab_environment_name` label on the alerts you set up in Prometheus. The value of this should match the name of your Environment in GitLab.
@@ -73,22 +73,22 @@ For example, you may not want to enable a feature flag on production until your
first confirmed that the feature is working correctly on testing environments.
To handle these situations, you can enable a feature flag on a particular environment
with [Environment specs](../../../ci/environments.md#scoping-environments-with-specs).
with [Environment specs](../../../ci/environments/index.md#scoping-environments-with-specs).
You can define multiple specs per flag so that you can control your feature flag more granularly.
To define specs for each environment:
1. Navigate to your project's **Operations > Feature Flags**.
1. Click on the **New Feature Flag** button or edit an existing flag.
1. Set the status of the default [spec](../../../ci/environments.md#scoping-environments-with-specs)(`*`). Choose a rollout strategy. This status and rollout strategy combination will be used for _all_ environments.
1. If you want to enable/disable the feature on a specific environment, create a new [spec](../../../ci/environments.md#scoping-environments-with-specs) and type the environment name.
1. Set the status of the default [spec](../../../ci/environments/index.md#scoping-environments-with-specs)(`*`). Choose a rollout strategy. This status and rollout strategy combination will be used for _all_ environments.
1. If you want to enable/disable the feature on a specific environment, create a new [spec](../../../ci/environments/index.md#scoping-environments-with-specs) and type the environment name.
1. Set the status and rollout strategy of the additional spec. This status and rollout strategy combination takes precedence over the default spec since we always use the most specific match available.
1. Click **Create feature flag** or **Update feature flag**.
NOTE: **NOTE**
We'd highly recommend you to use the [Environment](../../../ci/environments.md)
We'd highly recommend you to use the [Environment](../../../ci/environments/index.md)
feature in order to quickly assess which flag is enabled per environment.
## Feature flag behavior change in 13.0
...
...
@@ -122,7 +122,7 @@ make a strategy apply to a specific environment spec:
