Add latest changes from gitlab-org/gitlab@15-2-stable-eev15.2.0-rc42

3 files changed, 83 insertions, 2 deletions

diff --git a/doc/ci/cloud_deployment/ecs/deploy_to_aws_ecs.md b/doc/ci/cloud_deployment/ecs/deploy_to_aws_ecs.md
index 9af5218e058..aea7b492d4e 100644
--- a/doc/ci/cloud_deployment/ecs/deploy_to_aws_ecs.md
+++ b/doc/ci/cloud_deployment/ecs/deploy_to_aws_ecs.md
@@ -223,7 +223,7 @@ These variables are injected into the pipeline jobs and can access the ECS API.
    |`AWS_SECRET_ACCESS_KEY`|`<Secret access key of the deployer>`| For authenticating `aws` CLI. |
    |`AWS_DEFAULT_REGION`|`us-east-2`| For authenticating `aws` CLI. |
    |`CI_AWS_ECS_CLUSTER`|`ecs-demo`| The ECS cluster is accessed by `production_ecs` job. |
-   |`CI_AWS_ECS_SERVICE`|`ecs_demo`| The ECS service of the cluster is updated by `production_ecs` job. |
+   |`CI_AWS_ECS_SERVICE`|`ecs_demo`| The ECS service of the cluster is updated by `production_ecs` job. Ensure that this variable is scoped to the appropriate environment (`production`, `staging`, `review/*`). |
    |`CI_AWS_ECS_TASK_DEFINITION`|`ecs_demo`| The ECS task definition is updated by `production_ecs` job. |
 
 ### Make a change to the demo application
@@ -246,6 +246,55 @@ NOTE:
 ECS deploy jobs wait for the rollout to complete before exiting. To disable this behavior,
 set `CI_AWS_ECS_WAIT_FOR_ROLLOUT_COMPLETE_DISABLED` to a non-empty value.
 
+## Set up Review Apps
+
+To use [Review Apps](../../../development/testing_guide/review_apps.md) with ECS:
+
+1. Set up a new [service](#create-an-ecs-service).
+1. Use the `CI_AWS_ECS_SERVICE` variable to set the name.
+1. Set the environment scope to `review/*`.
+
+Only one Review App at a time can be deployed because this service is shared by all review apps.
+
+## Set up Security Testing
+
+### Configure SAST
+
+To use [SAST](../../../user/application_security/sast/index.md) with ECS, add the following to your `.gitlab-ci.yml` file:
+
+```yaml
+include:
+   - template: Security/SAST.gitlab-ci.yml
+```
+
+For more details and configuration options, see the [SAST documentation](../../../user/application_security/sast/index.md#configuration).
+
+### Configure DAST
+
+To use [DAST](../../../user/application_security/dast/index.md) on non-default branches, [set up review apps](#set-up-review-apps)
+and add the following to your `.gitlab-ci.yml` file:
+
+```yaml
+include:
+  - template: Security/DAST.gitlab-ci.yml
+```
+
+To use DAST on the default branch:
+
+1. Set up a new [service](#create-an-ecs-service). This service will be used to deploy a temporary
+DAST environment.
+1. Use the `CI_AWS_ECS_SERVICE` variable to set the name.
+1. Set the scope to the `dast-default` environment.
+1. Add the following to your `.gitlab-ci.yml` file:
+
+```yaml
+include:
+  - template: Security/DAST.gitlab-ci.yml
+  - template: Jobs/DAST-Default-Branch-Deploy.gitlab-ci.yml
+```
+
+For more details and configuration options, see the [DAST documentation](../../../user/application_security/dast/index.md).
+
 ## Further reading
 
 - If you're interested in more of the continuous deployments to clouds, see [cloud deployments](../index.md).
diff --git a/doc/ci/cloud_deployment/heroku.md b/doc/ci/cloud_deployment/heroku.md
new file mode 100644
index 00000000000..4e627675b01
--- /dev/null
+++ b/doc/ci/cloud_deployment/heroku.md
@@ -0,0 +1,32 @@
+---
+stage: Release
+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
+---
+
+# Use GitLab CI/CD to deploy to Heroku
+
+You can deploy an application to Heroku by using GitLab CI/CD.
+
+## Prerequisites
+
+- A [Heroku](https://id.heroku.com/login) account.
+  Sign in with an existing Heroku account or create a new one.
+
+## Deploy to Heroku
+
+1. In Heroku:
+   1. Create an application and copy the application name.
+   1. Browse to **Account Settings** and copy the API key.
+1. In your GitLab project, create two [variables](../../ci/variables/index.md):
+   - `HEROKU_APP_NAME` for the application name.
+   - `HEROKU_PRODUCTION_KEY` for the API key
+1. Edit your `.gitlab-ci.yml` file to add the Heroku deployment command. This example uses the `dpl` gem for Ruby:
+
+   ```yaml
+   heroku_deploy:
+     stage: production
+     script:
+       - gem install dpl
+       - dpl --provider=heroku --app=$HEROKU_APP_NAME --api-key=$HEROKU_PRODUCTION_KEY
+   ```
diff --git a/doc/ci/cloud_deployment/index.md b/doc/ci/cloud_deployment/index.md
index c5be2328264..5df396e796e 100644
--- a/doc/ci/cloud_deployment/index.md
+++ b/doc/ci/cloud_deployment/index.md
@@ -93,7 +93,7 @@ To deploy to your ECS cluster:
    | Environment variable name      | Value                   |
    |:-------------------------------|:------------------------|
    | `CI_AWS_ECS_CLUSTER`           | The name of the AWS ECS cluster that you're targeting for your deployments. |
-   | `CI_AWS_ECS_SERVICE`           | The name of the targeted service tied to your AWS ECS cluster. |
+   | `CI_AWS_ECS_SERVICE`           | The name of the targeted service tied to your AWS ECS cluster. Ensure that this variable is scoped to the appropriate environment (`production`, `staging`, `review/*`). |
    | `CI_AWS_ECS_TASK_DEFINITION`   | If the task definition is in ECS, the name of the task definition tied to the service. |
    | `CI_AWS_ECS_TASK_DEFINITION_FILE` | If the task definition is a JSON file in GitLab, the filename, including the path. For example, `ci/aws/my_task_definition.json`. If the name of the task definition in your JSON file is the same name as an existing task definition in ECS, then a new revision is created when CI/CD runs. Otherwise, a brand new task definition is created, starting at revision 1. |