First class concept for production environments
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:
- It's a label/codename for the application on the environment.
- 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".
We introduce a new keyword
environment:deployment_tier: in .gitlab-ci.yml.
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
deploy-to-production: script: echo 'Deploy to production' environment: name: gprd deployment_tier: production
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
environment: customer-portal will be
other. So it's not 100% accurate.
FYI, this is same type structure with Jira's Environment Data model.
deployment_tier was suggested by @ogolowinski.
We show the deployment_tier on environment index page. (Maybe next 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:
stagingdeployment_tiers of environments can be created/modified by operator group.
developmentdeployment_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.