Aisalkyn Aidarova

Posted on Feb 21

GitActions & Jenkins & GitLab differences

1️⃣ Jenkins

Used by:

Large enterprises
Banks
Old infrastructure companies
Companies with on-prem data centers

Why companies use it:

Fully customizable
1000+ plugins
Works with everything (AWS, Azure, GCP, Kubernetes, Docker)
Total control

Reality:

Very powerful
But high maintenance
DevOps team must manage upgrades, plugins, security

Example companies:

Banks, insurance, telecom, enterprise IT

2️⃣ GitHub Actions

Used by:

Startups
Cloud-native companies
Open-source projects
SaaS companies

Why companies use it:

Built inside GitHub
Easy setup
No server maintenance
Great for cloud & Kubernetes

Reality:

Very popular in modern DevOps
Especially if code is already in GitHub
Less infrastructure work

3️⃣ GitLab CI/CD

Used by:

Companies using GitLab as main platform
Enterprises wanting full DevSecOps in one tool
Some European companies

Why companies use it:

All-in-one (Repo + CI/CD + Security + Registry)
Built-in container registry
Good enterprise control

Reality:

Popular in mid-large companies
Less popular than GitHub globally
Strong in DevSecOps environments

🔥 What is MOST popular right now?

If company uses GitHub → GitHub Actions

If company is enterprise / old infra → Jenkins

If company uses GitLab → GitLab CI

📊 2026 Market Trend

GitHub Actions — fastest growing
Jenkins — still huge in enterprise
GitLab CI — strong but smaller market share

🎯 For YOU (Senior DevOps)

Since:

You use AWS
You teach DevOps
You use EKS, ArgoCD, Terraform
You already use Jenkins

You should know:

Jenkins (for enterprise interviews)
GitHub Actions (for modern roles)
Basic GitLab CI (for flexibility)

💬 Interview Answer Example

If interviewer asks:

"Which CI/CD tool is most popular?"

You answer:

It depends on organization.
In enterprise environments Jenkins is still dominant because of flexibility and plugin ecosystem.
For modern cloud-native environments GitHub Actions is growing rapidly due to its simplicity and GitHub integration.
GitLab CI is popular in organizations that use GitLab as their DevOps platform.

That is senior-level answer.

GitLab

Is GitLab Open Source?

Yes — but partially.

GitLab has two main editions:

GitLab Community Edition (CE)

Open source
Free
You can self-host
Source code is publicly available

GitLab Enterprise Edition (EE)

Includes extra enterprise features
Paid version
Advanced security, compliance, analytics

So:

Core GitLab → Open source
Advanced enterprise features → Commercial

This is called an open-core model.

Who Invented GitLab?

GitLab was created in 2011 by:

Dmitriy Zaporozhets
Sid Sijbrandij

Short story:

Dmitriy started GitLab as an open-source project.
Sid later joined to help grow it into a company.
GitLab became a fully remote company from the beginning.
In 2021, GitLab went public on NASDAQ.

Interesting Facts (Good for Interview)

GitLab is one of the largest all-remote companies in the world.
It competes directly with:
- GitHub
- Bitbucket
GitLab provides full DevOps lifecycle in one platform:
- Repo
- CI/CD
- Security scanning
- Container registry
- Monitoring

Simple Interview Answer

If asked:

"Is GitLab open source?"

You say:

GitLab started as an open-source project and still provides a Community Edition that is open source. However, it follows an open-core model, where advanced enterprise features are available in the paid Enterprise Edition.

1️⃣ GitLab vs GitHub — Architecture Level

🟣 GitLab Architecture

Core Idea:

GitLab is one integrated DevOps platform.

Everything is in one system:

Git repository
CI/CD
Container Registry
Security scanning
Issue tracking
Monitoring

Components (Self-Managed setup):

GitLab Rails App

Main web UI
API
Authentication
1. PostgreSQL
Stores metadata (users, pipelines, MR, etc.)
1. Redis
Caching & background jobs
1. Gitaly
Git repository storage service
1. Sidekiq
Background job processor
1. GitLab Runner
Executes CI/CD jobs

👉 Everything tightly integrated.

🟢 GitHub Architecture

Core Idea:

GitHub = Code hosting first
CI/CD added later (GitHub Actions)

Architecture is more modular:

GitHub (repos, PRs)
GitHub Actions (separate workflow system)
GitHub Packages
GitHub Security
Often integrated with 3rd party tools

👉 CI/CD is not originally core — it’s an extension.

🔥 Key Architectural Difference

Area	GitLab	GitHub
DevOps lifecycle	Built-in all-in-one	Separate services
CI/CD	Native core component	Extension (Actions)
Self-hosting	Very strong	Enterprise only
Architecture style	Monolithic + services	Distributed services
Enterprise control	Very strong	Strong but cloud-focused

2️⃣ Why Some Companies Prefer GitLab

Companies choose GitLab when they want:

✅ Full DevSecOps in one platform

Repo
CI/CD
SAST
DAST
Container registry
Security dashboard

All integrated.

✅ Strong Self-Hosting

Banks, government, regulated industries prefer GitLab because:

Can deploy fully on-prem
Full control over data
No dependency on SaaS

✅ Built-in Security & Compliance

GitLab includes:

Security scans in pipeline
License scanning
Dependency scanning
Compliance pipelines

This is strong for enterprise DevSecOps.

3️⃣ How GitLab CI Works Internally

This is important for interviews.

Step-by-Step Internal Flow

You push code → pipeline starts

Step 1: Git Push

Developer pushes to repo.

GitLab detects .gitlab-ci.yml.

Step 2: Pipeline Created

GitLab Rails app:

Parses YAML
Creates pipeline record in PostgreSQL
Creates jobs

Step 3: Job Queued

Jobs stored in database queue.

Step 4: GitLab Runner Picks Job

Runner types:

Shared runner
Specific runner
Self-hosted runner

Runner polls GitLab API:

"Do you have job for me?"

Step 5: Job Execution

Runner can use executors:

Docker executor
Shell executor
Kubernetes executor
SSH executor

Example Docker executor flow:

Pull Docker image
Create container
Clone repository
Execute job script
Upload artifacts
Send result back

Step 6: Result Stored

Runner sends:

Logs
Status
Artifacts

GitLab stores in:

Database
Object storage (S3, MinIO, etc.)

Architecture Summary (Internal View)

Developer → GitLab API → DB → Job Queue → Runner → Docker/K8s → Back to GitLab

🔥 Senior-Level Interview Answer

If asked:

"How does GitLab CI work internally?"

You say:

GitLab CI is tightly integrated into GitLab’s core architecture. When code is pushed, GitLab parses the .gitlab-ci.yml file, creates a pipeline entry in the database, and queues jobs. GitLab Runners poll the GitLab API for available jobs. Once assigned, the runner executes the job using a configured executor such as Docker or Kubernetes, then returns logs and artifacts back to GitLab.

That is senior-level answer.

Why GitLab and GitHub use “Git” in their name?

Because both platforms are built around:

Git

What is Git?

Git is a distributed version control system (DVCS).

It was created in 2005 by:

Linus Torvalds

(the creator of Linux)

Git manages:

Source code history
Branching
Merging
Collaboration
Version tracking

What GitHub and GitLab Actually Are

They are platforms built on top of Git.

Think of it like this:

Git = Engine
GitHub / GitLab = Garage + Tools + UI + Automation

🟢 GitHub

“Hub” = central place
GitHub = Central hub for Git repositories

Originally it was just:

Git repository hosting
Pull requests
Collaboration

CI/CD came later.

🟣 GitLab

“Lab” = development laboratory
GitLab = Development platform built around Git

From the beginning it aimed to:

Manage repos
Provide CI/CD
Provide DevOps lifecycle tools

Why Include "Git" in the Name?

Because:

They are based on Git repositories
They extend Git functionality
Their core product is Git repository hosting

Without Git → GitHub and GitLab would not exist.

Simple Analogy for Students

Git = Database of code history
GitHub/GitLab = Cloud service that stores and manages that database + adds collaboration + CI/CD

Important Interview Point

If interviewer asks:

"Is GitHub a version control system?"

Correct answer:

No. Git is the version control system. GitHub is a cloud-based platform built on top of Git that provides repository hosting, collaboration, and CI/CD features.

That distinction is important.

1️⃣ Why Git Is Distributed (And Why That Matters)

Git

Distributed means:

Every developer has the entire repository history locally.

When you run:

git clone repo-url

You do NOT just download latest code.
You download:

All commits
All branches
Full history
All metadata

Your local machine becomes a full copy of the repo.

Why This Matters

✅ 1. No single point of failure

If GitHub goes down → developers still have full history locally.

✅ 2. Offline work

You can:

commit
branch
merge
rebase
view history

Without internet.

✅ 3. Speed

Most operations are local:

git log
git diff
git branch

No server roundtrip.

✅ 4. Flexible collaboration

You can push to:

GitHub
GitLab
Bitbucket
Another developer's machine

No central dependency.

Compare to SVN (Centralized)

In centralized systems like:

Apache Subversion (SVN)

Developers only download:

Latest version
No full history

Most operations require server connection.

If server goes down → work stops.

2️⃣ How Git Works Internally (Real Architecture)

Git is basically a content-addressable database.

Everything is stored inside:

.git/

Git Object Types

Git has 4 main object types:

1️⃣ Blob (Binary Large Object)

Stores file content.

Example:
If you create:

echo "hello" > file.txt
git add file.txt

Git creates a blob object containing:

hello

Blob does NOT store filename.
Only content.

2️⃣ Tree

Tree represents directory structure.

It maps:

filenames
blob IDs
subdirectories

Think of tree as folder snapshot.

3️⃣ Commit

Commit stores:

Pointer to tree
Parent commit
Author
Timestamp
Message

Commit = snapshot of project at a moment in time.

4️⃣ Tag (optional)

Pointer to commit.

Internally Everything Is Hashed

Git uses SHA-1 hash.

Each object gets unique ID:

e99a18c428cb38d5f260853678922e03abd8334

That hash is based on:

Object content

If content changes → hash changes.

This makes Git:

Immutable
Secure
Efficient

Commit Chain Example

Commit C → points to Commit B
Commit B → points to Commit A

This creates commit history graph.

That’s why Git history is technically a Directed Acyclic Graph (DAG).

3️⃣ Why Companies Use Git Instead of SVN

Even in 2026, Git dominates.

Here’s why:

🔥 1. Branching Is Lightweight

In Git:

git branch feature-x

Creates pointer. Instant.

In SVN:
Branching = directory copy (heavy).

🔥 2. Better for CI/CD

Modern DevOps uses:

Feature branches
Pull requests
Merge requests
Rebasing
GitOps workflows

Git handles this naturally.

SVN struggles with modern microservice workflows.

🔥 3. Cloud Ecosystem Built Around Git

All modern tools integrate with Git:

GitHub
GitLab
Bitbucket
CI/CD pipelines
Kubernetes GitOps
Terraform workflows

🔥 4. Better for Large Teams

Git allows:

Fork workflows
Open source contributions
Multiple remotes
Parallel development

Senior-Level Interview Answer

If interviewer asks:

"Why is Git distributed and why does it matter?"

Answer:

Git is distributed because every clone contains the full repository history. This eliminates single points of failure, enables offline work, improves performance since most operations are local, and supports flexible collaboration models. This architecture makes Git highly scalable and suitable for modern CI/CD and DevOps workflows.