GitLab Deep Dive | Architecture, CI/CD & System Design
The world's largest independent DevOps platform is a Ruby monolith. But how does the pipeline behind the pipeline really work? We'll find out by examining GitLab's stack, architecture, and logic for its CI/CD process. We'll also ground these topics in their historical context by discussing pipes, DAG scheduling, and optimistic concurrency.
Finally, I'll make the case for why all of this is about to change very soon.
Read our GitLab research reports:
https://newsletter.fullstack.zip/p/gi...
https://newsletter.fullstack.zip/p/in...
Sponsor this channel: https://www.fullstack.zip/sponsors
STACK:
Backend: Ruby on Rails
HTTP server: Puma (Ruby web server)
Edge: Nginx
Reverse proxy: Go service (Workhorse)
Background jobs: Sidekiq (Ruby framework)
DB — primary: PostgreSQL
DB — connection pooling: PgBouncer
DB — high availability: Patroni
Cache: Redis
Git: Custom gRPC repo interface (Git & Gitaly)
Blob: AWS S3
Frontend — rendering: Haml & Vue
Frontend — state: Pinia (Vue store), Immer (immutable cache),
API: GraphQL (Apollo) + REST
Observability: Prometheus & Grafana
Error tracking: Sentry & OpenTelemetry
Deployments: GitLab Omnibus (Omnibus fork)
00:00 Intro
00:35 Architecture
07:58 CI Pipeline
12:25 Context
16:00 What's Next?