भाग 1: आराखडा (जांभळा, 1–4) · भाग 2: नोंदवही आणि कंत्राटदार (teal, 5–8) · भाग 3: अनेक जागा, सुरक्षितपणे (amber, 9–12). प्रत्येक आकृती खऱ्या, deterministic lab मधून काढली आहे — iac/demo.py जे आकडे print करतो तेच — आणि प्रत्येक आकृतीखाली एक lab आहे जिथे तुम्ही स्वतः आराखडा बदलता. वर्तुळातील क्रमांकांचा क्रम पाळा: 1 → 2 → 3.
1 📜 infrastructure as code का
Clicks विरुद्ध लिखित आराखडे — आराखड्यांवरून बांधलेला campus पुन्हा बांधता, review करता आणि नव्याने उभारता का येतो.
🧒 सोप्या शब्दांत
शाळेला तीन गावांत एकसारखी science wing हवी आहे. कतरिना प्रत्येक wing हाताने बांधते आणि दर वेळी 8 गोष्टी type करते. तिसऱ्या site वर ती floor 2 ऐवजी 20 type करते. आता wings एकसारख्या नाहीत. म्हणून दीपिका एकदाच आराखडा लिहून ठेवते. Contractor आराखड्यावरून बांधतो, आणि तिन्ही wings जुळतात. तो पुन्हा आला की म्हणतो: काहीच करायचे नाही.
📖 नवे शब्दinfrastructure — तुमचे programs ज्यात राहतात त्या खोल्या, gates आणि lockers; खऱ्या आयुष्यात servers आणि networksinfrastructure as code — click करण्याऐवजी campus text files मध्ये लिहून ठेवणेdeclarative — काय असायला हवे ते तुम्ही सांगता, आणि पायऱ्या tool ठरवतेidempotent — काहीच वेगळे नसेल तर पुन्हा चालवल्यावर काहीच बदलत नाही
⏪ आधी
एक clerk प्रत्येक site web console मध्ये click करून बांधत असे: प्रत्येक site ला 8 fields हाताने, आणि का ते कुठेच लिहिलेले नाही.
💡 काय
Infrastructure as code: works office campus चा आराखडा git मध्ये लिहून ठेवते, आणि contractor त्यावरून बांधकाम करतो.
⚙️ कसे
हाताने बांधताना prod ला floor 2 ऐवजी 20 पडला, म्हणून 3 sites जुळत नाहीत. आराखड्यातून: प्रत्येकी 5 added, आणि त्या जुळतात.
🎯 का
आराखडा pull request मध्ये तपासता येतो, git मध्ये ठेवता येतो आणि पुन्हा वापरता येतो. dev वर दुसरे apply 'No changes.' म्हणते.
🚀 पुढे
पुढचा धडा आराखडा उघडतो: एका resource block मध्ये काय लिहिता येते, आणि provider व campus काय भरतात.
🧪 इथे करून पाहा — 3 जागा हाताने विरुद्ध आराखड्यांवरून बांधा — चुकीची शक्यता आणि दिवस बदला
Resources, providers आणि schemas — आराखड्यांत काय लिहिता येते आणि campus काय भरतो.
🧒 सोप्या शब्दांत
कतरिना आराखड्यात एक ओळ लिहिते: chem-lab नावाची खोली, floor 2 वर, 30 seats. Campus ओळखणारा एक मदतनीस ती वाचतो. त्याच्याकडे खोल्यांचे नियम-पुस्तक आहे. नियम सांगतो की खोलीला नाव हवेच. Campus खोली बांधतो आणि तिला एक नंबर देतो: room-01. कतरिना तो नंबर स्वतः कधीच ठरवत नाही.
📖 नवे शब्दresource — बांधायची एक गोष्ट, जसे एक खोली किंवा एक gateprovider — आराखड्याचे एका cloud साठी calls मध्ये रूपांतर करणारा मदतनीस pluginschema — नियम-पुस्तक: कोणत्या गोष्टी चालतात, लागतातच किंवा नंतर भरल्या जातातcomputed — campus भरतो ते मूल्य, जसे id room-01
⏪ आधी
प्रत्येक console form चे fields आणि नियम वेगळे होते; 'create' दाबण्याआधी खोलीची settings कोणी तपासू शकत नसे.
💡 काय
Resource म्हणजे बांधायची एक गोष्ट, जसे school_room.lab. Provider plugin ला त्याचे schema आणि campus API माहीत असते.
⚙️ कसे
Lab साठी chem-lab, floor 2, 30 seats मागितले. Provider POST /rooms करतो आणि campus id room-01 देतो.
🎯 का
Schema सांगते: name required आहे, floor चा default 1 आणि बदलला तर नवी खोली, आणि id computed आहे: आराखडा तो कधीच ठरवत नाही.
🚀 पुढे
पुढच्या धड्यात आराखडा बदलतो आणि diff वाचतो: कोणत्या ओळी जागीच update होतात आणि कोणत्या पुन्हा बांधल्या जातात.
🧪 इथे करून पाहा — एक school_room लिहा — provider चे schema ते तपासते, बाकीचे campus भरतो
Diff: create, जागीच update, replace, destroy — आणि नवीन object बनवायला भाग पाडणारे arguments.
🧒 सोप्या शब्दांत
ऐश्वर्या आराखडा बदलते. Lab ला 30 ऐवजी 40 seats. Art room floor 3 वर जाते. Gate जाते, आणि library येते. बांधण्याआधी contractor एक यादी दाखवतो. अधिक म्हणजे बांधा, नागमोडी खूण म्हणजे जागीच दुरुस्त करा, आणि वजा म्हणजे पाडा. खोली दुसऱ्या floor वर नेणे म्हणजे अगदी नवी खोली. ऐश्वर्या आधी यादी वाचते, मग हो म्हणते.
📖 नवे शब्दplan — contractor करणार असलेल्या बदलांची यादी, काहीही होण्याआधी दाखवलेलीapply — खऱ्या campus वर plan प्रत्यक्ष अमलात आणणेupdate in place — तीच खोली दुरुस्त करणे, जसे जास्त seats; id room-01 तसाच राहतोreplace — खोली पाडून नव्या id सह नवी खोली बांधणे
⏪ आधी
बदल थेट campus वर केले जात; एखादा बदल खोली पाडेल का हे आधी कोणालाच कळत नसे.
💡 काय
Plan आराखडा, नोंदवही आणि campus यांची तुलना करतो: + create, ~ update, -/+ replace आणि - destroy.
⚙️ कसे
Version 2: lab seats 30 → 40 (~), art floor 1 → 3 (-/+), library (+), gate नाही (-). Plan: 2 to add, 1 to change, 2 to destroy.
🎯 का
Replace म्हणजे update नव्हे: art room नवी वस्तू झाली, room-02 → room-03, पण lab ने आपला id room-01 ठेवला.
🚀 पुढे
पुढचा धडा inputs, outputs आणि loops आणतो: एकाच block मधून अनेक lockers, count किंवा for_each ने ओळखलेले.
🧪 इथे करून पाहा — आराखड्याची version 2 बदला — + ~ -/+ - ओळी पाहा
Variables, locals, outputs, count आणि for_each — आणि मधली item काढणे का महत्त्वाचे ठरते.
🧒 सोप्या शब्दांत
Office ला तीन lockers हवे आहेत: a, b आणि c. तीन blocks लिहिण्याऐवजी दीपिका एक block आणि एक loop लिहिते. count मध्ये lockers ना 0, 1 आणि 2 म्हणतात. b काढला तर c जागा 1 वर सरकतो, म्हणून c च्या locker चे label बदलते. for_each मध्ये lockers ना नावाने ओळखतात. b काढला तर फक्त b जातो. बाकी काहीच हलत नाही.
📖 नवे शब्दvariable — आराखड्यातील एक रिकामी जागा जी तुम्ही भरता, जसे env = devoutput — बांधल्यानंतर आराखडा सांगतो ते मूल्य, जसे locker idcount — N प्रती बनवा, जागेनुसार 0, 1, 2 असे नंबरfor_each — प्रत्येक नावासाठी एक प्रत, त्याच नावाने ओळखलेली
⏪ आधी
प्रत्येक locker साठी copy-paste केलेला block होता, आणि dev व prod चे आराखडे वेगळ्या files मध्ये हळूहळू वेगळे होत गेले.
💡 काय
Variables आराखड्यात मूल्ये देतात, locals नावे ठरवतात, outputs ids सांगतात, आणि count किंवा for_each अनेक प्रती बांधतात.
⚙️ कसे
Defaults मुळे lab_name dev-school-lab आणि 3 lockers. count ने b काढला: 1 to change, 1 to destroy. for_each ने: फक्त 1 to destroy.
🎯 का
count lockers ना जागेनुसार ओळखतो, म्हणून मधला काढला की बाकी सरकतात; for_each त्यांना नावाने ओळखतो.
🚀 पुढे
पुढचा धडा नोंदवहीच उघडतो: कोणता address कोणती खरी वस्तू आहे हे contractor कसे लक्षात ठेवतो.
🧪 इथे करून पाहा — एक locker काढा — count स्थानानुसार key करतो, for_each नावानुसार
जागेची नोंदवही: कोणता address कोणता खरा object आहे — आणि त्यात secrets का असतात.
🧒 सोप्या शब्दांत
Works office एक नोंदवही ठेवते. प्रत्येक ओळ सांगते की आराखड्यातील कोणते नाव कोणती खरी वस्तू आहे: lab म्हणजे room-01. Contractor प्रत्येक plan आधी ती वाचतो. नोंदवहीत locker codes पण असतात, जसे 6872, साध्या अक्षरात. Screen वर code लपवला तरी नोंदवहीत तो लपत नाही. एके दिवशी नोंदवही हरवते. Contractor सगळे पुन्हा बांधतो, आणि आता दोन chem-labs आहेत.
📖 नवे शब्दstate — आराखड्यातील प्रत्येक नाव एका खऱ्या वस्तूशी जोडणारी नोंदवहीserial — नोंदवही लिहिली की दर वेळी वाढणारा countersensitive — screen वर लपवलेले, पण नोंदवहीत तरीही लिहिलेलेduplicate — नोंदवही हरवल्यामुळे चुकून बांधलेली दुसरी प्रत
⏪ आधी
Contractor ला काहीच आठवत नसे: बांधकामानंतर 'आराखड्यातील lab' आणि campus वरील room-01 यांचा संबंध कुठेच नव्हता.
💡 काय
State म्हणजे site ची नोंदवही: version 4, serial 1, lineage campus-3f9a, 5 addresses आणि 5 खऱ्या वस्तूंची जोडणी.
⚙️ कसे
sensitive = true मुळे code_a <sensitive> दिसते, तरीही state मध्ये 6872, 4434 आणि 4123 साध्या अक्षरात असतात.
🎯 का
नोंदवही हरवली की plan 5 to add म्हणतो; apply नंतर chem-lab नावाच्या 2 खोल्या आणि 10 वस्तू, म्हणजे duplicates.
🚀 पुढे
पुढचा धडा विचारतो कोणत्या क्रमाने बांधायचे: gates आधी खोल्या, आणि एका वेळी किती.
🧪 इथे करून पाहा — apply करा, मग नोंदवही हरवा आणि पुन्हा apply करा
फाटकांआधी खोल्या: implicit आणि explicit क्रम, parallel पायऱ्या, cycles.
🧒 सोप्या शब्दांत
खोली नसताना तिचे gate लावता येत नाही. Contractor बाण काढतो: आधी खोली, मग gate. ज्यांच्यामध्ये बाण नाही त्या गोष्टी एकाच वेळी बांधता येतात. 10 जणांच्या crew ला आठ गोष्टींसाठी 3 steps लागतात. 1 जणाला 8 steps. पाडताना उलट: आधी lockers, शेवटी खोल्या. दोन गोष्टी एकमेकींची वाट पाहत असतील तर कोणीच सुरू करू शकत नाही.
📖 नवे शब्दdependency — आधी असायलाच हवी अशी गोष्ट, जसे gate आधी खोलीdepends_on — आराखड्यात दिसत नसेल तेव्हा हाताने जोडलेला बाणparallelism — crew एकाच वेळी किती गोष्टी बांधतेcycle — दोन गोष्टी एकमेकींची वाट पाहतात, म्हणून काहीच सुरू होत नाही
⏪ आधी
बांधकाम करणारे file मधल्या क्रमाने checklist पाळत आणि gate त्याच्या खोलीच्या आधी येणार नाही अशी आशा करत.
💡 काय
room_id = school_room.lab.id सारखा reference graph मधील एक edge आहे; depends_on हाताने edge जोडतो.
⚙️ कसे
8 resources: parallelism 10 मध्ये 3 steps [2, 5, 1], parallelism 2 मध्ये 4 steps, parallelism 1 मध्ये 8 steps.
🎯 का
Destroy graph उलटा चालतो, आधी lockers, शेवटी lab; locker ला gate आणि gate ला locker हवा असेल तर Cycle error येतो.
🚀 पुढे
पुढचा धडा hall, gate आणि lockers एका wing च्या आराखड्यात बांधतो आणि तो दोनदा वापरतो.
🧪 इथे करून पाहा — कामगारांची संख्या, lockers आणि depends_on बदला — पायऱ्या मोजा
एका wing चे design, दोनदा बांधलेले: inputs आणि outputs असलेले modules.
🧒 सोप्या शब्दांत
शाळेला east wing आणि west wing हवी आहे. प्रत्येक wing मध्ये एक hall, एक gate आणि काही lockers आहेत. दीपिका एकच wing आराखडा काढते आणि तो दोनदा वापरते. East ला 2 lockers आणि west ला 3. एकूण 9 गोष्टी. West ने चौथा locker मागितला की फक्त west मध्ये एक locker वाढतो. East wing ला अजिबात धक्का लागत नाही.
📖 नवे शब्दmodule — पुन्हा वापरता येणारा आराखडा, जसे wing चे एक चित्रinput — module ला दिलेले मूल्य, जसे किती lockersmodule output — module परत देते ते मूल्य, जसे gate idaddress — एखाद्या गोष्टीचे पूर्ण नाव, जसे module.west.school_locker.row[3]
⏪ आधी
प्रत्येक नवीन wing मागच्या wing चे blocks हाताने copy करत असे, आणि एका copy मधली दुरुस्ती इतरांपर्यंत पोहोचत नसे.
💡 काय
Module म्हणजे inputs (wing, lockers) आणि outputs (gate_id, hall_id) असलेला एक wing आराखडा, हवा तितक्या वेळा वापरता येतो.
⚙️ कसे
East ला 2 lockers आणि west ला 3: Plan: 9 to add. Outputs east_gate = gate-01 आणि west_hall = room-02.
🎯 का
West ने 4 lockers मागितले तर फक्त module.west.school_locker.row[3] वाढतो: 1 to add, east ला धक्का लागत नाही.
🚀 पुढे
पुढचा धडा नोंदवही एका सामायिक जागी नेतो, कारण दोन लोकांकडे दोन प्रती असल्या की गोंधळ होतो.
🧪 इथे करून पाहा — wing module वेगवेगळ्या inputs सह बोलवा
एकाच सामायिक जागी एक नोंदवही, एका वेळी एकच लिहिणारा.
🧒 सोप्या शब्दांत
सोमवारी कतरिना आणि दीपिका दोघी नोंदवहीची प्रत घेतात. त्यात लिहिले आहे: एक lab. कतरिना gym बांधते. दीपिका library बांधते. कतरिना आपली प्रत परत लिहिते, मग दीपिका आपली प्रत त्यावर लिहिते. आता नोंदवही gym विसरते. Gym उभे आहे पण त्याची काळजी कोणी घेत नाही. म्हणून office कुलूप आणते: कतरिनाकडे कुलूप असताना दीपिकाने थांबायचे.
📖 नवे शब्दremote state — एकाच सामायिक जागी ठेवलेली एक नोंदवही, laptop वर नाहीbackend — नोंदवही साठवणारी सामायिक जागा, जसे bucketstate lock — नोंदवही बदलताना एका वेळी फक्त एकीकडे राहणारी किल्लीorphan — बांधलेली आणि पैसे भरलेली, पण नोंदवहीला माहीत नसलेली गोष्ट
⏪ आधी
नोंदवही एका laptop वर किंवा git मध्ये होती, आणि दोन लोक एकाच वेळी plan करून ती लिहू शकत.
💡 काय
Remote state एकच नोंदवही सामायिक backend मध्ये ठेवते, आणि कुलूप असल्याने एका वेळी एकच लिहिणारी काम करते.
⚙️ कसे
कुलूप नाही: कतरिना आणि दीपिका दोघी serial 1 वाचतात आणि serial 2 लिहितात; दीपिका शेवटी लिहिते, म्हणून gym orphan होते.
🎯 का
कुलूप असताना दीपिकाला 'Error acquiring the state lock' येतो, ती कतरिनाचा बदल घेते, आणि serial 3: 3 खोल्या = नोंदवहीत 3.
🚀 पुढे
पुढचा धडा कोणीही न लिहिलेले बदल शोधतो: console click, हाताने बांधलेले gate आणि नाव बदललेली खोली.
🧪 इथे करून पाहा — कतरिना व्यायामशाळा जोडते, दीपिका ग्रंथालय, एकाच वेळी
कोणीतरी console मध्ये click केले: refresh, drift, ignore_changes, import आणि moved blocks.
🧒 सोप्या शब्दांत
दीपिका console मध्ये click करून lab ला 45 seats देते. आराखड्यात अजून 30 आहेत. Contractor हे ओळखतो आणि ते परत 30 करायला सांगतो. मग ऐश्वर्याला कोणीतरी हाताने बांधलेले back gate सापडते. ती import ओळ जोडते, म्हणजे दुसरे gate न बांधता आराखडा तेच gate स्वीकारतो. खोलीचे नाव बदलले तर moved ओळ सांगते की ती तीच खोली आहे.
📖 नवे शब्दdrift — खरा campus बदलला, पण आराखडा आणि नोंदवही नाहीrefresh — काय बदलले ते पाहण्यासाठी खरा campus वाचणेimport — हाताने बांधलेली गोष्ट नोंदवहीत स्वीकारणेmoved — जुने नाव आणि नवे नाव एकच गोष्ट आहे असे सांगणारी नोंद
⏪ आधी
कोणीतरी console मध्ये खोली बदलली आणि पुढच्या बांधकामाने ती गुपचूप परत बदलेपर्यंत कोणाला कळले नाही.
💡 काय
Drift म्हणजे campus नोंदवहीपेक्षा वेगळा असणे; import हाताने बांधलेली वस्तू स्वीकारतो, moved address चे नाव बदलतो.
⚙️ कसे
दीपिका room-01 चे seats 30 → 45 करते; plan ~ seats 45 → 30 दाखवतो, आणि ignore_changes = [seats] ने No changes.
🎯 का
Import शिवाय gate-02 च्या शेजारी दुसरे gate बनते; moved शिवाय नाव बदलल्याने 0 ऐवजी 3 to add आणि 3 to destroy.
🚀 पुढे
पुढचा धडा तेच आराखडे dev आणि prod साठी चालवतो, आणि चुकीची site किती सहज बदलते ते दाखवतो.
🧪 इथे करून पाहा — कोणीतरी console मध्ये click केले — refresh, ignore, import, move
त्याच आराखड्यांवरून dev आणि prod: workspaces विरुद्ध directories विरुद्ध वेगळे accounts.
🧒 सोप्या शब्दांत
शाळा एक लहान सरावाचा campus आणि खरा campus चालवते. दोघांसाठी एकच आराखडा. प्रत्येकाची स्वतःची नोंदवही आणि स्वतःची settings file. Dev मध्ये 10 seats आणि 1 locker. Prod मध्ये 40 seats आणि 3 lockers. एके दिवशी कतरिनाने prod उघडलेले असते पण ती dev file वापरते. Plan prod लहान करू पाहतो. सुदैवाने ती plan वाचते आणि नाही म्हणते.
📖 नवे शब्दenvironment — campus ची एक प्रत, जसे सरावासाठी dev किंवा खऱ्यासाठी prodworkspace — त्याच आराखड्यासाठी वेगळी नोंदवही, प्रत्येक environment ला एक.tfvars file — एका environment ची मूल्ये असलेली settings fileseparate accounts — dev आणि prod वेगवेगळ्या accounts मध्ये, सर्वात मजबूत भिंत
⏪ आधी
एकच environment होते, म्हणून प्रत्येक बदल थेट production मध्ये तपासला जाई, किंवा dev ही हाताने केलेली प्रत होती.
💡 काय
एकच आराखडा, प्रत्येक environment साठी एक workspace, आणि प्रत्येकी एक .tfvars file: dev.tfvars आणि prod.tfvars.
⚙️ कसे
Dev (10 seats, 1 locker) मध्ये 2 added, prod (40 seats, 3 lockers) मध्ये 4: नोंदवह्या env:/dev आणि env:/prod, 6 वस्तू.
🎯 का
prod निवडलेले असताना कतरिना dev.tfvars ने plan करते: seats 40 → 10 आणि 2 lockers destroy. Prod dev एवढे लहान होते.
🚀 पुढे
पुढच्या धड्यात बांधकामाआधी तपासनीस येतात: validate, tests, policy आणि cost सगळे plan वाचतात.
🧪 इथे करून पाहा — निवडलेले workspace आणि .tfvars फाइल निवडा
Validate, tests, policy आणि cost — काहीही बांधण्याआधी plan वाचणारे निरीक्षक.
🧒 सोप्या शब्दांत
काहीही बांधण्याआधी चार तपासनीस आराखडा वाचतात. पहिली लिखाण तपासते आणि तिला 4 चुका सापडतात. दुसरी छोट्या tests चालवते: 2 pass, 1 fail. तिसरी शाळेचे नियम तपासते आणि रात्रभर उघडे राहणारे gate थांबवते. चौथी खर्च मोजते: महिन्याला 2830 रुपये. हे सगळे कागदावरच होते.
📖 नवे शब्दvalidate — campus शिवाय, आराखडा बरोबर लिहिला आहे का ते तपासणेtest — plan ला हवा तोच अर्थ आहे का याची छोटी तपासणीpolicy — एखाद्या बदलाला DENY म्हणू शकणारा शाळेचा नियमcost estimate — बांधण्याआधी, plan ला दर महिन्याला किती खर्च येईल
⏪ आधी
चुका बांधकामानंतर सापडत: उघडे gate, owner नसलेली खोली, महिन्याच्या शेवटी मोठे बिल.
💡 काय
चार तपासनीस आधी आराखडा वाचतात: validate आकार, tests अर्थ, policy काय परवानगी आहे, आणि cost किंमत तपासते.
⚙️ कसे
Validate ला 4 errors सापडतात; policy 3 बदल नाकारते; cost ₹0 → ₹2830/month; tests: 2 passed, 1 failed.
🎯 का
00-24 उघडे राहणारे night gate कागदावरच थांबते, कोणतेही gate बांधण्याआधी किंवा एकही रुपया खर्च होण्याआधी.
🚀 पुढे
पुढचा धडा सगळे एका conveyor belt वर ठेवतो: pull request वर plan, merge वर apply, keys ऐवजी OIDC.
🧪 इथे करून पाहा — आराखडा बदला — validate, policy, cost आणि tests पुन्हा चालतात
Pull request वर plan, merge वर apply, keys ऐवजी OIDC — आणि संपूर्ण चित्र.
🧒 सोप्या शब्दांत
आता एक conveyor belt काम करतो. दीपिका बदलाची विनंती उघडते, आणि belt ती तपासून plan दाखवतो. ऐश्वर्या तो तपासते. Merge झाला की belt बांधकाम करतो. Belt कडे साठवलेली किल्ली नसते: तो एक तास टिकणारा pass दाखवतो. दोन बदल शर्यत लावतात तेव्हा belt जुना plan नाकारतो आणि नवी तपासणी मागतो.
📖 नवे शब्दpull request — आराखडा बदलण्याची विनंती जी आधी इतर जण तपासतातCI/CD — तुमच्यासाठी बदल तपासणारा, plan करणारा आणि apply करणारा conveyor beltOIDC token — साठवलेल्या किल्लीऐवजी job दाखवतो तो थोडा वेळ टिकणारा passstale plan — दुसऱ्या कोणी नोंदवही बदलण्याआधी बनवलेला plan
⏪ आधी
कोणी laptop वरून apply चालवत असे, आणि सगळ्या jobs मध्ये वाटलेली long-lived cloud key CI secret मध्ये ठेवलेली असे.
💡 काय
CI प्रत्येक pull request वर plan आणि merge वर apply चालवते, साठवलेल्या keys ऐवजी short-lived OIDC tokens वापरून.
⚙️ कसे
pull_request token ला campus-plan (3600 s) मिळते पण campus-apply ला AccessDenied; फक्त main apply करू शकते.
🎯 का
#43 apply झाल्यावर #42 चा saved plan stale झाला: re-plan ला 1 to destroy हवे होते, म्हणून थांबला; rebase नंतर serial 3.
🚀 पुढे
पुढे: AWS school हा campus आहे जो हे आराखडे सहसा बांधतात, आणि CI/CD school pipeline चालवते.
🧪 इथे करून पाहा — कोण plan किंवा apply करू शकते — आणि कोणता merge जिंकतो