GitLab New Staging, 13 Jan 2022

Previous Meeting

Next Meeting

⏯

youtube image

►

From YouTube: Staging Ref Overview

Description

- Staging Ref documentation: https://about.gitlab.com/handbook/engineering/infrastructure/environments/staging-ref/
- Slides (GitLab only): https://docs.google.com/presentation/d/1K7CxBrX44ODZtLGWWwzy8Bm_BtTpPODP0p4IZX9H1qQ

0:00 - Intro
0:17 - Why the new Staging was needed?
1:18 - Staging Ref overview
1:51 - Environment information
2:17 - Deployment process
2:35 - How to use Staging Ref
3:24 - Future iterations and known limitations
3:40 - Feedback & Links

A

Hello, everyone: this is a quick overview of staging ref, a new staging sandbox environment that can be used for pre-production testing, with full access to the environment and control over the data in this video we'll go through why it was built and how you can use it.

A

The current staging is a close replica of our production environment and has several limitations. It has customer data, which is a blocker for giving more access to engineering, for example. Sometimes engineers can't test their features quickly on staging because they need to go through the process of requesting admin. Access staging requires stricter control over the environment as it's used in deployment process, for example. If something goes wrong, when an engineer made, a change on staging an environment needs to be fixed during this period, the deployment process will be blocked.

A

Also, staging is not performant and has api and web rate limits and test data limitations, so quality and infrastructure team collaborated on building a new staging environment that will resolve these issues. Please see more details in the epic staging ref was designed as a safe playground for engineers to test the latest staging canary code.

A

Staging deployments do not block the deployment process and environment can be tweaked or updated by any gitlab engineer. So gitlab engineers have wide perform wide permissions and full control over the environment. Also, staging rail follows 10k, hybrid architecture, so it's more performant than existing staging and could be used for load testing if needed.

A

Here's more detailed information about staging ref configuration, as mentioned before staging is a 10k cloud native, hybrid reference architecture where stateless components deployed to google kubernetes engine cluster and the remaining stateful components installed to gcp virtual machines. It is being deployed with github environment toolkit and deployer.

A

Staging ref deployment runs parallel to staging canary deployment and after successful deployment, sanity and full qa pipelines are triggered.

A

To sign in to the environment, navigate to staging ref, url and use your gitlab, google account to sign in feature flux can be enabled via tops command in stadium graph slack channel, and to promote your user to admin. Please send in as admin using the staging graph credentials from one password engineering world. Please note that staging ref environment is shared across all engineers. So if you plan to perform changes to gitlab admin, settings use the staging graph slack channel to communicate changes broadly.

A

If destructive changes are done to the environment or it ended up in a bad state after testing, it can be rebuilt on the request and to request access to gcp project and environment. Please follow guidance in the main staging graph documentation.

A

It's worth noting that staging ref environment work is still ongoing and there are known limitations currently listed on the slide. One of the main focuses next quarter will be the work on test data configurations.

A

If you have any questions or feedback, please reach out to engineering allocation, new, staging slack channel or raise an issue in staging graph, get config thanks for watching.