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

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

📮 धडा 01 — CI/CD का: गृहपाठाचा ढीग

📍 तुम्ही इथे आहात: 12 पैकी धडा 01 · पुढे: lesson-02-pipeline-anatomy

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

कोर्सचा पाया: pipeline मुळात का असते, आणि तो छोटा ॲप जो courier सगळ्या 12 धड्यांमध्ये वाहून नेणार आहे. खऱ्या files:

app/server.js — demo ॲप (शून्य dependencies; port 3000 वर आपले hostname आणि version सांगतो, /healthz म्हणतो ok)
app/server.test.js — Node च्या built-in test runner ने लिहिलेल्या तीन तपासण्या; तपासणी डेस्क प्रत्येक push वर नेमक्या याच चालवते

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

अशा वर्गाची कल्पना करा जिथे सत्राच्या शेवटच्या दिवसापर्यंत कोणीच गृहपाठ देत नाही. तीस फोल्डर्स एकदम शिक्षिकेच्या टेबलावर येऊन पडतात. 📚 पाने उलटसुलट आहेत, दोन विद्यार्थ्यांनी आपल्या कागदांना वेगवेगळे क्रमांक दिले आहेत, एक उत्तर अशा worksheet वर अवलंबून आहे जी दुसरा कोणीतरी जोडायला विसरला. एकही पेपर तपासण्याआधीच शिक्षिका संपूर्ण weekend फक्त कोणाची पाने एकमेकांशी जुळतात हे शोधण्यात घालवते. 😩

तो weekend म्हणजे integration hell. Software मध्ये ते असे दिसते: पाच लोक आठवडेभर आपापल्या branches वर काम करतात, मग शुक्रवारी merge करतात, आणि निकाल build सुद्धा होत नाही.

आता एका वेगळ्या शाळेची कल्पना करा. प्रत्येक गृहपाठाचा कागद पूर्ण होताच त्याच दिवशी mailroom 📮 मध्ये जातो. एक courier robot तो उचलतो, तपासणी डेस्क ✅ वरून नेतो, आणि काही मिनिटांत शिक्का परत येतो: ✅ किंवा ❌. काहीच साचत नाही, कारण प्रत्येक कागद छोटा आणि ताजा असतानाच तपासला जातो — आणि एखादा fail झाला, तर नेमका कोणता कागद आणि का ते तुम्हाला कळते.

ती mailroom म्हणजे तुमची CI system. Robot चा मार्ग — तपासणी डेस्क, मग फोटोकॉपी मशीन 🍱, मग delivery van 🚚 — म्हणजे pipeline. हा कोर्स तो मार्ग बांधण्याबद्दल आहे, एका वेळी एक डेस्क.

🗺️ आकृती

flowchart LR
    pile["📚 term-end pile<br/>everything merged at once"]
    dev["🧑‍💻 you<br/>git push"]
    mail["📮 mailroom<br/>the CI system"]
    check["✅ checking desk<br/>node --test"]
    copy["🍱 photocopier<br/>docker build"]
    van["🚚 delivery van<br/>deploy"]
    board["📌 notice board<br/>Kubernetes Deployment"]
    dev -.->|"0 the old way"| pile
    dev -->|"1 every push"| mail
    mail -->|"2 check"| check
    check -->|"3 only if green"| copy
    copy -->|"4 lessons 07 to 10"| van
    van -->|"5 pin the new notice"| board

❓ काय

Continuous integration (CI) = छोटे बदल सामायिक main line मध्ये वारंवार merge करण्याची सवय, आणि प्रत्येक बदलावर आपोआप build-आणि-test run. मुद्दा सवयीचा आहे; tool म्हणजे फक्त mailroom.
Continuous delivery = main line नेहमी release करण्यायोग्य ठेवली जाते; production ला पाठवणे हा एका माणसाने बटण दाबून घेतलेला निर्णय असतो (प्राचार्यांची सही 🛑, धडा 08).
Continuous deployment = pipeline पास होणारा प्रत्येक बदल आपोआप production ला जातो. बटण नाही. Pipeline हीच सही आहे.
Pipeline = बदल ज्या क्रमाने, आपोआप जातो तो मार्ग: तपासा → copy करा → पोहोचवा. प्रत्येक थांबा एक job आहे; संपूर्ण मार्ग म्हणजे courier ची फेरी.
Integration hell = merge पुढे ढकलले की जे होते ते: conflicts, कोणाच्याच मालकीचा नसलेला build, आणि उत्खननात वाया गेलेला weekend.

🧠 तीन शब्द, शेजारी शेजारी

CI                      merge often, check each merge        → "it still works together"
Continuous delivery     main is releasable; a human ships    → the principal signs
Continuous deployment   every green change ships by itself   → no signature step

शेवटच्या दोन्हींसाठी "CD" वापरले जाते, म्हणूनच हा कोर्स त्याला कोणते म्हणायचे आहे ते नावाने सांगतो. बहुतेक teams delivery करतात; deployment म्हणजे सहीची पायरी काढून टाकलेली delivery — ही एक निवड आहे, upgrade नाही.

🤔 का

डबा कसा भरायचा (Docker शाळा) आणि तो कसा चालवायचा (Kubernetes शाळा) हे तुम्हाला आधीच माहीत आहे. जे हरवले आहे ते म्हणजे मधला प्रवास: git push पासून नवी image चालवणाऱ्या pod पर्यंत, प्रत्येक थांब्यावर शिक्क्यासह. हे हाताने केले तर ते क्वचित, रात्री उशिरा, पायऱ्या लक्षात असलेल्या एकाच व्यक्तीकडून होते. Pipeline ने केले तर ते प्रत्येक push वर, हुबेहूब तसेच, log सह होते.

म्हणूनच हा कोर्स Ops track मध्ये 3️⃣ क्रमांकावर आहे. तो delivery van ने फलकावर सूचना लावण्याने संपतो — push model — आणि van निघून गेल्यावर ती काय करू शकत नाही याच्या प्रामाणिक यादीने (drift, CI मध्ये राहणारी cluster credentials). तिथूनच ArgoCD शाळेचा धडा 03 पुढे सुरू होतो.

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

या धड्यात अजून कोणतीही pipeline नाही — फक्त गृहपाठ आणि उत्तरपत्रिका. app/server.js मधल्या ॲपमध्ये एक route आहे ज्याची संपूर्ण track ला काळजी आहे, कारण readiness probe (Kubernetes शाळा धडा 07) आणि smoke test (इथला धडा 07) दोघेही त्यालाच विचारतात:

  if (req.url === '/healthz') {                 // "are you ready?" — the readiness probe asks this
    res.writeHead(200, { 'content-type': 'text/plain' });
    return res.end('ok\n');
  }

तपासणी डेस्कची उत्तरपत्रिका म्हणजे app/server.test.js. ती server port 0 वर सुरू करते (कोणताही मोकळा port, म्हणजे तुम्ही चालू ठेवलेल्या copy शी tests ची टक्कर होत नाही) आणि नेमका body तपासते:

test('GET /healthz answers ok — what the readiness probe asks', () =>
  withServer(async (base) => {
    const res = await fetch(`${base}/healthz`);
    assert.equal(res.status, 200);
    assert.equal(await res.text(), 'ok\n');
  }));

दोन्ही files फक्त node:http, node:test आणि node:assert वापरतात — शून्य dependencies. हे जाणूनबुजून आहे: npm install नाही, lockfile नाही, download करायला काहीच नाही. पुढच्या धड्यांमध्ये run सावकाश किंवा लाल झाला, तर ते pipeline चे काम आहे, एखाद्या package चे नाही. app/package.json नुसार, संपूर्ण test command आहे "test": "node --test".

🧪 करून पाहा

# 0) you need Node 20 or newer (the tests use the built-in runner and fetch)
node --version

# 1) be the checking desk yourself
cd app
node --test                 # ✔ 3 tests, 3 pass — this exact command runs in CI from lesson 03 on

# 2) break the homework on purpose: make /healthz answer "okay" instead of "ok"
sed -i.bak "s/end('ok/end('okay/" server.js
node --test                 # ✖ GET /healthz answers ok … expected 'ok\n', actual 'okay\n'
echo "exit code: $?"        # non-zero — this is what turns a run red in lesson 03

# 3) fix it and confirm the stamp is green again
git checkout -- server.js && rm server.js.bak
node --test
cd ..

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

"आमच्याकडे Jenkins server आहे" याला continuous integration म्हणणे — CI म्हणजे छोटे आणि वारंवार merge, प्रत्येक merge वर तपासणीसह; server म्हणजे फक्त mailroom
delivery आणि deployment यांना समानार्थी समजणे — एक माणसाचे बटण ठेवते, दुसरे ते काढून टाकते, आणि रात्री 2 वाजता कोणाला page येणार ते त्यावरून ठरते
एखादी branch आठवडेभर जिवंत ठेवून शेवटी "integrate" करणे — प्रत्येक branch चा run कितीही हिरवा असला तरी तो सत्राच्या शेवटचा ढीगच आहे

⏭️ पुढे

Courier आपली पहिली फेरी करण्याआधी, त्याचे भाग शिका: त्याला सुरू करणारी घंटा, तो ज्या डेस्कना भेट देतो ते, आणि त्यावर बसणारे कारकून. 🧩

git checkout lesson-02-pipeline-anatomy

📮 Lesson 01 — Why CI/CD: the homework pile-up

📍 You are here: Lesson 01 of 12 · Next: lesson-02-pipeline-anatomy

📦 What's in this branch

The foundation of the course: why a pipeline exists at all, plus the tiny app the courier will carry through all 12 lessons. Real files:

app/server.js — the demo app (zero dependencies; answers on port 3000 with its hostname and version, /healthz says ok)
app/server.test.js — three checks written with Node's built-in test runner; the checking desk runs exactly these on every push

🧒 Explain like I'm 5

Imagine a class where nobody hands in homework until the last day of term. Thirty folders land on the teacher's desk at once. 📚 Pages are out of order, two students numbered their sheets differently, one answer depends on a worksheet someone else forgot to include. The teacher spends the whole weekend just working out whose pages fit together — before grading a single one. 😩

That weekend is integration hell. In software it looks like this: five people work on their own branches for weeks, then merge on Friday, and the result does not even build.

Now picture a different school. Every homework sheet goes into the mailroom 📮 the day it is finished. A courier robot picks it up, runs it past the checking desk ✅, and a stamp comes back within minutes: ✅ or ❌. Nothing piles up, because every sheet is checked while it is still small and fresh — and when one fails, you know exactly which sheet and why.

That mailroom is your CI system. The robot's route — checking desk, then the photocopier 🍱, then the delivery van 🚚 — is the pipeline. This course is about building that route, one desk at a time.

🗺️ Diagram

flowchart LR
    pile["📚 term-end pile<br/>everything merged at once"]
    dev["🧑‍💻 you<br/>git push"]
    mail["📮 mailroom<br/>the CI system"]
    check["✅ checking desk<br/>node --test"]
    copy["🍱 photocopier<br/>docker build"]
    van["🚚 delivery van<br/>deploy"]
    board["📌 notice board<br/>Kubernetes Deployment"]
    dev -.->|"0 the old way"| pile
    dev -->|"1 every push"| mail
    mail -->|"2 check"| check
    check -->|"3 only if green"| copy
    copy -->|"4 lessons 07 to 10"| van
    van -->|"5 pin the new notice"| board

❓ What

Continuous integration (CI) = the habit of merging small changes into the shared main line frequently, with an automated build-and-test run on each one. The point is the habit; the tool is just the mailroom.
Continuous delivery = the main line is kept releasable at all times; shipping to production is a decision a human makes by pressing a button (the principal's signature 🛑, lesson 08).
Continuous deployment = every change that passes the pipeline goes to production automatically. No button. The pipeline is the signature.
Pipeline = the ordered, automated route a change takes: check → copy → deliver. Each stop is a job; the whole route is the courier's round.
Integration hell = what happens when merging is postponed: conflicts, a build nobody owns, and a weekend lost to archaeology.

🧠 The three words, side by side

CI                      merge often, check each merge        → "it still works together"
Continuous delivery     main is releasable; a human ships    → the principal signs
Continuous deployment   every green change ships by itself   → no signature step

"CD" is used for both of the last two, which is why this course names the one it means. Most teams practice delivery; deployment is delivery with the signature step removed — a choice, not an upgrade.

🤔 Why

You already know how to pack the lunchbox (Docker school) and how to run it (Kubernetes school). What is missing is the trip in between: from git push to a pod running the new image, with a stamp at every stop. Do that by hand and it happens rarely, late at night, by the one person who remembers the steps. Do it with a pipeline and it happens on every push, identically, with a log.

That is why this course sits at position 3️⃣ of the Ops track. It ends with the delivery van pinning a notice on the board — the push model — and with an honest list of what the van cannot do after it drives away (drift, cluster credentials living in CI). That list is where the ArgoCD school's lesson 03 picks up.

🔧 How (in this repo)

There is no pipeline in this lesson yet — only the homework and the answer key. The app in app/server.js has one route the whole track cares about, because the readiness probe (Kubernetes school lesson 07) and the smoke test (lesson 07 here) both ask it:

  if (req.url === '/healthz') {                 // "are you ready?" — the readiness probe asks this
    res.writeHead(200, { 'content-type': 'text/plain' });
    return res.end('ok\n');
  }

The checking desk's answer key is app/server.test.js. It starts the server on port 0 (any free port, so tests do not collide with a copy you left running) and asserts the exact body:

test('GET /healthz answers ok — what the readiness probe asks', () =>
  withServer(async (base) => {
    const res = await fetch(`${base}/healthz`);
    assert.equal(res.status, 200);
    assert.equal(await res.text(), 'ok\n');
  }));

Both files use only node:http, node:test and node:assert — zero dependencies. That is deliberate: no npm install, no lockfile, nothing to download. When a run is slow or red in later lessons, it is the pipeline's doing, not a package's. From app/package.json, the whole test command is "test": "node --test".

🧪 Try it

# 0) you need Node 20 or newer (the tests use the built-in runner and fetch)
node --version

# 1) be the checking desk yourself
cd app
node --test                 # ✔ 3 tests, 3 pass — this exact command runs in CI from lesson 03 on

# 2) break the homework on purpose: make /healthz answer "okay" instead of "ok"
sed -i.bak "s/end('ok/end('okay/" server.js
node --test                 # ✖ GET /healthz answers ok … expected 'ok\n', actual 'okay\n'
echo "exit code: $?"        # non-zero — this is what turns a run red in lesson 03

# 3) fix it and confirm the stamp is green again
git checkout -- server.js && rm server.js.bak
node --test
cd ..

⚠️ Common mistakes

calling "we have a Jenkins server" continuous integration — CI is merging small and often with a check on each merge; the server is just the mailroom
treating delivery and deployment as synonyms — one keeps a human button, the other removes it, and that decides who gets paged at 2 a.m.
keeping a branch alive for weeks and then "integrating" at the end — that is the term-end pile, no matter how green each branch's run was

⏭️ Next

Before the courier makes its first round, learn its parts: the bell that starts it, the desks it visits, and the clerks who staff them. 🧩

git checkout lesson-02-pipeline-anatomy

← Course homeall lessons Next →pipeline anatomy

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