GitLab Glossary

Sakshi . -

Introduction

In the realm of version control and CI/CD tools, navigating GitLab's functionalities can be intricate without a grasp of key terms and concepts.

Explore our GitLab Glossary to uncover important definitions related to version control, continuous integration, and software development. Elevate your understanding effortlessly and enhance your knowledge of GitLab's systems.

GitLab Terms

A

Application: An application is made up of one or more services and a set of configurations. These configurations can be connected to different release items and environments. Applications are a way to group related services together for business and operational purposes, with only one copy of each application existing in an environment. It's important to note that a single GitLab project can contain multiple applications, like GitLab Switchboard and Amazon Checkout, even though they are housed in the same repository.

Artifact: An artifact is the outcome of a set of actions, typically identified by an address or ID within the system. It's considered immutable and must include the following cryptographically signed attributes: a list of sources and tools used for traceability, binary addresses with size and hash, links to source repos and builds, author or creator, and other metadata such as security scan results, scanner version, and configuration. These results must be cryptographically signed to ensure a third party can trust the creator didn't forge them.  

Examples:

Docker images:

  • Gitaly, kas, main Rails app, Runner, Shell, etc

Helm charts with default values

CI artifacts:

  • Source code scans, Container image scans, code coverage, unit test reports, license compliance checks

Terraform plan

Archives of directories:

  • Kpt package

B

Browser Performance Testing: GitLab's Browser Performance Testing metrics collect Browser Performance report as artifacts.

C

Configuration: A configuration consists of unchangeable key-value pairs that define the rules or settings for a specific service within a particular environment. Each configuration, uniquely identified by a hash, forms part of a deployment and is filled with data sourced from various channels: service and environment-specific setups by either the Application Operator or the Platform Engineer, service-specific configurations by the Application Operator, processes or the platform within GitLab (like the user ID running a pipeline), and target infrastructures established by the Platform Engineer. These configurations can be linked to one or more release artifacts associated with a particular service, creating a structured framework for managing and maintaining service settings across different environments.

Examples:

In the context of gitlab.com, the configuration is stored in several places:

  1. Configuration files within the repository
  2. Environment-specific configuration defined in the CI definition within the repository
  3. Helm charts, including their default values, which are part of the release

It's important to note that defaults baked into the application itself are not considered part of the configuration, but rather part of the release.

D

Deployment: A deployment involves placing a released artifact into a particular service environment. Typically, only one active deployment is present in an environment. However, in more complex deployment scenarios like Blue/Green and Canary deployments, multiple active deployments may coexist simultaneously. Deployment is the process of potentially lengthy duration that involves updating an environment with a new version of the release artifact and its corresponding configuration. It's important to note that for end-users to access a deployment, it must undergo a rollout process.

E

Environment: Examples of environments in the context of GitLab include Production, Staging, Testing, and Development. It's important to note that the term "environment" can also refer to IDEs, in which case we should specify "application environments" to disambiguate. An environment is a logical concept that connects GitLab to a target infrastructure, allowing it to access that infrastructure for deployments and monitoring, and containing environment-specific variables (a subset of environment variables) that can be used to deploy to the target infrastructure.

Example:

  • GitLab environments, such as gprd, gstg, and pre, are set up using Terraform.
  • The release artifact version could be saved in the repository along with the deployment configuration.
  • The deployment version within an environment is integral to the service's state.
  • A record of deployments: each deployment corresponds to a CI job within an environment.

G

GitLab CI/CD: GitLab CI/CD is a tool for automating the build, test, and deployment of software.

GitLab Pages: GitLab Pages is a feature for uploading the result of a job to use with GitLab Pages.

I

Image: The Image keyword uses Docker images.

Inherit: The Inherit keyword selects which global defaults all jobs inherit.

Interruptible: The Interruptible keyword defines if a job can be canceled when made redundant by a newer run.

J

Job: A job is defined as a list of keywords that define the job's behavior.

P

Parallel: The Parallel keyword runs a job multiple times in parallel in a single pipeline.

Pipeline: A pipeline is a sequence of jobs that are executed in a specific order.

Private Token: A Private Token is used to authenticate with the GitLab API.

Projects: Projects are the repositories of code and data that are managed by GitLab.

R

Release artifact: A release artifact, also known simply as a release, is a specialized type of artifact that is intended for delivery. This could mean deploying it to an environment or making it available for download. A release artifact may include multiple artifacts, either directly or by referencing them. In addition to referencing other artifacts, the release artifact also contains any deployed configurations in some form. While some of the artifacts within a release may be part of the deployment, a release may also contain artifacts that are not deployed, such as metadata like scan results.

Rollout: A rollout involves presenting a deployment to its users, which can occur through various methods. This could involve modifying the infrastructure, such as configuring a load balancer, or adjusting the application code flow using a feature flag, which doesn't necessitate a new deployment. The rollout process may occur concurrently with a deployment or as a distinct action. A rollout might take many forms. For example: blue-green, canary, user or group based, random percentile-based, region based, device based.

S

Secrets: Secrets, such as key-value pairs that enable privileged or secure access between components, are considered part of the configuration. The management of these secrets requires special care and attention.

Service: Examples of services within an application include the Search API, Search UI, Frontend, Backend, Database, Caching, and Monitoring. A service is a logical concept that represents a largely independent, loosely coupled component of the application, responsible for specific functionalities. For external consumers, each service exposes a set of APIs. Services may be structurally managed by a container orchestration framework like Kubernetes. Alternatively, a service could be provided by an external organization, such as using Amazon RDS instead of running a database in Kubernetes. The health of a service can be observed through metrics, logs, traces, and error tracking. Additionally, each service has a history of deployments for the environments in which it has been deployed.

Stage: A Stage is a group of jobs that are executed in a specific order.

T

Target infrastructure: An immutable entity known as a target infrastructure encompasses one or more environments and the applications operating within them. While a target infrastructure typically supports multiple applications, it is not specific to any single application. From GitLab's viewpoint, target infrastructures are regarded as external systems. The target infrastructure plays a crucial role in authenticating GitLab with the infrastructure, with authorization being governed by the established best practices of the specific infrastructure, such as IAM and RBAC. Access controls may restrict certain jobs or users, with activities logged for compliance and programmable actions, like retrieving and issuing a JWT token.

X

X-Total: X-Total is a header that indicates the count of available entries.

X-Total-Pages: X-Total-Pages is a header that indicates the total number of pages available.

Y

YAML: YAML is a syntax used to configure GitLab CI/CD.

Guide to Install GitLab

Ready to dive into using GitLab? Ensure you have it installed correctly by following these detailed installation guides tailored to different distros.

With these installation guides, you'll be up and running with GitLab in no time!