Staging Ref is a sandbox environment used for pre-production testing of the latest Staging Canary code with full access to the environment and control over data.
| Name | URL | Purpose | Deploy | Database | Terminal access | Slack channel |
|---|---|---|---|---|---|---|
| Staging Ref | staging-ref.gitlab.com | Pre-production testing | Frequently (Parallel to gstg-cny) |
Separate and local | All engineers | #staging-ref |
gstg) has customer data which is a blocker for giving more access to Development and Quality teams.snowplow.trx.gitlab.netStaging Ref deployment runs parallel to Staging Canary deployment. Deployer triggers a job in Staging-Ref GET Config to update the environment. Notifications about new deployments are sent to the #announcements Slack channel.
Staging Ref pipelines do not block the deployment. If there are any failures with deployment to gstg-ref, please reach out to @release-managers. After successful deployment, Sanity and Full QA pipelines are triggered. Results are posted to #qa-staging-ref and analysed by Quality on-call DRIs. Please refer to the Quality Department pipeline triage rotation schedule to identify the current DRI.
Staging Ref is a safe playground for engineers who want to test latest Staging(gstg-cny) code. Staging Ref has several advantages that allow it to be a full-fledged sandbox environment:
gstg) and could be used for load testing if needed.To sign in to the environment, navigate to staging-ref.gitlab.com and use your GitLab Google account in 'Sign in with Google' option.
After signing in you can proceed using the environment as required. If destructive changes were done to the environment or it ended up in a bad state after testing, create a request to rebuild the environment. Please reach out to the #staging-ref Slack channel or raise an issue in Staging-Ref GET Config. The process is automated with Staging-Ref GET Config and will take about an hour to finish.
ChatOps commands can be used to enable or disable Feature Flags on Staging Ref. You can run this command in the #staging-ref Slack channel and notifications will be sent to #qa-staging-ref after a flag is enabled/disabled.
To promote your user to Admin, please sign in as Admin using the Staging Ref credentials from 1Password Engineering vault. Then navigate to the Admin Area’s Users page and edit your user's Access Level.
Note that Staging Ref environment is shared across all engineers. If you plan to perform changes to GitLab Admin settings, use the #staging-ref Slack channel to communicate changes broadly.
If you need access to Staging Ref components in the GCP project(gitlab-staging-ref), please reach out in the #staging-ref Slack channel. Quality Engineering Managers can add you to gcp-staging-ref-sg@gitlab.com Google group.
As another option you can create an issue in the access-request project. Requests for access to server environments requires the approval of your manager and an Infrastructure manager.
A simplified process to request SSH access to Staging Ref virtual machines and the GKE cluster is being worked on in issue#343938.
Note that GitLab configuration changes will be overwritten by a new deployment to the environment. Environment updates can be locked if needed by a request to @release-managers in the #staging-ref Slack channel.
Sanity or Full QA pipeline may be triggered on demand in staging-ref project. Please reach out to Quality on-call DRIs if there are any questions.
Monitoring implementation was done in (epic#594). Documentation can be found in the runbooks.
Dashboards for Staging Ref can be found in Grafana under the staging-ref folder. Other existing dashboards may also show Staging Ref information if you select environment=gstg-ref. If you need some specific dashboard or some existing dashboard doesn't work please reach out to Infrastructure team Slack channel or in #new-staging-for-mixed-deployments channel.
By default, all users and groups are on the Free plan. To upgrade a paid plan use Admin account and do the following:
Watch this demo to see an example when a group was promoted to Premium plan.
Staging Ref environment has pre-existing accounts that can be used for testing. For example, Admin accounts on different paid plans, Auditor user, QA users. All credentials are stored in Staging Ref credentials in 1Password Engineering vault.
An Okta application has been setup to act as SAML idP for https://staging-ref.gitlab.com/groups/saml-sso-group.
Two users with names gitlab-qa-saml-sso-user1 and gitlab-qa-saml-sso-user2 have been created and added to Okta and assigned the application. These users are also available in staging-ref environment.
Please note that all credentials and values for fields mentioned below are saved in 1Password Engineering Vault in "Staging Ref credentials" under "User credentials for saml-sso-group Group".
For using SAML SSO, you will need to:
The first time you visit https://staging-ref.gitlab.com/groups/saml-sso-group and try to login, you will be asked to sign in to GitLab with an existing account to
link the SAML identity. Use username gitlab-qa-saml-sso-user1 or gitlab-qa-saml-sso-user2 to sign in. The credentials are in 1Password.
Staging Ref environment has some known limitations that will be worked on:
If you need some additional custom configuration for Staging Ref to be explored or you have other feedback and ideas for improvements, please reach out to #eng-allocation-new-staging Slack channel or add a comment to the feedback issue#350744.
