GitLab CI/CD
GitLab CI/CD integrates source control, CI pipeline, container registry, and deployment environments into a single platform. We configure .gitlab-ci.yml pipelines that build, test, scan, and deploy your application with stages, dependencies, artifacts, and environment-based deployment gates.
Capabilities
What we build with GitLab CI/CD
.gitlab-ci.yml
Pipeline Authoring
Pipeline files with stages, job dependencies, artifacts, caching, and rule conditions that run the right jobs on the right events — merge requests get different jobs than pushes to the default branch.
Shared · project runners
Runner Configuration
GitLab Runner setup on EC2, EKS, or GitLab's shared runners, with executor configuration (Docker, Kubernetes), runner tags, and resource limits appropriate for the build workloads.
GitLab Container Registry
Container Image Builds
Jobs that build Docker images with BuildKit and push to the built-in GitLab Container Registry or Amazon ECR, with image tagging strategy tied to branch, tag, and commit SHA.
Helm · kubectl
Kubernetes Deployment
Deployment jobs that update Helm values or Kubernetes manifests and apply them to EKS or another cluster, with rollout status monitoring and environment tracking in GitLab.
Dev · staging · prod gates
Environment Management
GitLab Environments configuration with manual approval gates for production deployments, deployment history, and rollback capabilities built into the GitLab UI.
SAST · DAST · Dependency
Security Scanning
GitLab Ultimate's built-in SAST, dependency scanning, and container scanning, or equivalent open-source tools, integrated as pipeline stages that block merge on critical findings.
Our approach
Rules over only/except
The rules keyword gives precise control over when a job runs: by branch, by tag, by pipeline source, by changes to specific files. The older only/except syntax is less expressive. We use rules throughout for clarity.
Artifacts and caching are different
Cache persists dependency downloads across pipeline runs for the same branch. Artifacts pass files between jobs in the same pipeline. Confusing them is a common issue in GitLab pipelines — we configure both correctly so that pipelines are fast and jobs have access to the files they need.
Protected environments for production
GitLab protected environments require specific maintainer-or-above roles and can require manual approval before a deployment job runs. We configure production as a protected environment so that deployments require intentional human action.
Pipeline as code, version-controlled
The .gitlab-ci.yml is the pipeline. It lives in the repository, is reviewed in merge requests, and its history is visible in Git. We write pipeline files that are readable and maintainable rather than arcane sequences of shell commands.
All engineering work is done by US-based engineers. We do not offshore any development or architecture work.
Part of our DevOps practice
FAQ
Common questions
Virginia · United States
Need GitLab CI/CD expertise?
If you need a pipeline built, migrated, or improved, reach out and we will discuss the requirements.