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

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

🛑 धडा 08 — Environments & मंजुरीचे गेट: प्राचार्यांची सही

📍 तुम्ही इथे आहात: 12 पैकी धडा 08 · मागील: lesson-07-build-push-image · पुढील: lesson-09-deploy-strategies

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

धडे 01–07, आणि त्याशिवाय हिरवी खूण आणि मुख्य सूचना फलक यांच्यामधली दोन दारे: पुढचे दार (branch protection) आणि प्राचार्यांचे कार्यालय (approval gate). खऱ्या files:

.github/workflows/deploy.yml — environment: staging, मग required reviewers मागे environment: production
.github/workflows/ship.yml — 🚚 deliver job, जो यशस्वी push नंतर deploy.yml ला बोलावतो
.github/workflows/ci.yml — name: test (node ${{ matrix.node }}): जो check तुम्ही required करता त्याचे नाव
.circleci/config.yml, .gitlab-ci.yml, Jenkinsfile — type: approval, when: manual, input

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

शाळेत दोन सूचना फलक आहेत. शिक्षकांच्या खोलीतला सराव फलक 📌 — इथे courier नवी सूचना आधी लावतो, म्हणजे शिक्षिका ती नीट वाचता येते का ते तपासू शकते. सभागृहातला मुख्य फलक वर्गांना दिसतो. CI मध्ये हे आहेत staging आणि production — या कोर्समध्ये, एकाच cluster वरचे दोन namespaces.

दोन फलकांच्या मध्ये आहे प्राचार्यांचे कार्यालय 🛑. नावानिशी व्यक्ती सही करेपर्यंत व्हॅन सूचना घेऊन दारात थांबते, आणि ती सही एका नोंदवहीत जाते: कोणी, केव्हा, कोणती सूचना. हेच approval gate — required reviewer Approve वर click करेपर्यंत run production job वर थांबतो.

त्याच्याही आधी एक दार आहे. तपासणी डेस्कवर ✅ न मिळालेला गृहपाठ "copy करायचे" ट्रेपर्यंत पोहोचूच नये. Branch protection मुळे test (node 22) check ही merge बटणाची अट होते: लाल check, merge नाही.

हा मार्ग trunk-based आहे: छोटे बदल वारंवार main मध्ये merge होतात (branches आठवडे नव्हे, तास जगतात), आणि build होऊन पाठवली जाणारी एकमेव गोष्ट म्हणजे main. गेट म्हणजे "कोणती branch" नाही — तर "कोणता check पास झाला, आणि कोणी सही केली".

🗺️ आकृती

flowchart LR
    pr["🔀 pull request<br/>required check: test (node 22)"]
    main["🌳 main<br/>protected branch"]
    stg["📌 staging job<br/>environment: staging"]
    gate["🛑 production environment<br/>required reviewers, wait timer<br/>approval recorded"]
    prod["📌 production job<br/>environment: production"]
    pr -->|"1 green check, merge"| main
    main -->|"2 ship builds and pushes, then"| stg
    stg -->|"3 pauses here"| gate
    gate -->|"4 a human clicks Approve"| prod

❓ काय

Environment (GitHub) = नाव दिलेले deploy target (staging, production), ज्याचे स्वतःचे protection rules, secrets आणि variables असतात. environment: production जाहीर करणारा job त्याच्या नियमांखाली चालतो.
Required reviewers = जास्तीत जास्त सहा व्यक्ती किंवा teams; job सुरू होण्याआधी त्यांपैकी एकाने approve केलेच पाहिजे. ऐच्छिक: prevent self-review. Wait timer = job पुढे जाण्याआधी मिनिटांत ठरलेला विलंब (30 दिवसांपर्यंत).
Deployment branches and tags = तिथे कोणते refs deploy करू शकतात — "protected branches only" किंवा main सारखी नावांची यादी.
Branch protection (किंवा ruleset) = main वरचे नियम: pull request आवश्यक, status checks पास होणे आवश्यक, हवे तर reviews आवश्यक. Check चे नाव job वरून येते — name: test (node ${{ matrix.node }}) मधून test (node 22) मिळते.
Audit trail = प्रत्येक environment deployment run, approver, वेळ आणि कोणताही comment नोंदवते.

🧠 दोन दारे, दोन प्रश्न

दार	कुठे	प्रश्न	उत्तर कोण देते
पुढचे दार	pull request → `main`	तपासणी डेस्कने ✅ शिक्का मारला का?	robot — required status check
प्राचार्यांचे कार्यालय	staging → production	ही copy मुख्य फलकावर जावी का?	नावानिशी माणूस — required reviewer

🤔 का

हिरवी test सांगते की code नीट वागतो; config, cluster, किंवा प्रत्यक्ष build झालेल्या image बद्दल ती काहीच सांगत नाही. अशा प्रकारचे आश्चर्य staging स्वस्तात पकडते. Approval मुळे माणसाला एक क्षण मिळतो आणि शाळेला एक नोंद मिळते: मुख्य फलक बिघडला की "कोणी काय, केव्हा approve केले" हे शोधून पाहायचे असते, वादाचा विषय नसतो. Branch protection मुळे बाकी सगळे टिकते — जर न तपासलेला code सरळ main मध्ये शिरू शकत असेल, तर production वरच्या गेटला फारशी किंमत नाही. ArgoCD शाळेचा धडा 03 व्हॅन बदलण्याआधी नेमक्या याच push pipeline पासून सुरू होतो.

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

दोन jobs, दोन environments. deploy.yml आधी staging, मग production चालवते; needs: त्यांचा क्रम ठरवते, environment: नियम जोडते:

  staging:
    runs-on: ubuntu-latest
    environment: staging                          # the practice notice board

  production:
    needs: staging
    runs-on: ubuntu-latest
    environment: production                       # 🛑 required reviewers = the principal's signature

YAML मध्ये कुठेही "approval साठी थांबा" असे लिहिलेले नाही. File च्या header मध्ये म्हटल्याप्रमाणे, production environment "must be created once in Settings → Environments with Required reviewers — THAT checkbox is the approval gate" — म्हणजे तो एकदा Settings मध्ये तयार करावा लागतो, आणि तो checkbox हेच approval gate आहे.

थांबा कसा चालतो. Run production job पर्यंत पोहोचला की GitHub त्या environment चे protection rules तपासतो. Required reviewers लावलेले असतील तर job Waiting दाखवतो आणि run summary मध्ये Review deployments बटण येते. यादीतला reviewer approve किंवा reject करतो, हवे तर comment सह; approve → job त्या environment च्या secrets आणि variables सह सुरू होतो, reject → job fail होतो. हा निर्णय run सोबत जपला जातो (summary मध्ये कोणी approve केले ते दिसते) आणि environment च्या deployment history मध्येही — gh api repos/{owner}/{repo}/actions/runs/<id>/approvals ने सुद्धा वाचता येतो.

सेटअप (एकदाच, fork मध्ये). Settings → Environments → New environment → production → Required reviewers वर खूण करा आणि स्वतःला जोडा → हवे तर Wait timer → Deployment branches and tags → selected branches → main. staging सुद्धा तयार करा, reviewers शिवाय. Public repositories ना सध्याच्या plans वर protection rules मिळतात; private साठी paid plan लागू शकतो — GitHub चे docs तपासा.

पुढचे दार. Settings → Branches (classic) किंवा Settings → Rules (rulesets) → main protect करा → Require status checks to pass before merging → test (node 22) जोडा. मग लाल check असलेल्या pull request वर Merging is blocked दिसते.

व्हॅनला कुठे बोलावले जाते. ship.yml मध्ये 🚚 deliver job (uses: ./.github/workflows/deploy.yml) फक्त vars.EKS_CLUSTER सेट असेल तेव्हाच अस्तित्वात असतो — AWS नसलेल्या fork वर तो जाणूनबुजून skip होतो.

🔁 हेच CircleCI मध्ये

      - hold-for-approval:               # 🛑 the principal's signature: click Approve in the UI
          type: approval
          requires: [deploy-staging]

Approval job म्हणजे steps नसलेली जागा राखणारी खूण; project वर write access असलेली कोणी व्यक्ती त्यावर click करेपर्यंत workflow तिथे थांबतो, deploy-production त्याला requires: मध्ये लिहितो, आणि workflow page वर कोणी click केले ते दिसते.

🦊 हेच GitLab CI मध्ये

deploy-production:
  <<: *deploy
  needs: [deploy-staging]
  environment: { name: production }
  when: manual                                # 🛑 the principal's signature: a human presses ▶ in the UI

when: manual play बटण काढते; environment: deployment ला त्याच्या history सह Operate → Environments खाली नोंदवते. Play कोण दाबू शकते हे मर्यादित करणे म्हणजे protected environment, जे हे लिहिताना paid-tier feature आहे.

🎩 हेच Jenkins मध्ये

    stage('🛑 approve') {
      options { timeout(time: 2, unit: 'DAYS') }
      steps { input message: 'Deploy to production?', ok: 'Approve' }   // the principal's signature
    }

input build थांबवते आणि approver चे नाव build log मध्ये येते. दोन दिवसांचा timeout विसरलेला build अनिश्चित काळ उघडा ठेवण्याऐवजी abort करतो; input ला submitter: यादीही देता येते, जी कोण click करू शकते ते ठरवते (# illustrative).

🧪 करून पाहा

हे AWS शिवाय public fork वर चालते. धडा 06 चे variables आणि EKS_CLUSTER अस्तित्वात येईपर्यंत deploy jobs स्वतः skip राहतात, म्हणून staging प्रत्यक्ष चालल्यावरच Review deployments बटण दिसते.

# 1) the front door: make "test (node 22)" a required check on main, for admins too
gh api -X PUT "repos/{owner}/{repo}/branches/main/protection" --input - <<< '{ "required_status_checks":
  { "strict": true, "contexts": ["test (node 22)"] }, "enforce_admins": true, "required_pull_request_reviews": null, "restrictions": null }'

# 2) open a PR that breaks a test and watch the merge get blocked
git checkout -b break-a-test
sed -i.bak 's/writeHead(404/writeHead(500/' app/server.js && rm app/server.js.bak
git commit -am "break the 404 test on purpose" && git push -u origin break-a-test
gh pr create --fill && gh pr checks --watch     # test (node 22) ❌
gh pr merge --squash                            # refused: the base branch policy prohibits the merge
git checkout main && gh pr close break-a-test --delete-branch

# 3) the principal's office: create the production environment with yourself as reviewer
gh api -X PUT "repos/{owner}/{repo}/environments/production" --input - <<JSON
{ "wait_timer": 0, "reviewers": [ { "type": "User", "id": $(gh api user --jq .id) } ],
  "deployment_branch_policy": { "protected_branches": true, "custom_branch_policies": false } }
JSON
# then open Settings → Environments → production in the browser and read the three switches

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

main protect करणे पण administrators साठी ते लागू न करणे — नियम टाळू शकणारी एकमेव व्यक्ती हीच सहसा घाईत असते
environment: production लिहून तेवढ्यानेच काहीतरी gate होते असे समजणे — protection rules लावले नसतील तर job सरळ चालतो
team repository वर एकच reviewer, wait timer नाही, self-review ला परवानगी — रात्री 2 वाजता एक थकलेली व्यक्ती उघडू शकेल असे गेट म्हणजे निव्वळ औपचारिकता

⏭️ पुढे

प्राचार्यांनी सही केली. आता, मधे फलक रिकामा न राहता नवी सूचना जुनी कशी बदलते — आणि कालची परत कशी लावायची? 🔁

git checkout lesson-09-deploy-strategies

🛑 Lesson 08 — Environments & approval gates: the principal's signature

📍 You are here: Lesson 08 of 12 · Previous: lesson-07-build-push-image · Next: lesson-09-deploy-strategies

📦 What's in this branch

Lessons 01–07, plus the two doors between a green check and the main notice board: the front door (branch protection) and the principal's office (the approval gate). Real files:

.github/workflows/deploy.yml — environment: staging, then environment: production behind required reviewers
.github/workflows/ship.yml — the 🚚 deliver job that calls deploy.yml after a successful push
.github/workflows/ci.yml — name: test (node ${{ matrix.node }}): the check name you make required
.circleci/config.yml, .gitlab-ci.yml, Jenkinsfile — type: approval, when: manual, input

🧒 Explain like I'm 5

The school has two notice boards. The practice board 📌 in the staff room is where the courier pins a new notice first, so a teacher can check it reads right. The main board in the hall is what the classes see. In CI those are staging and production — in this course, two namespaces on one cluster.

Between the boards sits the principal's office 🛑. The van waits at the door with the notice until a named person signs, and the signature goes in a log book: who, when, which notice. That is an approval gate — the run pauses on the production job until a required reviewer clicks Approve.

There is an earlier door too. Homework that failed the checking desk ✅ shouldn't reach the "to copy" tray at all. Branch protection makes the test (node 22) check a condition of the merge button: red check, no merge.

The route is trunk-based: small changes merge into main often (branches live hours, not weeks), and main is the one thing that gets built and shipped. The gate is not "which branch" — it is "which check passed, and who signed".

🗺️ Diagram

flowchart LR
    pr["🔀 pull request<br/>required check: test (node 22)"]
    main["🌳 main<br/>protected branch"]
    stg["📌 staging job<br/>environment: staging"]
    gate["🛑 production environment<br/>required reviewers, wait timer<br/>approval recorded"]
    prod["📌 production job<br/>environment: production"]
    pr -->|"1 green check, merge"| main
    main -->|"2 ship builds and pushes, then"| stg
    stg -->|"3 pauses here"| gate
    gate -->|"4 a human clicks Approve"| prod

❓ What

Environment (GitHub) = a named deploy target (staging, production) with its own protection rules, secrets and variables. A job that declares environment: production runs under its rules.
Required reviewers = up to six people or teams; one of them must approve before the job may start. Optional: prevent self-review. Wait timer = a fixed delay in minutes (up to 30 days) before the job may proceed.
Deployment branches and tags = which refs may deploy there — "protected branches only" or a named list such as main.
Branch protection (or a ruleset) = rules on main: require a pull request, require status checks to pass, optionally require reviews. The check is named after the job — name: test (node ${{ matrix.node }}) gives test (node 22).
Audit trail = each environment deployment records the run, the approver, the time and any comment.

🧠 Two doors, two questions

door	where	the question	who answers
front door	pull request → `main`	did the checking desk stamp ✅?	the robot — a required status check
principal's office	staging → production	should this copy go on the main board?	a named human — a required reviewer

🤔 Why

A green test says the code behaves; it says nothing about the config, the cluster, or the image that was actually built. Staging catches that class of surprise cheaply. The approval buys a human a moment and buys the school a record: when the main board breaks, "who approved what, when" is a lookup, not an argument. Branch protection makes the rest hold — a gate on production is worth little if untested code can walk into main. The ArgoCD school's lesson 03 starts from this exact push pipeline before it replaces the van.

🔧 How (in this repo)

Two jobs, two environments. deploy.yml runs staging, then production; needs: orders them, environment: attaches the rules:

  staging:
    runs-on: ubuntu-latest
    environment: staging                          # the practice notice board

  production:
    needs: staging
    runs-on: ubuntu-latest
    environment: production                       # 🛑 required reviewers = the principal's signature

Nothing in the YAML says "wait for approval". As the file's header puts it, the production environment "must be created once in Settings → Environments with Required reviewers — THAT checkbox is the approval gate".

How the pause works. When the run reaches the production job, GitHub evaluates the environment's protection rules. With required reviewers set, the job shows Waiting and the run summary grows a Review deployments button. A listed reviewer approves or rejects, with an optional comment; approve → the job starts with that environment's secrets and variables, reject → the job fails. The decision is kept with the run (the summary shows who approved) and in the environment's deployment history — also readable with gh api repos/{owner}/{repo}/actions/runs/<id>/approvals.

Setting it up (once, in the fork). Settings → Environments → New environment → production → tick Required reviewers and add yourself → optionally a Wait timer → Deployment branches and tags → selected branches → main. Create staging too, with no reviewers. Public repositories get protection rules on the current plans; private ones may need a paid plan — check GitHub's docs.

The front door. Settings → Branches (classic) or Settings → Rules (rulesets) → protect main → Require status checks to pass before merging → add test (node 22). A pull request with a red check then shows Merging is blocked.

Where the van is called. In ship.yml the 🚚 deliver job (uses: ./.github/workflows/deploy.yml) only exists once vars.EKS_CLUSTER is set — on a fork without AWS it is skipped, by design.

🔁 The same thing in CircleCI

      - hold-for-approval:               # 🛑 the principal's signature: click Approve in the UI
          type: approval
          requires: [deploy-staging]

An approval job is a placeholder with no steps; the workflow stops there until someone with write access to the project clicks it, deploy-production lists it in requires:, and the workflow page shows who clicked.

🦊 The same thing in GitLab CI

deploy-production:
  <<: *deploy
  needs: [deploy-staging]
  environment: { name: production }
  when: manual                                # 🛑 the principal's signature: a human presses ▶ in the UI

when: manual draws the play button; environment: files the deployment under Operate → Environments with its history. Restricting who may press play is a protected environment, a paid-tier feature at the time of writing.

🎩 The same thing in Jenkins

    stage('🛑 approve') {
      options { timeout(time: 2, unit: 'DAYS') }
      steps { input message: 'Deploy to production?', ok: 'Approve' }   // the principal's signature
    }

input pauses the build and the approver's name lands in the build log. The two-day timeout aborts a forgotten build instead of holding it open indefinitely; input also takes a submitter: list naming who may click (# illustrative).

🧪 Try it

This works on a public fork without AWS. The deploy jobs themselves stay skipped until the lesson 06 variables and EKS_CLUSTER exist, so the Review deployments button appears only once staging has actually run.

# 1) the front door: make "test (node 22)" a required check on main, for admins too
gh api -X PUT "repos/{owner}/{repo}/branches/main/protection" --input - <<< '{ "required_status_checks":
  { "strict": true, "contexts": ["test (node 22)"] }, "enforce_admins": true, "required_pull_request_reviews": null, "restrictions": null }'

# 2) open a PR that breaks a test and watch the merge get blocked
git checkout -b break-a-test
sed -i.bak 's/writeHead(404/writeHead(500/' app/server.js && rm app/server.js.bak
git commit -am "break the 404 test on purpose" && git push -u origin break-a-test
gh pr create --fill && gh pr checks --watch     # test (node 22) ❌
gh pr merge --squash                            # refused: the base branch policy prohibits the merge
git checkout main && gh pr close break-a-test --delete-branch

# 3) the principal's office: create the production environment with yourself as reviewer
gh api -X PUT "repos/{owner}/{repo}/environments/production" --input - <<JSON
{ "wait_timer": 0, "reviewers": [ { "type": "User", "id": $(gh api user --jq .id) } ],
  "deployment_branch_policy": { "protected_branches": true, "custom_branch_policies": false } }
JSON
# then open Settings → Environments → production in the browser and read the three switches

⚠️ Common mistakes

protecting main but not enforcing it for administrators — the one person who can bypass the rule is usually the one in a hurry
writing environment: production and assuming that alone gates anything — with no protection rules configured, the job runs straight through
one reviewer, no wait timer, self-review allowed, on a team repository — a gate one tired person can open at 2 a.m. is a formality

⏭️ Next

The principal signed. Now, how does the new notice replace the old one without a blank board in between — and how do you put yesterday's back? 🔁

git checkout lesson-09-deploy-strategies

← Previousbuild push image Next →deploy strategies

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