🖼️ See the drawing + lab 🏠 Course home 🌿 Branch on GitHub ✏️ View source

🖼️ आकृती आणि labThe drawing + lab पूर्ण पानावर उघडा ↗Open full page ↗

🗣️ धडा 11 — तीच pipeline चार बोलींमध्ये: चार कुरिअर, एक मार्ग

📍 तुम्ही इथे आहात: 12 पैकी धडा 11 · मागील: lesson-10-deploy-to-kubernetes · पुढील: lesson-12-pipeline-hygiene

📦 या ब्रँचमध्ये काय आहे

धडे 01–10, आणि त्याशिवाय शब्दकोश. या धड्यात नवीन काहीही घडत नाही — तोच मार्ग (test → build & push → staging → सही → production) चार वेळा लिहिलेला आहे, आणि तुम्ही चारही वाचायला शिकता. खऱ्या files:

.github/workflows/ci.yml · ship.yml · deploy.yml — GitHub Actions मार्गाचे तीन files मध्ये विभाजन करते
.circleci/config.yml — CircleCI: एक file, workflows: मध्ये एकत्र जोडलेले jobs:
.gitlab-ci.yml — GitLab CI: एक file, stages: आणि YAML anchors
Jenkinsfile — Jenkins declarative pipeline, YAML ऐवजी Groovy मध्ये
app/package.json — test:ci मध्ये logic राहू शकते, म्हणजे YAML पातळ राहते

🧒 5 वर्षांच्या मुलाला समजावल्यासारखे

शाळेच्या मार्गासाठी चार कुरिअर कंपन्या बोली लावतात 📮. प्रत्येक जण तोच रस्ता चालवते: गृहपाठ घ्या, तपासा, फोटोकॉपी करा, लॉकरमध्ये ठेवा, सराव फलकावर पोहोचवा, प्राचार्यांच्या सहीची वाट पाहा, मुख्य फलकावर पोहोचवा.

पण प्रत्येक कंपनीची स्वतःची कागदपत्रे 📄 असतात. एक थांब्याला "job" म्हणते, दुसरी "stage". एक आपल्या चालकाला "runner" म्हणते, एक "agent", एक "executor". तिघी आपले फॉर्म YAML मध्ये लिहितात; एक Groovy मध्ये. मार्ग बदलत नाही; फॉर्मवरचे शब्द बदलतात.

म्हणून हा धडा म्हणजे एक शब्दकोश 🗣️. महत्त्वाचे चौदा शब्द शिका आणि चारपैकी कोणताही फॉर्म तुम्हाला आधीच माहीत असलेल्यासारखा वाचता येईल. सगळ्यात छान भाग: प्रत्यक्ष काम — node --test, docker build, kubectl rollout status — चारही files मध्ये तीच shell command आहे. बोली म्हणजे फक्त वरचे आवरण.

🗺️ आकृती

flowchart LR
    route["📮 one route<br/>test → build+push → staging → 🛑 → production"]
    gha["⚙️ GitHub Actions<br/>3 files: ci · ship · deploy"]
    cci["🔄 CircleCI<br/>.circleci/config.yml"]
    gl["🦊 GitLab CI<br/>.gitlab-ci.yml"]
    jk["🎩 Jenkins<br/>Jenkinsfile"]
    cmds["🐚 the same shell lines<br/>node --test · docker build · kubectl rollout status"]
    route -->|"1"| gha
    route -->|"1"| cci
    route -->|"1"| gl
    route -->|"1"| jk
    gha -->|"2 runs"| cmds
    cci -->|"2 runs"| cmds
    gl -->|"2 runs"| cmds
    jk -->|"2 runs"| cmds

❓ काय

🧠 Rosetta stone — चार खऱ्या files ज्या प्रकारे शब्द लिहितात

संकल्पना	⚙️ GitHub Actions	🔄 CircleCI	🦊 GitLab CI	🎩 Jenkins
trigger	`on: push:` / `pull_request:` / `workflow_call:` / `workflow_dispatch:`	अप्रत्यक्ष: push केला की `workflows:` चालतात	अप्रत्यक्ष: push केला की pipeline चालते	file मध्ये नाही, job वर ठरवलेले (webhook / multibranch scan)
workflow / pipeline	एक file = एक workflow, `name: ✅ ci`	`workflows: test-build-deploy:`	संपूर्ण file; `stages: [test, build, deploy]`	`pipeline { … }`
job / stage	`jobs: test:` + `needs:`	`jobs: test:` + `requires:`	`stage: test` सह `test:` + `needs:`	`stage('✅ test')`
step	`steps: - uses:` / `- run:`	`steps: - checkout` / `- run:`	`script:` ओळी	`steps { sh '…' }`
runner	`runs-on: ubuntu-latest`	`docker: - image: cimg/node:…` (executor)	runner वर `image: node:${NODE}-alpine`	`agent { docker { image "node:${NODE}-alpine" } }` / `agent any`
matrix	`strategy: matrix: node: [20, 22, 24]`	`matrix: parameters: node: […]`	`parallel: matrix: - NODE: […]`	`matrix { axes { axis { name 'NODE' … } } }`
cache	`actions/cache@v4`, `key: prepared-${{ hashFiles('app/prepare.js') }}`	`restore_cache` / `save_cache`, `{{ checksum "prepare.js" }}`	`cache: key: files: [app/prepare.js]`	अंगभूत नाही — persistent workspace, किंवा Job Cacher plugin
artifact	`actions/upload-artifact@v4` / `download-artifact@v4`	`store_artifacts`	`artifacts: paths:` + `expire_in`	या file मध्ये वापरलेले नाही (`archiveArtifacts` ही step आहे)
test report	artifact म्हणून upload केलेली JUnit file	`store_test_results`	`artifacts: reports: junit:`	`post { always { junit '…' } }`
secret / credential	`${{ secrets.X }}` / `${{ vars.X }}`	`context: school-cicd`	project CI/CD variables, `$AWS_ROLE_ARN`	`withAWS(credentials: 'aws-school-cicd', …)`
OIDC badge	`permissions: id-token: write` + `configure-aws-credentials` `role-to-assume:`	`aws-cli/setup: role_arn:`	`id_tokens:` + `aws sts assume-role-with-web-identity`	या file मध्ये नाही — त्याऐवजी credential binding
approval gate	`environment: production` + required reviewers	`hold-for-approval: type: approval`	`when: manual`	`input message: 'Deploy to production?'`
environment	`environment: staging`	एक job `name:` + एक `namespace:` parameter	`environment: { name: staging }`	`deployTo('staging')` — function argument
फक्त main वर	`on: push: branches: [main]`	`filters: branches: only: main`	`rules: - if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH`	`when { branch 'main' }`

Hosted runner = vendor चे मशीन, प्रत्येक job साठी नवे, एका ठरलेल्या मोफत मर्यादेतून मिळणारे. Self-hosted runner / agent = तुमचे मशीन किंवा pod: तुमचे patching, तुमची network पोहोच, तुमचे बिल. चारही self-hosted ला support करतात; Jenkins तर मुळातच self-hosted आहे.

🤔 का

Teams भाषा बदलतात त्यापेक्षा जास्त वेळा CI vendor बदलतात, आणि नोकरीच्या जाहिरातींमध्ये चारही नावे असतात. तुमच्या pipeline चे logic YAML मध्ये असेल तर migration म्हणजे पूर्ण पुनर्लेखन; ते scripts आणि package.json मध्ये असेल तर migration म्हणजे पातळ आवरणाचे भाषांतर — जे नेमके वरच्या तक्त्यात आहे. या कोर्सचे चार tab असलेले पान पूर्ण files शेजारी शेजारी दाखवते.

प्रत्येक कुठे चमकतो (सावधपणे — चारही बदलत राहतात)

⚙️ GitHub Actions: code आधीच जिथे आहे तिथेच राहतो; actions चा मोठा marketplace; हे लिहिताना public repositories ना मोफत मर्यादा मिळते.
🔄 CircleCI: वेगवान executors, पुन्हा वापरता येणारे orbs, नावाच्या jobs पुरते credentials मर्यादित करणारे contexts, image builds साठी setup_remote_docker.
🦊 GitLab CI: SCM आणि CI एकाच product मध्ये; environments आणि merge-request widgets (JUnit report MR मध्ये दिसतो); स्वतः चालवायला सोपे.
🎩 Jenkins: self-hosted, जवळजवळ प्रत्येक गोष्टीसाठी plugin, मोठ्या किंवा दीर्घकाळ चाललेल्या व्यवस्थांमध्ये अजूनही सामान्य; controller आणि त्याचे upgrades तुमच्या डोक्यावर.

प्रत्येक vendor ची मोफत मर्यादा बदलत असते; हे README नव्हे, सध्याचे पान तपासा.

🔧 कसे (या repo मध्ये)

चारही जिच्यावर सहमत आहेत ती एक ओळ — तीच test command, चार आवरणे:

# .github/workflows/ci.yml
      - name: 🧪 test
        run: >
          node --test
          --test-reporter=spec  --test-reporter-destination=stdout
          --test-reporter=junit --test-reporter-destination=test-results.xml

# .circleci/config.yml
      - run:
          name: 🧪 test
          command: |
            mkdir -p test-results
            node --test --test-reporter=spec --test-reporter-destination=stdout \
                        --test-reporter=junit --test-reporter-destination=test-results/junit.xml

# .gitlab-ci.yml
  script:
    - cd app
    - node prepare.js                         # prints "already exists" on a cache hit
    - node --test --test-reporter=spec --test-reporter-destination=stdout
                  --test-reporter=junit --test-reporter-destination=test-results.xml

// Jenkinsfile
                sh '''node --test --test-reporter=spec  --test-reporter-destination=stdout \
                                  --test-reporter=junit --test-reporter-destination=test-results.xml'''

Migration ची युक्ती. app/package.json मध्ये आधीच "test:ci": "node --test --test-reporter=spec … --test-reporter=junit …" आहे. चारही files मधून npm run test:ci बोलावा, म्हणजे reporter flags एकाच जागी राहतात. Build-and-push shell आणि deploy shell साठीही तेच: ते scripts/ मध्ये ठेवा, म्हणजे प्रत्येक बोली "या credentials सह ही script चालवा" एवढीच उरते.

🧪 करून पाहा

# 1) the three load-bearing commands, pulled out of all four dialects
for f in .github/workflows/ci.yml .github/workflows/ship.yml .github/workflows/deploy.yml \
         .circleci/config.yml .gitlab-ci.yml Jenkinsfile; do
  echo "── $f"; grep -nE "node --test|docker build|rollout status" "$f"
done

# 2) diff the deploy recipe between two dialects — only the variable spelling differs
recipe() { grep -hE "sed -i|kubectl apply|rollout status" "$1" | sed -E 's/^[ -]*//'; }
diff <(recipe .circleci/config.yml) <(recipe .gitlab-ci.yml)
diff <(recipe .gitlab-ci.yml) <(recipe Jenkinsfile)

# 3) count: how many dialects run each command? (GitHub's three files count as one dialect)
for c in "node --test" "docker build --build-arg APP_VERSION" "rollout status"; do
  n=0
  cat .github/workflows/*.yml | grep -qE "$c" && n=$((n+1))
  for f in .circleci/config.yml .gitlab-ci.yml Jenkinsfile; do grep -qE "$c" "$f" && n=$((n+1)); done
  echo "$c → $n of 4 dialects"
done

# 4) now the wrapper words: the matrix, four ways
grep -nE "matrix|axes|node: \[|NODE: \[" .github/workflows/ci.yml .circleci/config.yml .gitlab-ci.yml Jenkinsfile

⚠️ नेहमीच्या चुका

आधी logic scripts मध्ये न हलवता YAML ओळ-न-ओळ भाषांतर करून pipeline port करणे — प्रत्येक विचित्रपणा तुम्ही सोबत नेता आणि काहीच मिळवत नाही
शब्द एकास एक जुळतात असे मानणे: GitLab चा stage parallel चालणाऱ्या jobs चा गट असतो, Jenkins चा stage एक क्रमवार block असतो, आणि CircleCI job चा क्रम फक्त requires: ने ठरतो
मागच्या वर्षीच्या मोफत मर्यादेवरून किंवा एखाद्या blog post वरून vendors ची तुलना करणे — मर्यादा बदलतात; निवडण्याआधी सध्याचे पान तपासा

⏭️ पुढे

तुम्ही चारही फॉर्म वाचू शकता. शेवटचा धडा म्हणजे mailroom चे नियमपुस्तक poster: pipeline वर्षानुवर्षे विश्वासार्ह कशाने राहते, आणि ArgoCD शाळेकडे हस्तांतर.

git checkout lesson-12-pipeline-hygiene

🗣️ Lesson 11 — The same pipeline in four dialects: four couriers, one route

📍 You are here: Lesson 11 of 12 · Previous: lesson-10-deploy-to-kubernetes · Next: lesson-12-pipeline-hygiene

📦 What's in this branch

Lessons 01–10, plus the phrasebook. Nothing new happens in this lesson — the same route (test → build & push → staging → signature → production) is written four times, and you learn to read all four. Real files:

.github/workflows/ci.yml · ship.yml · deploy.yml — GitHub Actions splits the route into three files
.circleci/config.yml — CircleCI: one file, jobs: wired together in workflows:
.gitlab-ci.yml — GitLab CI: one file, stages: and YAML anchors
Jenkinsfile — Jenkins declarative pipeline, in Groovy rather than YAML
app/package.json — test:ci is where the logic can live so the YAML stays thin

🧒 Explain like I'm 5

Four courier companies bid for the school's route 📮. Each one drives the same road: pick up the homework, check it, photocopy it, file it in the locker, deliver to the practice board, wait for the principal's signature, deliver to the main board.

But each company has its own paperwork 📄. One calls a stop a "job", one a "stage". One calls its driver a "runner", one an "agent", one an "executor". Three write their forms in YAML; one writes them in Groovy. The route does not change; the words on the form do.

So this lesson is a phrasebook 🗣️. Learn the fourteen words that matter and any of the four forms reads like the one you already know. The best part: the actual work — node --test, docker build, kubectl rollout status — is the same shell command in all four files. The dialect is only the wrapper.

🗺️ Diagram

flowchart LR
    route["📮 one route<br/>test → build+push → staging → 🛑 → production"]
    gha["⚙️ GitHub Actions<br/>3 files: ci · ship · deploy"]
    cci["🔄 CircleCI<br/>.circleci/config.yml"]
    gl["🦊 GitLab CI<br/>.gitlab-ci.yml"]
    jk["🎩 Jenkins<br/>Jenkinsfile"]
    cmds["🐚 the same shell lines<br/>node --test · docker build · kubectl rollout status"]
    route -->|"1"| gha
    route -->|"1"| cci
    route -->|"1"| gl
    route -->|"1"| jk
    gha -->|"2 runs"| cmds
    cci -->|"2 runs"| cmds
    gl -->|"2 runs"| cmds
    jk -->|"2 runs"| cmds

❓ What

🧠 The Rosetta stone — the words as the four real files spell them

concept	⚙️ GitHub Actions	🔄 CircleCI	🦊 GitLab CI	🎩 Jenkins
trigger	`on: push:` / `pull_request:` / `workflow_call:` / `workflow_dispatch:`	implicit: a push runs `workflows:`	implicit: a push runs the pipeline	set on the job (webhook / multibranch scan), not in the file
workflow / pipeline	one file = one workflow, `name: ✅ ci`	`workflows: test-build-deploy:`	the whole file; `stages: [test, build, deploy]`	`pipeline { … }`
job / stage	`jobs: test:` + `needs:`	`jobs: test:` + `requires:`	`test:` with `stage: test` + `needs:`	`stage('✅ test')`
step	`steps: - uses:` / `- run:`	`steps: - checkout` / `- run:`	`script:` lines	`steps { sh '…' }`
runner	`runs-on: ubuntu-latest`	`docker: - image: cimg/node:…` (executor)	`image: node:${NODE}-alpine` on a runner	`agent { docker { image "node:${NODE}-alpine" } }` / `agent any`
matrix	`strategy: matrix: node: [20, 22, 24]`	`matrix: parameters: node: […]`	`parallel: matrix: - NODE: […]`	`matrix { axes { axis { name 'NODE' … } } }`
cache	`actions/cache@v4`, `key: prepared-${{ hashFiles('app/prepare.js') }}`	`restore_cache` / `save_cache`, `{{ checksum "prepare.js" }}`	`cache: key: files: [app/prepare.js]`	none built in — persistent workspace, or the Job Cacher plugin
artifact	`actions/upload-artifact@v4` / `download-artifact@v4`	`store_artifacts`	`artifacts: paths:` + `expire_in`	not used in this file (`archiveArtifacts` is the step)
test report	the JUnit file uploaded as an artifact	`store_test_results`	`artifacts: reports: junit:`	`post { always { junit '…' } }`
secret / credential	`${{ secrets.X }}` / `${{ vars.X }}`	`context: school-cicd`	project CI/CD variables, `$AWS_ROLE_ARN`	`withAWS(credentials: 'aws-school-cicd', …)`
OIDC badge	`permissions: id-token: write` + `configure-aws-credentials` `role-to-assume:`	`aws-cli/setup: role_arn:`	`id_tokens:` + `aws sts assume-role-with-web-identity`	not in this file — a credential binding stands in
approval gate	`environment: production` + required reviewers	`hold-for-approval: type: approval`	`when: manual`	`input message: 'Deploy to production?'`
environment	`environment: staging`	a job `name:` + a `namespace:` parameter	`environment: { name: staging }`	`deployTo('staging')` — a function argument
only on main	`on: push: branches: [main]`	`filters: branches: only: main`	`rules: - if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH`	`when { branch 'main' }`

Hosted runner = the vendor's machine, fresh for each job, drawn from an allowance. Self-hosted runner / agent = your machine or pod: your patching, your network reach, your bill. All four support self-hosted; Jenkins is self-hosted by nature.

🤔 Why

Teams change CI vendors more often than they change languages, and job ads name all four. If your pipeline's logic lives in the YAML, a migration is a rewrite; if it lives in scripts and package.json, the migration is a translation of the thin wrapper — which is exactly the table above. This course's four-tab page shows the complete files side by side.

Where each shines (hedged — all four keep changing)

⚙️ GitHub Actions: lives where the code already is; a large marketplace of actions; public repositories get a free allowance at the time of writing.
🔄 CircleCI: fast executors, reusable orbs, contexts that scope credentials to named jobs, setup_remote_docker for image builds.
🦊 GitLab CI: SCM and CI in one product; environments and merge-request widgets (the JUnit report shows up in the MR); straightforward to self-manage.
🎩 Jenkins: self-hosted, a plugin for nearly everything, still common in large or long-lived estates; you carry the controller and its upgrades.

Each vendor has a free allowance that changes; check the current page, not this README.

🔧 How (in this repo)

The one line all four agree on — the same test command, four wrappers:

# .github/workflows/ci.yml
      - name: 🧪 test
        run: >
          node --test
          --test-reporter=spec  --test-reporter-destination=stdout
          --test-reporter=junit --test-reporter-destination=test-results.xml

# .circleci/config.yml
      - run:
          name: 🧪 test
          command: |
            mkdir -p test-results
            node --test --test-reporter=spec --test-reporter-destination=stdout \
                        --test-reporter=junit --test-reporter-destination=test-results/junit.xml

# .gitlab-ci.yml
  script:
    - cd app
    - node prepare.js                         # prints "already exists" on a cache hit
    - node --test --test-reporter=spec --test-reporter-destination=stdout
                  --test-reporter=junit --test-reporter-destination=test-results.xml

// Jenkinsfile
                sh '''node --test --test-reporter=spec  --test-reporter-destination=stdout \
                                  --test-reporter=junit --test-reporter-destination=test-results.xml'''

The migration tip. app/package.json already has "test:ci": "node --test --test-reporter=spec … --test-reporter=junit …". Call npm run test:ci from all four files and the reporter flags live in one place. The same goes for the build-and-push shell and the deploy shell: put them in scripts/ and each dialect shrinks to "run this script with these credentials".

🧪 Try it

# 1) the three load-bearing commands, pulled out of all four dialects
for f in .github/workflows/ci.yml .github/workflows/ship.yml .github/workflows/deploy.yml \
         .circleci/config.yml .gitlab-ci.yml Jenkinsfile; do
  echo "── $f"; grep -nE "node --test|docker build|rollout status" "$f"
done

# 2) diff the deploy recipe between two dialects — only the variable spelling differs
recipe() { grep -hE "sed -i|kubectl apply|rollout status" "$1" | sed -E 's/^[ -]*//'; }
diff <(recipe .circleci/config.yml) <(recipe .gitlab-ci.yml)
diff <(recipe .gitlab-ci.yml) <(recipe Jenkinsfile)

# 3) count: how many dialects run each command? (GitHub's three files count as one dialect)
for c in "node --test" "docker build --build-arg APP_VERSION" "rollout status"; do
  n=0
  cat .github/workflows/*.yml | grep -qE "$c" && n=$((n+1))
  for f in .circleci/config.yml .gitlab-ci.yml Jenkinsfile; do grep -qE "$c" "$f" && n=$((n+1)); done
  echo "$c → $n of 4 dialects"
done

# 4) now the wrapper words: the matrix, four ways
grep -nE "matrix|axes|node: \[|NODE: \[" .github/workflows/ci.yml .circleci/config.yml .gitlab-ci.yml Jenkinsfile

⚠️ Common mistakes

porting a pipeline by translating YAML line by line instead of moving the logic into scripts first — you carry every quirk across and gain nothing
assuming the vocabulary maps one to one: a GitLab stage groups jobs that run in parallel, a Jenkins stage is one sequential block, and a CircleCI job is ordered only by requires:
comparing vendors on last year's free allowance or a blog post — the allowances change; check the current page before choosing

⏭️ Next

You can read all four forms. The last lesson is the mailroom's rulebook poster: what keeps a pipeline trustworthy for years, and the handoff to the ArgoCD school.

git checkout lesson-12-pipeline-hygiene

← Previousdeploy to kubernetes Next →pipeline hygiene

This page is the lesson's README from the lesson-11-four-dialects branch, shown here so the whole School stays on one site. Code files open on GitHub at the same branch.