GitLab Professional Services
Accelerate your software lifecycle with help from GitLab experts
Popular GitLab use cases
Enterprise Small Business Continuous Integration (CI/CD) Source Code Management (SCM) Out-of-the-box Pipelines (Auto DevOps) Security (DevSecOps) Agile Development Value Stream Management GitOpsGitLab Professional Services
Accelerate your software lifecycle with help from GitLab experts
Popular GitLab use cases
Enterprise Small Business Continuous Integration (CI/CD) Source Code Management (SCM) Out-of-the-box Pipelines (Auto DevOps) Security (DevSecOps) Agile Development Value Stream Management GitOpsThis handbook section defines the latest iteration of infrastructure standards for AWS and GCP across all departments and groups at GitLab. These standards were created by a cross-department collaboration in this Compute Sandbox Issue 3 (Budget and Cost Allocation) issue and Infrastructure Epic 257 (Provide cloud resources for non-production usage).
Each realm owner, department, or infrastructure community member can adopt these standards as they iterate their infrastructure.
#wg_infrastructure-standards
Slack channel for architectural questions with the realm owners or #compute-sandbox
for non-production infrastructure needs.For cloud infrastructure, we have created top-level AWS organizational units and GCP folders under the respective cloud provider master account that we refer to as "realms".
You can think of each realm as a domain or namespace that provides flexibility for department(s) and group(s) that use that realm to customize their infrastructure configuration and security policies as needed without affecting other departments or realms at GitLab.
Our realms are designed based on which department is the DRI (realm owner) and purposefully reducing the blast radius and security vulnerability based on the infrastructure resources that are deployed in each realm. You can find our pre-defined mapping of realms and department groups in the Department Group Collaboration Environments section below.
Are you looking to deploy a production or production-like service? All engineering or product related production infrastructure should be deployed and managed in the saas
realm that is managed by the Engineering Infrastructure team with SRE on-call coverage. All business (non-engineering) production infrastructure should be deployed in the business-ops
realm in the GCP project or AWS account specified by the security team.
What is defined as non-production?
Are you looking for an AWS account or GCP project to deploy resources in that you will share with your team? We have created a GCP project for each department group in the GitLab infrastructure community to allow each group to collaborate efficiently and provision the infrastructure that you need for shared purposes.
Are you an engineer looking for a sandbox or testing AWS account or GCP project? Please use the Compute Sandbox which gives you access to your own private AWS account or GCP project that grants you owner permissions and has centrally managed billing with the GitLab master account.
Value | Human Friendy Name | Description |
---|---|---|
saas |
GitLab SaaS | This is for GitLab.com SaaS that is managed by Engineering Infrastructure and Site Reliability Engineers. |
gitter |
Gitter SaaS | This is for Gitter hosted services. |
sandbox |
Compute Sandbox Cloud | This is for sandbox and ephemeral testing resources that provides an account/project for each user that are self-administered by each team member. |
Approximately ~750 of the ~1,300 GitLab team members are in departments that use cloud infrastructure for development, experiment, testing or non-production purposes. For documentation purposes, we refer to this as the GitLab infrastructure community.
For any groups that are not part of the GitLab infrastructure community, please reach out to Business Operations for assistance with having your infrastructure created in the business-ops
realm.
You can find the full list departments, stages, and groups on the labels and tags handbook page. You can learn more about each department in the organization chart. You can learn more about the engineering stages and groups on the product categories handbook page.
Realm | Usage | Departments/Groups |
---|---|---|
business-ops Business Operations and IT Realm Docs |
This is for resources managed by the Business Operations and IT team, including all departments and groups that do not have their own realm. |
ga-accounting-x ga-business-ops-x ga-ceo-x ga-finance-x ga-legal-x ga-people-x ga-recruiting-x mktg-x sales-alliances-x sales-channel-x sales-commercial-x sales-ent-x sales-field-ops-x sales-practice-mgmt-x |
eng-dev Engineering Development Realm Docs |
This is for additional services managed by Engineering Development (including `eng-ux` and `product` department resources) that don't belong in `saas`, `eng-infra`, or `sandbox` realms. |
eng-dev-manage-x eng-dev-plan-x eng-dev-create-x eng-dev-verify-x eng-dev-package-x eng-dev-release-x eng-dev-configure-x eng-dev-monitor-x eng-dev-secure-x eng-dev-protect-x eng-dev-growth-x eng-dev-enablement-x eng-quality-x eng-ux-x product-mgmt-x |
eng-infra Engineering Infrastructure Realm Docs |
This is for additional services managed by Engineering Infrastructure and Site Reliability Engineers that may not be specific to GitLab.com SaaS (Ex. tools, release and package management services, etc). |
eng-infra-x |
eng-security Engineering Security Realm Docs |
This is for resources managed by the Security team. |
eng-security-x |
eng-support Engineering Customer Support Realm Docs |
This is for resources managed by the Customer Support team. |
eng-support-x |
sales-cs Customer Success Realm Docs |
This is for resources managed by the Customer Success team, including demo and training systems. |
sales-cs-demo-cloud-x sales-cs-training-cloud sales-cs-sa-x sales-cs-tam-x sales-cs-ps-x |
Want to add a realm? Any departments without their own realm should have resources for their groups (teams) created in the business-ops
realm. If there are enough cloud resources and a dedicated infrastructure engineer team member to justify creating a new realm, please see the instructions for creating a new infrastructure realm.
dev-resources
and support-resources
dev-resources
and support-resources
Terraform projects that are used by the engineering development and support teams. There is no deprecation timeline or migration plan yet.
In the spirit of iteration and efficiency, we're working on standardizing how we create and manage ephemeral (sandbox) infrastructure that GitLab team members provision.
The oversimplified user story is "I need to spin up VM(s) or cluster(s) in GCP or AWS to try something (anything, may not be GitLab product specific), what's the company infrastructure standards for doing that?"
The Sandbox Cloud is a custom-built web application that automates the provisioning of an AWS account or GCP project for each GitLab team member that needs one for ephemeral sandbox and testing use cases.
The goal is to create a frictionless approach for technical team members that includes the tagging needed for cost allocation, best practice security configurations, and provide you the ability to create any resources that you need using the AWS or GCP web console or use our shared library of Terraform modules that include documentation and usage examples that can be copied into the Terraform configuration file for each user account. When you sign in with OKTA, we use the OKTA meta data that is integrated with BambooHR to determine your department and entity for cost reporting, and use this for the auto-creation of a tagging policy for resources that you create.
Learn more on the sandbox realm handbook page.
Each realm has one or more team members that are system owners that are the DRI or stable counterparts responsible for all of the infrastructure architecture, billing, resource provisioning and security policies in that realm.
Each realm DRI or counterpart is an engineering manager or experienced infrastructure engineer who can perform all actions needed for day-to-day management of the realm, including responding to security incidents and supporting group owners and counterparts in their realm.
Each of the GitLab department groups that have a GCP project within a realm have a Group DRI and counterparts that provide day-to-day support for users in their realm and escalate to realm DRIs or counterparts as needed.
Our infrastructure standards are designed to provide a well defined baseline with guidelines for customization by realm owners as needed within their realm.
The AWS architecture is currently being designed. Please create a GitLab issue and tag jeffersonmartin
, dawsmith
, and jurbanc
for assistance in the interim.