First class concept for production environments

Problem

Today, we don't have an explicit identifier about which environment is the "production" environment. Typically, one production environment exists per project. This identification is crucial in our features, for example, our DORA 4 metrics features explicitly target the production environment for data collection.

To illustrate the problem, please see the following examples.

When user defines a deployment job to a production environment, they script in .gitlab-ci.yml like:

deploy-to-production:
  script: echo 'Deploy to production'
  environment: production

This gives us an assumption that all production environments are defined with environment: production (or environment:name: production), however, if the name of their production environment is something else, such as "gprd" or "customer-portal", the definition doesn't align with the assumption:

deploy-to-production:
  script: echo 'Deploy to production'
  environment: gprd

The main problem on the current syntax is that the actual meaning of environment:name: differs per usecase:

1. It's a label/codename for the application on the environment.
2. It's a identifier for the production environment.

To align the system level expectation and end-user's level expectation for the "production" environment, we should provide an explicit identifier that which environment is "production".

Proposal

We introduce a new keyword environment:deployment_tier: in .gitlab-ci.yml.

• environment:name: <name> (or environment: <name>) ... This is the label/codename for the application on the enviornment.
• environment:deployment_tier: <name> ... This is the identifier that the environment is either production, staging, testing, development or other.

deploy-to-production:
  script: echo 'Deploy to production'
  environment:
    name: gprd
    deployment_tier: production 

If environment:deployment_tier: is not explicitly specified, GitLab automatically guesses the type from environment:name:. For example, environment: production will automatically set the type as production, however, environment: customer-portal will be other. So it's not 100% accurate.

FYI, this is same type structure with Jira's Environment Data model.

The terminology deployment_tier was suggested by @ogolowinski.

UX

We show the deployment_tier on environment index page. (Maybe next iteration)

Further iteration

This feature will enhance the design of Group-Level Protected environments. Sometimes, the definition of production environment (environment:name:) differs per project, so that hard to protect the production environments by its name. With this type, users can rule it by types. For example,:

• At group-level, operators create a protected environment rule:
  • production and staging deployment_tiers of environments can be created/modified by operator group.
  • testing and development deployment_tier of environments can be created/modified by anyone (e.g. operators and developers).
  • NOTE: This automatically disables all subsequent group/project-level protected environment rules.