GitLab CI/CD

Technical Definition

GitLab CI/CD is a continuous integration and continuous delivery capability integrated into the GitLab platform. A pipeline is defined declaratively in a YAML configuration file (conventionally .gitlab-ci.yml) stored in the project repository. The configuration defines stages and jobs; jobs within the same stage can run in parallel, while stages execute in sequence unless directed acyclic graph (DAG) relationships are explicitly defined using needs. Each job is executed by a runner, an agent process that GitLab dispatches work to, which may be shared, group-level or project-specific, and which executes jobs inside an isolated environment such as a container, shell or virtual machine, according to the configured executor.

Operational Relevance

GitLab CI/CD is used to automate the software delivery lifecycle: linting, unit and integration testing, artefact building, container image publishing, and deployment to target environments. Its operational value comes from making these steps repeatable, auditable and gated by defined rules (for example, running only on specific branches, tags or merge request events). Because pipeline configuration is version-controlled alongside application code, changes to the delivery process are reviewed and tracked using the same mechanisms as code changes, which supports change control and rollback of the pipeline definition itself, not only the application.

Architecture Relationship

GitLab CI/CD sits between the GitLab repository and one or more execution environments. The GitLab instance (SaaS or self-managed) coordinates pipeline scheduling and job dispatch; runners, which may be hosted by GitLab, by the organisation, or by a third party, poll for or receive jobs and report status back. Runners commonly execute inside container orchestration platforms (such as Kubernetes) or dedicated virtual machines, and jobs frequently interact with external systems such as container registries, artifact stores, secret managers and target deployment platforms. Correct operation therefore depends on runner availability, correct executor configuration, and correctly scoped credentials for any external system a job touches.

Example

A minimal pipeline definition might declare two stages, test and deploy, where a test job runs the project’s automated test suite on every merge request, and a deploy job runs only on the default branch after the test stage succeeds. The deploy job would typically be marked to run manually or under an explicit rule to avoid unattended production changes.

stages:
  - test
  - deploy

run_tests:
  stage: test
  script:
    - echo "Run the project test suite here"

deploy_production:
  stage: deploy
  script:
    - echo "Run the deployment step here"
  rules:
    - if: '$CI_COMMIT_BRANCH == "main"'
      when: manual

Misunderstanding

A common misunderstanding is that a runner is a GitLab feature rather than a separately deployed agent; runner health, capacity and executor configuration are operational concerns distinct from the pipeline configuration itself, and a syntactically valid .gitlab-ci.yml will still fail to execute if no compatible runner is available or authorised for the project or group. Another frequent confusion is treating pipeline success as equivalent to deployment success; a pipeline stage completing does not by itself confirm that a deployed change is healthy in the target environment, which is why separate validation and monitoring after deployment remain necessary.

Related Terms

• Runner
• Pipeline
• Stage and job
• Continuous integration
• Continuous delivery
• Merge request pipeline

Further Reading and Operational Checks

Before relying on a GitLab CI/CD pipeline for a production-relevant workflow, confirm the following in a non-production project or a protected branch with restricted merge permissions:

• Verify pipeline syntax without triggering job execution, using GitLab’s CI lint capability, and confirm the reported result is valid before merging configuration changes.
• Confirm that the intended runner is available, correctly tagged, and authorised for the project or group before assuming a pipeline will execute as designed.
• Review job-level access to secrets and deployment credentials to confirm least-privilege scope, since a runner executes with whatever access its environment and CI/CD variables grant it.
• If a pipeline change produces unexpected results, revert the specific commit to .gitlab-ci.yml through the normal Git workflow rather than editing pipeline state directly, since the configuration is the recoverable source of truth.

Treat any deployment job as requiring its own rollback plan independent of the pipeline: GitLab CI/CD automates the execution of steps you define, but it does not itself guarantee that a deployment can be safely reversed unless that reversal is explicitly built into the pipeline or into the target platform’s own recovery mechanism.