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

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

🧪 धडा 06 — मागणीनुसार environments: प्रत्येक बदलासाठी एक चाचणी वर्गखोली

📍 तुम्ही इथे आहात: 12 पैकी धडा 06 · मागे: lesson-05-self-service-infra · पुढे: lesson-07-paved-pipelines

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

धडे 01–05, आणि preview environments: प्रत्येक pull request ला service ची स्वतःची, थोड्या काळाची copy मिळते, स्वतःच्या पत्त्यावर, म्हणजे reviewers merge होण्याआधी बदल क्लिक करून पाहू शकतात. PR बंद झाला की, किंवा त्याचा time-to-live (TTL) संपला की environment हटवले जाते, आणि एक cap एका वेळी किती चालू शकतात ते मर्यादित करते. idp/selfserve.py मधले PreviewEnvs, idp/demo.py मधले previews().

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

विज्ञान प्रयोगशाळा खरोखर बदलण्याआधी कतरिनाला नवी मांडणी करून पाहायची आहे. सुविधा कार्यालय तिला एक चाचणी वर्गखोली 🧪 देते, दारावर पाटी लावून: "pr-101 — चाचणी मांडणी". इतर शिक्षिका आत येतात आणि त्यांना काय वाटते ते सांगतात.

दोन नियम शाळा नीटनेटकी ठेवतात:

कतरिना "झाले" म्हणते (PR बंद किंवा merge होतो) तेव्हा चाचणी खोली रिकामी केली जाते.
48 तास कोणीच चाचणी खोलीला हात लावला नाही तर ती तरीही रिकामी केली जाते. ⏰ प्रत्येक वेळी कतरिना काही बदलते (एक push), तेव्हा 48 तास पुन्हा सुरू होतात.

आणि चाचणी खोल्या फक्त 3 आहेत. तिन्ही वापरात असतील तर पुढच्या शिक्षिकेला सांगितले जाते "कोणतीच खोली मोकळी नाही — एखादी बंद झाली की पुन्हा प्रयत्न करा."

नियम 2 नसता तर कोणालाच आठवत नसलेल्या चाचणी खोल्या कायमच्या तशाच मांडलेल्या राहिल्या असत्या, आणि शाळेने वर्षभर त्यांच्या दिव्यांचे बिल भरले असते.

🗺️ आकृती

flowchart LR
    o["🔀 PR opened"] --> cap{"🧪 fewer than 3 live?"}
    cap -->|"no"| rf["❌ refused — retry<br/>when one closes"]
    cap -->|"yes"| env["🌐 pr-101.preview.school.test"]
    env -->|"push: TTL restarts"| env
    env -->|"PR closed"| del["🧹 deleted"]
    env -->|"48 h with no push"| exp["⏰ expired"]
    sum["one week: 223 env-hours with cleanup<br/>674 if nobody deleted them"]

🗺️ काढलेली आकृती + एक lab: https://school-edh.pages.dev/platform-engineering/lesson-diagrams.html#l06

❓ काय

Preview environment (याला ephemeral, review किंवा per-PR environment सुद्धा म्हणतात) — एका branch चे तात्पुरते deployment, अनेकदा स्वतःच्या Kubernetes namespace मध्ये, स्वतःच्या URL सह. Vercel आणि Netlify सारखे hosting platforms web front-ends साठी "deploy previews" देतात; back-end services साठी platforms ते Argo CD सारख्या tools ने बनवतात.
TTL (time-to-live) — एखादी गोष्ट कोणत्याही हालचालीशिवाय किती वेळ राहू शकते, त्यानंतर ती हटवली जाते. इथे तो प्रत्येक push वर पुन्हा सुरू होतो, म्हणजे चालू असलेल्या PR चे environment टिकते.
Cap (जास्तीत जास्त चालू environments) — सामायिक cluster आणि बजेटचे रक्षण करतो. Cap च्या पलीकडे विनंती नाकारली जाते (किंवा काही designs मध्ये रांगेत ठेवली जाते).
Environment-hours — environments किती तास चालले, त्याची बेरीज. खर्च पाहण्याचा एक सोपा मार्ग: ढोबळमानाने, खर्च ≈ environment-hours × प्रति तास खर्च.
Abandoned PR — असा PR जो कोणी बंद करत नाही आणि ज्यावर कोणी push करत नाही. TTL नसेल तर त्याचे environment कोणाच्या लक्षात येईपर्यंत चालत राहते.
Shared dependencies — preview कडे सहसा service ची स्वतःची copy असते, पण काही जड भाग, जसे मोठा database, तो seeded test data सह वाटून घेतो (किंवा नकली वापरतो). कशाची copy करायची आणि काय वाटून घ्यायचे हे निवडणे हाच अवघड design प्रश्न आहे.

🤔 का

कारण एकच सामायिक "staging" environment स्वतःच एक रांग बनते: एका team चा अर्धवट बदल सगळ्यांचे testing अडवतो. Per-PR environments ती वाट काढून टाकतात आणि reviewers ना खरा बदल पाहू देतात. पण मागणीनुसार बनवलेले environments विसरणे सोपे असते, आणि विसरलेली environments दर तासाला पैसे खातात. साफसफाईचे नियमच मागणीनुसार environments परवडणारी बनवतात.

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

idp/selfserve.py मधले PreviewEnvs(ttl_h, max_live) तीन events हाताळते: open (cap गाठला नसेल तर बनवा), push (TTL पुन्हा सुरू करा) आणि close (हटवा). प्रत्येक event आधी ज्यांची शेवटची हालचाल TTL पेक्षा जुनी आहे अशी environments ते expire करते. finish(end) उरलेली expire करते आणि एकूण environment-hours परत देते. env_hours_without_cleanup() ही "कोणीच काहीच कधी हटवत नाही" अशी तुलना आहे: बनवलेले प्रत्येक environment आठवड्याच्या शेवटपर्यंत चालते. idp/demo.py मधले previews() 6 PRs चा एक आठवडा (168 तास) खेळून दाखवते.

🧪 करून पाहा

python3 idp/demo.py previews
python3 - <<'EOF'
import sys; sys.path.insert(0, "idp"); from selfserve import PreviewEnvs
events = [(1, "open", 101), (5, "open", 102), (10, "open", 103), (20, "close", 101), (30, "open", 104), (40, "push", 103),
          (41, "open", 105), (70, "close", 103), (120, "open", 106)]
for ttl, cap in ((24, 3), (48, 3), (48, 5), (168, 5)):
    pe = PreviewEnvs(ttl_h=ttl, max_live=cap)
    for t, a, pr in events: pe.event(t, a, pr)
    hours = pe.finish(168)
    refused = [m for _, m in pe.log if "refused" in m]
    print(f"TTL {ttl:>3} h, cap {cap} → {len(pe.created)} made · {hours:>3} env-hours · refused {len(refused)}")
EOF

✅ तपासा — तुम्हाला काय दिसायला हवे

previews हे छापते:

   h40   pr-103 updated, TTL restarts
   h41   pr-105 refused — 3 previews already live; retry when one closes
   h53   pr-102 expired (TTL 48 h)
   h70   pr-103 deleted (PR closed)
   h78   pr-104 expired (TTL 48 h)
── after one week (168 h): 5 previews made · 223 environment-hours with cleanup · 674 if nobody ever deleted them

तुमचा snippet हे छापतो:

TTL  24 h, cap 3 → 6 made · 139 env-hours · refused 0
TTL  48 h, cap 3 → 5 made · 223 env-hours · refused 1
TTL  48 h, cap 5 → 6 made · 271 env-hours · refused 0
TTL 168 h, cap 5 → 6 made · 555 env-hours · refused 0

🏁 तुम्ही आत्ताच काय सिद्ध केले

साफसफाईने त्याच PRs सह एका आठवड्याचे 674 environment-hours 223 वर आणले — सुमारे एक तृतीयांश. pr-103 वर तास 40 ला push झाला, म्हणून तो तास 58 ला expire होण्याऐवजी तास 70 ला बंद होईपर्यंत टिकला. लहान TTL (24 h) आणखी स्वस्त आहे (139) आणि त्याने नकारही टाळला, कारण खोल्या लवकर मोकळ्या झाल्या — पण तो reviewer दुसऱ्या दिवशी सकाळी उघडू शकेल असे environment सुद्धा हटवतो. कडक cap शिवाय लांब TTL (168 h) 555 खर्च करतो. TTL आणि cap हे product निर्णय आहेत: सोयीच्या विरुद्ध खर्च.

📏 शिकवण्याचे मॉडेल: खरी environments बनायला काही मिनिटे लागतात आणि त्यांचा एक ठरलेला खर्च असतो (databases, load balancers). Environment-hours हा खर्चाचा ढोबळ संकेत आहे, bill नाही.

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

TTL नाही — abandoned PRs आठवडेनआठवडे environments चालू ठेवतात
app हटवणे पण त्याने जे बनवले ते नाही (namespaces, volumes, DNS records, databases)
एकच बदलता database वाटून घेणारे previews, त्यामुळे दोन PRs एकमेकांचा data बिघडवतात
production सारखे अजिबात नसलेले previews, त्यामुळे "preview मध्ये चालले" याला फारसा अर्थ नसतो
previews मध्ये खऱ्या ग्राहकांचा data टाकणे

🏭 प्रत्यक्ष वापरात

Argo CD ApplicationSets मध्ये एक Pull Request generator असतो: तो Git host कडून open PRs विचारतो आणि प्रत्येक PR साठी एक Argo CD Application बनवतो. खऱ्या cluster वर:

apiVersion: argoproj.io/v1alpha1
kind: ApplicationSet
metadata:
  name: exam-results-previews
  namespace: argocd
spec:
  goTemplate: true
  generators:
    - pullRequest:
        github:
          owner: school
          repo: exam-results
          labels: [preview]          # only PRs with this label get an environment
        requeueAfterSeconds: 300     # how often to ask GitHub for open PRs
  template:
    metadata:
      name: 'exam-results-pr-{{.number}}'
    spec:
      project: default
      source:
        repoURL: https://github.com/school/exam-results.git
        targetRevision: '{{.head_sha}}'
        path: deploy
      destination:
        server: https://kubernetes.default.svc
        namespace: 'preview-pr-{{.number}}'
      syncPolicy:
        automated: {prune: true}
        syncOptions: [CreateNamespace=true]

PR बंद झाला की generator त्याला यादीत दाखवत नाही, आणि ApplicationSet ते Application काढून टाकतो. CreateNamespace=true ने बनवलेले namespace त्याच्याबरोबर हटवले जात नाही — ते वेगळे साफ करा, किंवा Namespace chart मध्ये ठेवा. Argo CD ला स्वतःचा TTL नाही; kube-janitor हे एक open-source tool आहे जे janitor/ttl: "48h" सारखी annotation असलेले resources हटवते.

🏭 प्रत्यक्ष वापरात हे का महत्त्वाचे: cost report वर previews ची स्वतःची वेगळी ओळ ठेवा. तो आकडा PRs च्या संख्येपेक्षा जास्त वेगाने वाढत असेल तर साफसफाईत गळती आहे.

⏭️ पुढे

प्रत्येक PR build, test आणि deploy होतो. पुढे: ती pipeline शंभर copy केलेल्या YAML files ऐवजी एक सामायिक, version असलेला रस्ता बनवणे.

git checkout lesson-07-paved-pipelines

🧪 Lesson 06 — Environments on demand: a trial classroom per change

📍 You are here: Lesson 06 of 12 · Previous: lesson-05-self-service-infra · Next: lesson-07-paved-pipelines

📦 What's in this branch

Lessons 01–05, plus preview environments: every pull request gets its own short-lived copy of the service, at its own address, so reviewers can click through the change before it is merged. The environment is deleted when the PR closes, or when its time-to-live (TTL) runs out, and a cap limits how many run at once. PreviewEnvs in idp/selfserve.py, previews() in idp/demo.py.

🧒 Explain like I'm 5

Before Katrina changes the science lab for real, she wants to try the new layout. The facilities office lends her a trial classroom 🧪 with a sign on the door: "pr-101 — trial layout". Other teachers walk in and say what they think.

Two rules keep the school tidy:

When Katrina says "done" (the PR is closed or merged), the trial room is cleared.
If nobody touches the trial room for 48 hours, it is cleared anyway. ⏰ Every time Katrina changes something (a push), the 48 hours start again.

And there are only 3 trial rooms. When all three are in use, the next teacher is told "no room free — try again when one closes."

Without rule 2, trial rooms nobody remembered would stay set up forever, and the school would pay for their lights all year.

🗺️ Diagram

flowchart LR
    o["🔀 PR opened"] --> cap{"🧪 fewer than 3 live?"}
    cap -->|"no"| rf["❌ refused — retry<br/>when one closes"]
    cap -->|"yes"| env["🌐 pr-101.preview.school.test"]
    env -->|"push: TTL restarts"| env
    env -->|"PR closed"| del["🧹 deleted"]
    env -->|"48 h with no push"| exp["⏰ expired"]
    sum["one week: 223 env-hours with cleanup<br/>674 if nobody deleted them"]

🗺️ Drawn version + a lab: https://school-edh.pages.dev/platform-engineering/lesson-diagrams.html#l06

❓ What

Preview environment (also called an ephemeral, review or per-PR environment) — a temporary deployment of a branch, often in its own Kubernetes namespace, with its own URL. Hosting platforms such as Vercel and Netlify offer "deploy previews" for web front-ends; for back-end services, platforms build them with tools like Argo CD.
TTL (time-to-live) — how long something may live without activity before it is deleted. Here it restarts on every push, so an active PR keeps its environment.
Cap (maximum live environments) — protects the shared cluster and the budget. Beyond the cap, a request is refused (or queued, in some designs).
Environment-hours — how many hours environments were running, added up. A simple way to see cost: roughly, cost ≈ environment-hours × cost per hour.
Abandoned PR — a PR nobody closes and nobody pushes to. Without a TTL its environment runs until someone notices.
Shared dependencies — a preview usually has its own copy of the service but shares (or fakes) some heavy parts, like a big database, with seeded test data. Choosing what to copy and what to share is the hard design question.

🤔 Why

Because a shared "staging" environment becomes a queue of its own: one team's half-done change blocks everyone's testing. Per-PR environments remove that wait and let reviewers see the real change. But created-on-demand environments are easy to forget, and forgotten environments cost money every hour. The cleanup rules are what make on-demand environments affordable.

🔧 How (in this repo)

PreviewEnvs(ttl_h, max_live) in idp/selfserve.py handles three events: open (create, unless the cap is reached), push (restart the TTL) and close (delete). Before each event it expires environments whose last activity is older than the TTL. finish(end) expires the rest and returns total environment-hours. env_hours_without_cleanup() is the "nobody ever deletes anything" comparison: every created environment runs to the end of the week. previews() in idp/demo.py plays one week (168 hours) of 6 PRs.

🧪 Try it

python3 idp/demo.py previews
python3 - <<'EOF'
import sys; sys.path.insert(0, "idp"); from selfserve import PreviewEnvs
events = [(1, "open", 101), (5, "open", 102), (10, "open", 103), (20, "close", 101), (30, "open", 104), (40, "push", 103),
          (41, "open", 105), (70, "close", 103), (120, "open", 106)]
for ttl, cap in ((24, 3), (48, 3), (48, 5), (168, 5)):
    pe = PreviewEnvs(ttl_h=ttl, max_live=cap)
    for t, a, pr in events: pe.event(t, a, pr)
    hours = pe.finish(168)
    refused = [m for _, m in pe.log if "refused" in m]
    print(f"TTL {ttl:>3} h, cap {cap} → {len(pe.created)} made · {hours:>3} env-hours · refused {len(refused)}")
EOF

✅ Verify — what you should see

previews prints:

   h40   pr-103 updated, TTL restarts
   h41   pr-105 refused — 3 previews already live; retry when one closes
   h53   pr-102 expired (TTL 48 h)
   h70   pr-103 deleted (PR closed)
   h78   pr-104 expired (TTL 48 h)
── after one week (168 h): 5 previews made · 223 environment-hours with cleanup · 674 if nobody ever deleted them

Your snippet prints:

TTL  24 h, cap 3 → 6 made · 139 env-hours · refused 0
TTL  48 h, cap 3 → 5 made · 223 env-hours · refused 1
TTL  48 h, cap 5 → 6 made · 271 env-hours · refused 0
TTL 168 h, cap 5 → 6 made · 555 env-hours · refused 0

🏁 What you just proved

Cleanup cut a week from 674 to 223 environment-hours — about a third — with the same PRs. pr-103 was pushed at hour 40, so it lived to its close at hour 70 instead of expiring at hour 58. A shorter TTL (24 h) is cheaper still (139) and even avoided the refusal, because rooms freed up sooner — but it also deletes an environment a reviewer might open the next morning. A long TTL (168 h) without a tight cap costs 555. TTL and cap are product decisions: cost against convenience.

📏 Teaching model: real environments take minutes to create and have a fixed cost part (databases, load balancers). Environment-hours are a rough cost signal, not a bill.

⚠️ Common mistakes

no TTL — abandoned PRs keep environments running for weeks
deleting the app but not what it created (namespaces, volumes, DNS records, databases)
previews that share one mutable database, so two PRs corrupt each other's data
previews that are nothing like production, so "it worked in the preview" means little
putting real customer data into previews

🏭 In production

Argo CD ApplicationSets have a Pull Request generator: it asks the Git host for open PRs and makes one Argo CD Application per PR. On a real cluster:

apiVersion: argoproj.io/v1alpha1
kind: ApplicationSet
metadata:
  name: exam-results-previews
  namespace: argocd
spec:
  goTemplate: true
  generators:
    - pullRequest:
        github:
          owner: school
          repo: exam-results
          labels: [preview]          # only PRs with this label get an environment
        requeueAfterSeconds: 300     # how often to ask GitHub for open PRs
  template:
    metadata:
      name: 'exam-results-pr-{{.number}}'
    spec:
      project: default
      source:
        repoURL: https://github.com/school/exam-results.git
        targetRevision: '{{.head_sha}}'
        path: deploy
      destination:
        server: https://kubernetes.default.svc
        namespace: 'preview-pr-{{.number}}'
      syncPolicy:
        automated: {prune: true}
        syncOptions: [CreateNamespace=true]

When the PR closes, the generator no longer lists it, and the ApplicationSet removes that Application. A namespace created by CreateNamespace=true is not deleted with it — clean it up separately, or put the Namespace in the chart. Argo CD has no TTL of its own; kube-janitor is one open-source tool that deletes resources with an annotation such as janitor/ttl: "48h".

🏭 Why this matters in production: put previews on the cost report as their own line. If the number grows faster than the number of PRs, cleanup is leaking.

⏭️ Next

Every PR builds, tests and deploys. Next: making that pipeline a shared, versioned road instead of a hundred copied YAML files.

git checkout lesson-07-paved-pipelines

← Previousself service infra Next →paved pipelines

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