Claude Code को production deploy सौंपने से पहले का dry run चेक

शुक्रवार की शाम थी। मैंने Claude Code से कहा, “इस article का fix production पर डाल दो।” जवाब में बस एक लाइन आई, “publish हो गया,” और एक हरा tick। मैं निश्चिंत होकर घर चला गया। अगली सुबह site का homepage पूरी तरह सफेद था।

वजह बहुत बेवकूफाना थी। preview किसी ने खोली ही नहीं थी। Claude Code ने सिर्फ़ build pass होने वाला log देखकर “success” मान लिया था। लेकिन असली page किसी दूसरे article का template load कर रहा था और अंदर कुछ था ही नहीं। HTTP तो 200 लौटा रहा था, इसलिए मशीन की नज़र में यह “publish सफल” दिख रहा था।

उस दिन मुझे एक बात गहराई से समझ आई: तेज़ी और सुरक्षा दो अलग चीज़ें हैं। पूरा deploy सौंप दो तो काम एक पल में निपटा हुआ दिखता है। पर अगर यह कहीं दर्ज न हो कि क्या-क्या जांचा गया, तो गिरने के बाद पता ही नहीं चलता कि किसे वापस लाना है। आज मैं इसी का इलाज लिख रहा हूं: production access देने से पहले “dry run” (खाली अभ्यास) से सबूत जुटाने का तरीका।

मुख्य बातें

• Claude Code को deploy सौंपने पर होने वाले ज़्यादातर हादसे इसलिए होते हैं कि production को छूने से पहले की जांच छोड़ दी जाती है।
• production access देने से पहले पांच चीज़ें dry run में जांचें: build, diff, preview URL, rollback owner और जो हिस्से छुए नहीं गए।
• “मशीन जो खुद जांच सकती है” और “इंसान जिसे आंख से देखकर तय करता है” — इन दोनों को अलग कर दें तो रात के हादसे घटते हैं।
• copy-paste के लिए prompt का ढांचा और जांच के नतीजे को मशीन से परखने वाला code नीचे दिया है।
• शुरुआत से एकदम परफेक्ट नियमावली की ज़रूरत नहीं। एक fix पर आज़माएं, और जहां गिरें उसे checklist में जोड़ते जाएं।

Deploy हादसा “होशियारी” की नहीं, जांच की कमी की देन है

Claude Code होशियार है। पर होशियार होना और production में सुरक्षित चलना — ये दो अलग बातें हैं।

जो छात्र परीक्षा में पूरे अंक लाता है, वह भी अपनी पहली नौकरी में cash register तोड़ सकता है। यह काबिलियत की समस्या नहीं, “ज़मीन” यानी ढांचे की समस्या है। deploy की भाषा में ढांचा यानी “production को छूने से पहले क्या-क्या जांचना है।”

खासकर static site के deploy में, failure चुपचाप आगे बढ़ता है। build pass हो जाए और HTTP 200 लौटे, तो ऊपर से सब ठीक दिखता है। अंदर खाली हो या page बदलकर कोई और आ गया हो, अगर आप सिर्फ़ status code देख रहे हैं तो पता ही नहीं चलेगा। इसलिए “code चला या नहीं” नहीं, बल्कि “सही page सही ढंग से दिख रहा है या नहीं” — इसे इंसान की आंख से एक बार देखना ज़रूरी है।

Production छूने से पहले के पांच dry run कदम

मैं अभी जो तरीका इस्तेमाल करता हूं, बस इतना ही है। क्रम मायने रखता है, इसलिए ऊपर से नीचे क्रम में रखा है।

1. पहले local पर build pass कराएं। अगर यहीं गिरता है तो production की बात ही दूर। code की समस्या है या environment की — यह production छूने से पहले ही अलग कर लें।
2. diff पढ़ें। कहीं गोपनीय जानकारी (API key, token) या पैसों से जुड़ा बदलाव तो नहीं घुस गया — यह आंख से जांचें।
3. preview URL खोलें। heading (h1), canonical URL और signup button का गंतव्य असल screen पर देखकर पक्का करें कि सब अपेक्षा के मुताबिक है।
4. rollback owner और वापस लाने का तरीका तय करें। failure होने पर कौन, किस command से पिछली हालत में लौटाएगा। यह पहले से तय न हो तो हादसे के पल में हाथ-पांव फूल जाते हैं।
5. सबूत जुट जाने के बाद ही production access मांगें। 1 से 4 के नतीजे आने पर ही Claude Code से production deploy कहें।

बस इस क्रम का पालन करने से शुरुआत वाला “homepage सफेद” हादसा लगभग नहीं होता। क्योंकि कदम 3 में preview ज़रूर खुलती है।

AI को क्या सौंपें और इंसान क्या तय करे

न तो सब कुछ AI को सौंपना है, न सब कुछ हाथ से करना है। काम बांट लीजिए। नीचे की table मेरे असल काम में खींची गई लकीर है।

स्थिति	Claude Code को सौंपने वाला काम	इंसान जो सबूत देखे
Article publish	dist build और public URL का auto-check पहले चलवाएं	build नतीजा, diff, URL
Signup button बदलना	link का गंतव्य और consultation रास्ता preview पर मिलाएं	build नतीजा, diff, URL
Workers का fix	environment variables छुए बिना सिर्फ़ dry run log निकलवाएं	build नतीजा, diff, URL

मूल बात यह है: पढ़ना, क्रम में लगाना और मशीनी जांच — ये AI को सौंपें; और production में जो बदलाव वापस नहीं हो सकता, वैसा operation इंसान मंज़ूर करे। delete, production database में लिखना, billing, force push — इन सबको शुरू में “इंसान से पूछो” पर रख दीजिए। जो operation सुरक्षित साबित हो जाए, सिर्फ़ उसे बाद में auto में ऊपर चढ़ाइए।

permission की लकीर को और बारीकी से तय करना हो तो Claude Code का permission setup गाइड और deploy से पहले permission audit काम आएंगे।

Copy-paste के लिए prompt का ढांचा

request को पूरी तरह फेंक मत दीजिए; साफ़ लिखिए कि “अभी production पर मत डालो।” नीचे का ढांचा जस का तस चिपकाकर इस्तेमाल कर सकते हैं।

इस बदलाव को production पर deploy करने से पहले की "dry run checklist" में बदल दें।
नीचे के बिंदु एक table में लौटाएं।
- build नतीजा (success / failure और log का सार)
- diff का risk (गोपनीय जानकारी, billing या delete शामिल है या नहीं)
- preview URL
- rollback owner और rollback command
- जो हिस्से छुए नहीं गए
- दोबारा कोशिश की शर्त
production deploy अभी मत चलाएं। जब तक मैं जांच की पुष्टि न कर दूं, रुके रहें।

आखिरी दो लाइनें असर करती हैं। “अभी मत चलाओ” और “मेरी पुष्टि तक रुको” लिख देने से Claude Code का “अति-उत्साह में खुद publish कर देना” वाला हादसा रुक जाता है। prompt को सुरक्षित पहलू पर झुकाने का तरीका advanced prompt design में भी समेटा है।

Copy-paste से चलने वाली verification script

जांच के नतीजे को “इंसानी अंदाज़े” के बजाय मशीन से परखें तो चूक घटती है। नीचे की script dry run का result object लेती है और लौटाती है कि production access मांगने लायक हालत है या नहीं — सच/झूठ के रूप में। Node.js हो तो यह जस की तस चलती है।

// dry run का नतीजा। असली जांच की जानकारी यहां भरें
const deployCheck = {
  build: "passed",              // local build pass हुआ या नहीं
  diffReviewed: true,           // diff आंख से देखा या नहीं
  previewUrl: "https://example.pages.dev", // preview URL
  rollbackOwner: "Masa",        // rollback owner
  changedAreas: ["content", "cta-copy"],   // जो हिस्से छुए गए
};

// production access मांगने लायक हालत है या नहीं, यह तय करने वाला द्वारपाल
function canRequestProductionAccess(check) {
  return (
    check.build === "passed" &&          // build pass है
    check.diffReviewed &&                // diff देखा गया
    /^https:\/\//.test(check.previewUrl) && // preview URL https से मौजूद है
    check.rollbackOwner.length > 0 &&    // rollback owner तय है
    !check.changedAreas.includes("secrets") // गोपनीय हिस्सा नहीं छुआ
  );
}

const ready = canRequestProductionAccess(deployCheck);
console.log({ ready });
// जिस item पर ready false हो, उसे भरने तक production deploy मत मांगें

इस code की असली कीमत यहां है कि changedAreas में "secrets" आते ही यह false लौटा देती है। गोपनीय जानकारी गलती से छू गई हो, तो production access की request तक बात पहुंचेगी ही नहीं। इंसान व्यस्तता में चूक भी जाए, तो द्वारपाल रोक देता है।

जहां यह असल में काम आया, ऐसे 3 मौके

पहला — article publish। सिर्फ़ “blog डाल दो” कहो तो build pass होते ही publish तक दौड़ पड़ता है। बीच में dry run डालने पर public URL खोलकर heading और content का मेल पहले देखा जाता है, इसलिए शुरुआत वाला सफेद-screen हादसा रुक जाता है।

दूसरा — signup button बदलना। link में एक अक्षर गलत टाइप होते ही पूरा रास्ता 404 में गिर जाता है। preview पर button सच में दबाकर गंतव्य जांचने का कदम जोड़ने के बाद से, टूटे link शून्य हो गए।

तीसरा — Cloudflare Workers का fix। यहां एक environment variable मिटा दो तो production गिर जाता है। इसलिए dry run में environment variable छूने ही नहीं देता, सिर्फ़ log निकलवाता हूं। Workers की खास सावधानियां Cloudflare Workers इंटीग्रेशन के article में भी समेटी हैं।

आम गड्ढे और उन्हें भरने का तरीका

जो गलतियां मैंने सच में कीं और जो इलाज निकाला, वे तीन।

गड्ढा 1: build से पहले production command चला देना। सीधे wrangler deploy दौड़ा दो तो failure होने पर code गलत है या environment, यह अलग नहीं कर पाते। इलाज सीधा है — local build हमेशा पहले pass कराइए। बस एक कदम का क्रम बदलने से वजह ढूंढना कहीं तेज़ हो जाता है।

गड्ढा 2: rollback owner तय न करना। failure के बाद “कौन वापस लाएगा?” पर सलाह शुरू करो, तो उन्हीं चंद मिनटों में traffic सीधा चोट करता है। इलाज — dry run के चरण में ही rollback owner और rollback command लिखकर रख लीजिए। बस previousDeployId नोट कर लेना भी recovery को शांत कर देता है।

गड्ढा 3: preview खोले बिना सिर्फ़ status code पर भरोसा। HTTP 200 का मतलब बस इतना है कि “server ने कुछ लौटाया”, न कि “सही page आया।” इलाज — preview URL ब्राउज़र में एक बार ज़रूर खोलकर heading, canonical URL और hero image आंख से देखिए। शुरुआत वाले सफेद-screen को पकड़ने का यही एकमात्र तरीका था।

सबूत को “अगली बार भी काम आने वाली नोट” के रूप में रखें

dry run में जो जांचा, उसे उसी वक्त मिटाने के बजाय एक छोटी नोट में समेट लें, तो अगला काम काफ़ी तेज़ हो जाता है।

रखने को इतना ही काफ़ी है: पहली request का text, Claude Code ने कौन-सा हिस्सा पढ़ा, क्या नहीं छुआ, कौन-से जांच command चलाए, public URL या screenshot, और कहां फैसला उलझा। लंबी मीटिंग-नोट की ज़रूरत नहीं। बाद में “यह फैसला क्यों लिया” का पीछा किया जा सके — बस इतना मकसद पूरा हो जाए।

खास असर करता है “फैसले का दोराहा” एक लाइन में लिख देना। जैसे, “preview URL तो सही है पर rollback owner तय नहीं, इसलिए production अभी नहीं” लिख रखिए। अगली बार वही काम करते वक्त आप या कोई और, वही जांच दोबारा कर सकता है। deploy के अलावा बाकी automation में भी यही सोच काम आती है, इसलिए non-engineers के लिए Claude Code परिचय के साथ पढ़ें तो “सौंपने” का अंदाज़ा बन जाएगा।

अक्सर पूछे जाने वाले सवाल

Q. dry run तो आख़िर में बस मेहनत बढ़ाता है न? शुरू में ऐसा ही लगता है। पर एक बार हादसा हो जाए, तो recovery और वजह ढूंढने में कई घंटे पिघल जाते हैं। dry run चंद मिनट का है। मैं इसे फायदे वाला बीमा मानकर चलाता रहता हूं।

Q. local build pass हो जाए तो preview देखने की ज़रूरत नहीं? है। build pass होने पर भी template बदल जाना या page खाली रह जाना होता है। HTTP 200 और “सही page” दो अलग चीज़ें हैं, इसलिए आंख से देखना टाला नहीं जा सकता।

Q. rollback owner अकेले काम करता हूं तब भी तय करने का मतलब है? है। अकेले भी “गिरा तो इस command से वापस लाऊंगा” पहले से लिख रखो, तो हादसे के वक्त झिझक नहीं होती। तय करना अपने आप में एक तरीका बन जाता है।

Q. Claude Code “publish हो गया” कहे तो मान लूं? जवाब से ज़्यादा dry run के सबूत देखिए। build, diff, preview और rollback owner — सब जुटे हैं या नहीं, इस पर फैसला कीजिए। शब्द माहौल हैं, सबूत हकीकत।

Q. छोटी site पर भी इतना करना ज़रूरी है? आकार से नहीं, “वापस ला सकते हैं या नहीं” से सोचिए। छोटी ही सही, production गिरे तो दिक्कत होती है। पहले बस “preview खोलने” वाला एक कदम डालकर देखिए, असर महसूस होगा।

मैंने इसे सच में आज़माकर जो देखा

शुरुआत वाले सफेद-screen हादसे के बाद मैंने यह dry run तरीका अपने blog के संचालन में जोड़ लिया।

तीन चीज़ें परखीं। पहली — “preview URL ज़रूर खोलने” का नियम बना दिया, तो template बदलने से बनने वाले खाली page शून्य हो गए। दूसरी — ऊपर वाली verification script publish से पहले चलाने लगा, तो गोपनीय हिस्सा छूने वाला बदलाव ready: false पर रुक गया और production access की request तक नहीं पहुंचा। तीसरी — rollback owner और rollback command हर बार नोट करने लगा, तो जहां डर लगा, वहां भी चंद मिनट में पिछली हालत में लौट सका।

होशियार AI को सब सौंपकर प्रार्थना करने से बेहतर है कि गिरने पर भी चोट न लगे, ऐसी ज़मीन पहले बना लें। लंबा रास्ता लगता है, पर आख़िर में यही सबसे तेज़ निकलता है — मेरा अभी यही तजुर्बा है। पहले बस “preview खोलने” वाले एक कदम से, अपने deploy में एक द्वारपाल जोड़कर देखिए।

team में production deploy की लकीर और review व्यवस्था तक खड़ी करनी हो, तो training / consultation में साथ बैठकर इसे तरीके में ढाल सकते हैं। आधिकारिक संचालन मानक के लिए Anthropic की आधिकारिक Claude Code docs भी देखें।