🚀 Architecture — How GitLab CI Executes Pipelines
A GitLab CI pipeline consists of jobs defined in .gitlab-ci.yml. Each job runs in an isolated Docker container (or on a shared runner) and executes the commands listed in script.
📑 Table of Contents
- 🚀 Architecture — How GitLab CI Executes Pipelines
- 🔧 Runner Types — Shared vs. Specific
- 🧩 Jenkins — The Agent Model Explained
- ⚙️ Executor Types — Docker vs. Shell
- ⚖️ Comparison — gitlab ci vs jenkins startup pipelines Feature Matrix
- 🔧 Implementation — Building a Simple CI Pipeline for a Node.js App
- 📂 GitLab CI File
- 📂 Jenkinsfile
- 📈 Scaling — Startup Considerations for Parallel Jobs
- 🟩 Final Thoughts
- ❓ Frequently Asked Questions
- When should I choose Jenkins over GitLab CI?
- Can I run both GitLab CI and Jenkins in the same project?
- How do I secure secret variables in each system?
- 📚 References & Further Reading
🧩 Jenkins — The Agent Model Explained
Jenkins runs pipelines on agents (formerly slaves) that connect to a master via JNLP. Each agent provides the execution environment for the steps defined in the pipeline.
# Jenkinsfile
pipeline { agent any stages { stage('Test') { steps { sh 'npm ci && npm test' } } stage('Build') { steps { sh 'npm run build' archiveArtifacts artifacts: 'dist/**', fingerprint: true } } stage('Deploy') { when { branch 'main' } steps { sh './deploy.sh' } } }
}
What this does:
- agent any: Allocates any available agent for the pipeline.
- sh: Executes a shell command on the agent.
- archiveArtifacts: Persists files for later stages or for download.
- when: Conditional execution based on branch name.
When a job starts, the master sends a JNLP payload to the chosen agent, which then spawns a process that runs the scripted steps. The agent may be a Docker container, a VM, or a bare‑metal host. Because the agent persists across stages unless a node block is re‑entered, state can leak between stages if not explicitly cleaned.
⚙️ Executor Types — Docker vs. Shell
Jenkins can run steps inside a Docker container (Docker pipeline plugin) or directly on the host (Shell executor). Docker execution isolates each stage similarly to GitLab, but requires an explicit docker.image(...).inside block.
$ java -jar jenkins-cli.jar -s http://localhost:8080/ list-agents
[-07-31 12:00:00] INFO: Connected to Jenkins
Agent: docker-agent (online) Labels: docker linux Executor: 2
Agent: vm-agent (offline) Labels: vm windows
The command shows a Docker‑enabled agent ready to accept jobs. According to the Jenkins documentation, using a Docker executor improves reproducibility at the cost of additional startup latency for each container.
Key point: Jenkins’ flexible agent model accommodates heterogeneous hardware, but the persistent agent lifecycle can introduce hidden state issues for fast‑moving startups.
⚖️ Comparison — gitlab ci vs jenkins startup pipelines Feature Matrix
This table summarizes the most relevant attributes for early‑stage companies that need rapid iteration, low ops overhead, and clear cost visibility.
| Attribute | GitLab CI | Jenkins |
|---|---|---|
| Configuration Language | YAML (declarative) | Groovy (scripted/declarative) |
| Built‑in Container Support | Native Docker executor per job | Docker plugin required for per‑stage isolation |
| Scalability Model | Horizontal runner pool, auto‑scale via Kubernetes | Agent pool, manual scaling of nodes |
| Security Isolation | Job runs in fresh container; no host leakage | Agent can share host; requires careful sandboxing |
| Cost Predictability | Free tier includes 400 CI minutes; pay‑as‑you‑go for extra | Open source; cost is infrastructure only |
For startups that prioritize minimal ops and want containers to be the default execution environment, GitLab CI’s native model often reduces complexity. Jenkins excels when a team already maintains a fleet of heterogeneous agents and needs fine‑grained control over execution environments.
🔧 Implementation — Building a Simple CI Pipeline for a Node.js App
Creating a working pipeline in either system requires only a few files; the steps below illustrate the minimal viable setup for a typical startup codebase.
📂 GitLab CI File
Place the YAML snippet from the first section in the repository root as .gitlab-ci.yml. Commit and push to trigger the pipeline.
$ git push origin main
Enumerating objects: 12, done.
Counting objects: 100% (12/12), done.
Delta compression using up to 8 threads
Compressing objects: 100% (8/8), done.
Writing objects: 100% (12/12), 1.23 KiB | 1.23 MiB/s, done.
Total 12 (delta 4), reused 0 (delta 0)
To gitlab.com:example/startup-app.git * [new branch] main -> main
GitLab immediately displays a pipeline status badge. The runner pulls the Docker image, executes the npm ci and npm test steps, and reports success or failure.
📂 Jenkinsfile
For Jenkins, add the Jenkinsfile at the repository root and configure a Multibranch Pipeline job pointing to the repo.
$ curl -X POST http://localhost:8080/job/startup-pipeline/createItem?name=startup-pipeline \ -H "Content-Type: application/xml" \ -d '<flow-definition plugin="workflow-job@2.40"><definition class="org.jenkinsci.plugins.workflow.cps.CpsScmFlowDefinition"><scriptPath>Jenkinsfile</scriptPath></definition></flow-definition>'
Created
Jenkins scans the repo, detects the Jenkinsfile, and schedules the first run. The UI shows stages “Test”, “Build”, and “Deploy” with timestamps.
Key point: Both tools require only a single declarative file to achieve end‑to‑end CI for a Node.js startup, but GitLab CI eliminates the need for a separate job‑definition UI. (More onPythonTPoint tutorials)
📈 Scaling — Startup Considerations for Parallel Jobs
Parallel execution reduces feedback latency. The following explains how each platform achieves concurrency and the underlying mechanisms.
GitLab CI launches multiple runners concurrently. Each runner creates its own Docker container, isolated by cgroups. The scheduler maintains a queue in the database; workers poll the queue with a lightweight SELECT ordered by created_at. Overhead is limited to the docker create and docker start syscalls.
$ docker ps -a
CONTAINER ID IMAGE COMMAND CREATED STATUS NAMES
a1b2c3d4e5f6 node:20-alpine "npm ci && npm test" 2 minutes ago Exited (0) 1 minute ago gitlab-runner-12345
b2c3d4e5f6g7 node:20-alpine "npm run build" 2 minutes ago Exited (0) 1 minute ago gitlab-runner-12346
Jenkins achieves parallelism by allocating multiple executors on each agent. When using the Docker pipeline plugin, each stage can be wrapped in docker.image(...).inside, which spawns a new container via the Docker daemon. The master tracks executor availability in memory; a busy executor blocks further job assignment until the current container exits, incurring a context‑switch cost.
$ java -jar jenkins-cli.jar -s http://localhost:8080/ get-node docker-agent
[-07-31 12:05:00] INFO: Connected to Jenkins
Node: docker-agent Executors: 2 (available: 1) Labels: docker linux
Because Jenkins agents persist across stages, you can cache node_modules between jobs to speed up builds, but you must manually clean the workspace to avoid stale artifacts. GitLab CI’s per‑job containers automatically discard caches unless a cache section is defined.
Key point: GitLab CI’s stateless containers simplify horizontal scaling, while Jenkins’ executor model offers more control at the expense of manual state management.
🟩 Final Thoughts
The choice between GitLab CI and Jenkins for startup pipelines hinges on operational simplicity versus flexibility. GitLab CI provides a built‑in, container‑first experience that aligns with rapid iteration, reducing the need for custom agent provisioning and lowering the risk of environment drift. Jenkins, with its mature plugin ecosystem and agent‑centric architecture, excels when a startup already maintains a diverse set of build machines or requires complex orchestration beyond what a declarative YAML can express.
For most new ventures, the decisive factor is the cost of maintaining build infrastructure. GitLab CI’s free tier and auto‑scaling runners give predictable expense curves, while Jenkins requires dedicated servers or cloud instances that must be patched, monitored, and secured. Evaluate the long‑term roadmap: if the product will eventually need fine‑grained control over hardware resources, Jenkins may be justified; otherwise, the streamlined GitLab CI workflow usually accelerates delivery and keeps the DevOps burden low.
❓ Frequently Asked Questions
When should I choose Jenkins over GitLab CI?
Choose Jenkins if you already have an existing pool of heterogeneous build agents, need advanced plugin capabilities not yet available in GitLab, or require fine‑grained control over the build environment that goes beyond container isolation.
Can I run both GitLab CI and Jenkins in the same project?
Yes. Some teams use GitLab CI for fast feedback on pull‑request pipelines while delegating heavyweight integration tests or release orchestration to Jenkins, linking the two via webhooks or artifact publishing.
How do I secure secret variables in each system?
Both platforms store variables encrypted at rest. In GitLab CI, define them under Settings → CI/CD → Variables; they are injected as environment variables at runtime. In Jenkins, use the Credentials Plugin to create secret text or file credentials, then reference them in the pipeline with withCredentials.
💡 Want to practise this hands-on? DigitalOcean gives new accounts $200 free credit for 60 days — enough to spin up a full Linux/Docker/Kubernetes environment at no cost.
📚 Recommended reading: Best DevOps & cloud books on Amazon — from Linux fundamentals to Kubernetes in production, curated for working engineers.
📚 References & Further Reading
- Official Jenkins Pipeline documentation – details on declarative pipelines and agent configuration: jenkins.io
- Kubernetes documentation – explains how GitLab’s auto‑scaling runners integrate with K8s clusters: kubernetes.io
Top comments (0)