Loading page…
GitLab CI/CD Development
Pipelines defined in .gitlab-ci.yml with runners, environments and merge-request workflows, on GitLab.com or self-managed.
Start Your Project
What GitLab CI is
GitLab CI/CD is the pipeline system built into GitLab. Pipelines are defined in a .gitlab-ci.yml file, split into stages and jobs, and executed by runners that you can host yourself or take from GitLab.com.
Its distinguishing feature is how much sits in one product: source, merge requests, container registry, environments and security scanning share one data model. That suits teams that want a single tool, and especially those who need to self-host it.
We take on GitLab CI per engagement. It is not part of the stack we run for our own projects, so we scope it on the specifics of the setup you have.
Suitability
And when it is not. Choosing the wrong tool costs more than any implementation detail.
Good fit for
- Teams already on GitLab, whether GitLab.com or a self-managed instance
- Organisations that must keep source, builds and artefacts on infrastructure they control
- Workflows that benefit from review apps, protected environments and merge request pipelines in one place
- Projects that want container registry and dependency scanning without assembling separate tools
Consider alternatives for
- Code hosted on GitHub, where adding GitLab only for CI duplicates repositories and adds sync to maintain
- Teams with no capacity to operate and upgrade runners, if they would otherwise be well served by hosted runners
- Cases where several advanced features are paywalled behind a tier you have not budgeted for
In practice
01
Pipeline design
Stages and jobs structured so independent work runs in parallel, with rules that keep expensive jobs off branches that do not need them.
02
Runner infrastructure
Autoscaling runners on cloud or Kubernetes, with isolated executors and cached dependencies, so builds stay fast without idle machines.
03
Protected environments and approvals
Production deploys gated by protected branches, protected variables and manual approval jobs, with a clear audit trail.
Considerations
Practical notes from running this in production.
- 01
Runners are the operational burden of a self-managed setup. Capacity, isolation between jobs and secure handling of the Docker socket all need deliberate decisions.
- 02
Variables marked as protected or masked are only available in the right contexts. Misjudging this either leaks a value or silently breaks a deploy job.
- 03
Feature availability varies by tier. Check which capabilities a pipeline design depends on before committing to it.
- 04
Long include chains and templates become hard to reason about. Keep shared pipeline templates small and versioned.
FAQ
GitLab CI or GitHub Actions?
Mostly a question of where your code lives. If it is on GitLab, use GitLab CI. If you need everything self-hosted in one product, GitLab is a strong fit. If it is on GitHub, Actions is the simpler path.
Do you run GitLab CI in your own delivery?
No. Our own pipelines run on GitHub Actions. We take on GitLab CI per engagement and will say during scoping where the work is routine and where it needs more discovery.
Can you set up self-hosted runners?
Yes, including autoscaling runners on cloud infrastructure. We design the executor model, isolation and caching together, because those choices determine both cost and security.
How long does a GitLab CI development project take?
It depends on scope. A focused first release is usually weeks rather than months, while larger platforms are delivered in phases. We give a written estimate after a short discovery conversation and agree milestones before work starts.
How is GitLab CI development work priced?
We work either to a fixed scope with agreed milestones or on a time-and-materials basis, whichever suits how well the requirements are known. You receive the estimate and its assumptions in writing before committing.
By industry
Where we apply GitLab CI. Tiles marked "Guide" open a dedicated write-up; the rest open the industry page.
Let’s talk about your GitLab CI project
Tell us what you are trying to build or fix. We will come back with scope, approach and an honest view on cost and timeline.