The following page may contain information related to upcoming products, features and functionality. It is important to note that the information presented is for informational purposes only, so please do not rely on the information for purchasing or planning purposes. Just like with all projects, the items mentioned on the page are subject to change or delay, and the development, release, and timing of any products, features or functionality remain at the sole discretion of GitLab Inc.
This glossary is meant to serve as a guide to help team members and users discuss topics related to the Ops sub-department and more specifically application delivery. It aims to achieve the following:
The terms and their definitions outlined in this document are provided in context specifically for the GitLab product. Therefore, these terms may have different meanings to users outside of GitLab.
An application consists of one or more artifacts and a set of configurations. The artifacts likely package software code directly or as embedded/referenced artifacts. The configurations might be connected to one or more released versions.
Some of the artifacts in a release might come from an application, but a release might contain artifacts that are not an application.
There is always only 1 copy of each application in an environment.
Nota bene, that a single GitLab project might host multiple applications (e.g: kas and agentk are hosted in a single repo).
An artifact is the result of a set of actions, typically identified by an address or an ID in the system. It's considered immutable and must contain the following cryptographically signed attributes:
A list of all the sources and tools that were used to produce it for traceability.
These results need to be cryptographically signed so that a third party can trust that the creator of the artifact didn't forge them.
A configuration is an immutable set of key value pairs denoting the rules or settings for a particular application. The configuration can be identified by a unique hash and is part of a deployment. It's populated by data coming from:
In the case of gitlab.com, configuration is stored in:
Defaults baked into the application is part of the release * we don’t consider these configurations.
A deployment is an application instance configured for a given environment. There can be one or more deployments within each environment.
Deploying is the potentially long-running act of updating an environment with a new version of the application and the relevant configuration.
Disambiguation: Environments in the context of GitLab might refer to IDEs as well. When disambiguation is needed, we should call the environments in the delivery domain "application environments".
An environment is a logical concept that describes part of its target infrastructure with a rich set of metadata. It
Environments can be of different types:
Every environment has a single target infrastructure, a target infrastructure might have many environments. Thus multi-region setups require multiple environments.
You can have multiple instances of a given type (for example by region, provider, applications served). It’s useful to query the system by environment type, to be able to build dashboards around environment types.
Environments might be dynamically created during the pipeline execution, they might be templated.
GitLab environments. Examples: gprd, gstg, pre
A release is a special case of an artifact, as it is the artifact to be delivered. The delivery might mean a deployment to an environment or making it available to download.
A rollout is the action of putting an already deployed application in front of its users. This might happen in many ways:
The rollout step might happen together with a deployment or as a separate action.
A rollout might take many forms. For example:
As noted above, there are two big approaches to rollout. The following table summarizes provides a comparison:
| Feature flag | Network level |
|---|---|
| Changes the executed code path within a single deployment. | Changes the network traffic routing between deployments. |
| Typically manual rollout | Could be automatised based on error rates and metrics |
| A property of the environment. All the running deployments receive the same feature flag values. | A shared property of environment and deployment. Every deployment has its own rollout state. |
While we have two different approaches to rollout. We decided to refer to them as rollout for now. We will update the glossary if needed.
Secrets are part of the Configuration, typically key-value pairs that allow privileged or secure access between two or more components. Their management requires special attention, but it's outside the scope of this discussion. See the Secrets Management category direction on our approach to secrets.
A target infrastructure in an immutable entity that contains one or more environment, along with applications that run in that environment. A target infrastructure typically runs multiple applications, but is not application specific.
From GitLab's perspective, target infrastructures are considered external systems. The target infrastructure is responsible for the authenticating of GitLab with the infrastructure. Authorization is managed based on the respective best practices of the given infrastructure (e.g. IAM, RBAC). Accesses may be restricted to certain jobs or users and may be logged for compliance and be programmable. For example, retrieving and returning a JWT token.
