Merge branch 'docs-ci-release-tier' into 'master'

Add tier info to Release CI docs

See merge request gitlab-org/gitlab!66746

doc/ci/cloud_deployment/index.md

@@ -5,7 +5,7 @@ info: To determine the technical writer assigned to the Stage/Group associated w
 type: howto
 ---
 
-# Cloud deployment
+# Cloud deployment **(FREE)**
 
 Interacting with a major cloud provider may have become a much needed task that's
 part of your delivery process. With GitLab you can

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

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
@@ -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.
 

doc/ci/examples/authenticating-with-hashicorp-vault/index.md

@@ -5,7 +5,7 @@ info: To determine the technical writer assigned to the Stage/Group associated w
 type: tutorial
 ---
 
-# Authenticating and Reading Secrets With HashiCorp Vault
+# Authenticating and reading secrets with HashiCorp Vault **(PREMIUM)**
 
 This tutorial demonstrates how to authenticate, configure, and read secrets with HashiCorp's Vault from GitLab CI/CD.
 

doc/ci/examples/deployment/composer-npm-deploy.md

@@ -5,7 +5,7 @@ info: To determine the technical writer assigned to the Stage/Group associated w
 type: tutorial
 ---
 
-# Running Composer and npm scripts with deployment via SCP in GitLab CI/CD
+# Running Composer and npm scripts with deployment via SCP in GitLab CI/CD **(FREE)**
 
 This guide covers the building of dependencies of a PHP project while compiling assets via an npm script using [GitLab CI/CD](../../README.md).
 

doc/ci/examples/deployment/index.md

@@ -5,7 +5,7 @@ info: To determine the technical writer assigned to the Stage/Group associated w
 type: tutorial
 ---
 
-# Using Dpl as deployment tool
+# Using Dpl as a deployment tool **(FREE)**
 
 [Dpl](https://github.com/travis-ci/dpl) (pronounced like the letters D-P-L) is a deploy tool made for
 continuous deployment that's developed and used by Travis CI, but can also be
@@ -105,18 +105,18 @@ production:
 
 We created two deploy jobs that are executed on different events:
 
-1. `staging` is executed for all commits that were pushed to `master` branch,
-1. `production` is executed for all pushed tags.
+- `staging`: Executed for all commits pushed to the `master` branch
+- `production`: Executed for all pushed tags
 
 We also use two secure variables:
 
-1. `HEROKU_STAGING_API_KEY` - Heroku API key used to deploy staging app,
-1. `HEROKU_PRODUCTION_API_KEY` - Heroku API key used to deploy production app.
+- `HEROKU_STAGING_API_KEY`: Heroku API key used to deploy staging app
+- `HEROKU_PRODUCTION_API_KEY`: Heroku API key used to deploy production app
 
 ## Storing API keys
 
 To add secure variables, navigate to your project's
-**Settings > CI/CD > Variables**. The variables that are defined
+**Settings > CI/CD > Variables**. The variables defined
 in the project settings are sent along with the build script to the runner.
 The secure variables are stored out of the repository. Never store secrets in
 your project's `.gitlab-ci.yml`. It is also important that the secret's value
@@ -125,7 +125,7 @@ is hidden in the job log.
 You access added variable by prefixing it's name with `$` (on non-Windows runners)
 or `%` (for Windows Batch runners):
 
-1. `$VARIABLE` - use it for non-Windows runners
-1. `%VARIABLE%` - use it for Windows Batch runners
+- `$VARIABLE`: Use for non-Windows runners
+- `%VARIABLE%`: Use for Windows Batch runners
 
 Read more about the [CI/CD variables](../../variables/index.md).

doc/ci/review_apps/index.md

@@ -5,19 +5,14 @@ info: To determine the technical writer assigned to the Stage/Group associated w
 type: reference
 ---
 
-# Review Apps
+# Review Apps **(FREE)**
 
-> - [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/-/issues/21971) in GitLab 8.12. Further additions were made in GitLab 8.13 and 8.14.
-> - Inspired by [Heroku's Review Apps](https://devcenter.heroku.com/articles/github-integration-review-apps), which itself was inspired by [Fourchette](https://github.com/rainforestapp/fourchette).
-
-Review Apps is a collaboration tool that takes the hard work out of providing an environment to showcase product changes.
+Review Apps is a collaboration tool that assists with providing an environment to showcase product changes.
 
 NOTE:
 If you have a Kubernetes cluster, you can automate this feature in your applications
 by using [Auto DevOps](../../topics/autodevops/index.md).
 
-## Introduction
-
 Review Apps:
 
 - Provide an automatic live preview of changes made in a feature branch by spinning up a dynamic environment for your merge requests.
@@ -27,7 +22,7 @@ Review Apps:
 
 ![Review Apps Workflow](img/continuous-delivery-review-apps.svg)
 
-In the above example:
+In the previous example:
 
 - A Review App is built every time a commit is pushed to `topic branch`.
 - The reviewer fails two reviews before passing the third review.
@@ -107,8 +102,6 @@ Other examples of Review Apps:
 
 ## Route Maps
 
-> 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/index.md) defined for
 Review Apps.

doc/ci/secrets/index.md

@@ -5,7 +5,7 @@ info: To determine the technical writer assigned to the Stage/Group associated w
 type: concepts, howto
 ---
 
-# Using external secrets in CI
+# Using external secrets in CI **(FREE)**
 
 > - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/218746) in GitLab 13.4 and GitLab Runner 13.4.
 > - `file` setting [introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/250695) in GitLab 14.1 and GitLab Runner 14.1.