@@ -15,7 +15,7 @@ description: "Realm for the engineering infrastructure team to deploy shared and
This realm is for the engineering infrastructure team to deploy shared and team-specific infrastructure resources that aren't appropriate for the `saas` realms.
The [Engineering Infrastructure Environments handbook page](/handbook/engineering/infrastructure/environments/) is the current SSOT for environments. As the WIP initiative to iterate on our company-wide infrastructure standards evolves, the Engineering Infrastructure pages will be refactored incrementally as the standards are documented, implemented, and changes to environments take place.
The [Engineering Infrastructure Environments handbook page](/handbook/engineering/infrastructure-platforms/environments/) is the current SSOT for environments. As the WIP initiative to iterate on our company-wide infrastructure standards evolves, the Engineering Infrastructure pages will be refactored incrementally as the standards are documented, implemented, and changes to environments take place.
The [Engineering Infrastructure Environments handbook page](/handbook/engineering/infrastructure/environments/) is the current SSOT for environments. As the WIP initiative to iterate on our company-wide infrastructure standards evolves, the Engineering Infrastructure pages will be refactored incrementally as the standards are documented, implemented, and changes to environments take place.
The [Engineering Infrastructure Environments handbook page](/handbook/engineering/infrastructure-platforms/environments/) is the current SSOT for environments. As the WIP initiative to iterate on our company-wide infrastructure standards evolves, the Engineering Infrastructure pages will be refactored incrementally as the standards are documented, implemented, and changes to environments take place.
The [Engineering Infrastructure Environments handbook page](/handbook/engineering/infrastructure/environments/) is the current SSOT for environments. As the WIP initiative to iterate on our company-wide infrastructure standards evolves, the Engineering Infrastructure pages will be refactored incrementally as the standards are documented, implemented, and changes to environments take place.
The [Engineering Infrastructure Environments handbook page](/handbook/engineering/infrastructure-platforms/environments/) is the current SSOT for environments. As the WIP initiative to iterate on our company-wide infrastructure standards evolves, the Engineering Infrastructure pages will be refactored incrementally as the standards are documented, implemented, and changes to environments take place.
@@ -51,14 +51,14 @@ A package is deployed to GitLab.com in the following steps:
1. At regular intervals, an automated task in release-tools searches for the latest available package that has completed building.
1a. When a built package is found, it is automatically deployed to gstg-cny, [the canary stage of staging.gitlab.com](/handbook/engineering/infrastructure/environments/#staging-canary).
1a. When a built package is found, it is automatically deployed to gstg-cny, [the canary stage of staging.gitlab.com](/handbook/engineering/infrastructure-platforms/environments/#staging-canary).
1b. In parallel, the same package is deployed to the [Staging-ref environment, gstg-ref](/handbook/engineering/infrastructure/environments/#staging-ref)
1b. In parallel, the same package is deployed to the [Staging-ref environment, gstg-ref](/handbook/engineering/infrastructure-platforms/environments/#staging-ref)
1. A set of automated QA end-to-end/integration tests are run. Note that two sets of blocking QA tests are executed, one targeting gstg-cny and the other targeting staging (gstg). This is designed to assist with exposing issues arising in mixed deployment environments, where multiple versions of GitLab components are deployed that share services such as the database
1. After passing, the package is automatically deployed to gprd-cny, [the canary stage of gitlab.com](/handbook/engineering/infrastructure/environments/#production-canary), where [covering the canary stage and how to use it](/handbook/engineering/infrastructure/environments/canary-stage) can take place. This means that specific projects (like `gitlab-org/gitlab`) as well as a small amount of end user traffic will be using the new package.
1. After passing, the package is automatically deployed to gprd-cny, [the canary stage of gitlab.com](/handbook/engineering/infrastructure-platforms/environments/#production-canary), where [covering the canary stage and how to use it](/handbook/engineering/infrastructure-platforms/environments/canary-stage) can take place. This means that specific projects (like `gitlab-org/gitlab`) as well as a small amount of end user traffic will be using the new package.
1. Like with deployment to staging-canary above, two sets of automated QA end-to-end/integration tests are run. One targets the canary stage of production, the other targets the main stage (to ensure the new and old code are still functional). Note that the `smoke` and `reliable` tests targeting production canary (gprd-cny) are blocking.
1. After 30 minutes in the [canary stage of gitlab.com](/handbook/engineering/infrastructure/environments/#production-canary), and provided no new exceptions or alerts are reported, the package is considered to be ready for deployment to [gitlab.com](/handbook/engineering/infrastructure/environments/#production) and [staging.gitlab.com](/handbook/engineering/infrastructure/environments/#staging)
1. The promotion to [gitlab.com](/handbook/engineering/infrastructure/environments/#production) and [staging.gitlab.com](/handbook/engineering/infrastructure/environments/#staging) is triggered manually by the release
1. After 30 minutes in the [canary stage of gitlab.com](/handbook/engineering/infrastructure-platforms/environments/#production-canary), and provided no new exceptions or alerts are reported, the package is considered to be ready for deployment to [gitlab.com](/handbook/engineering/infrastructure-platforms/environments/#production) and [staging.gitlab.com](/handbook/engineering/infrastructure-platforms/environments/#staging)
1. The promotion to [gitlab.com](/handbook/engineering/infrastructure-platforms/environments/#production) and [staging.gitlab.com](/handbook/engineering/infrastructure-platforms/environments/#staging) is triggered manually by the release
managers. Ongoing incidents or Change Requests with the `blocks deployments` label will prevent a package from being deployed to gstg (staging) and gprd (production). Note that deployments to canary (both gstg-cny and gprd-cny)
will not be blocked. Migrations will also not be blocked since they are executed during canary deployments. However, post deploy migrations will be blocked.
