dry-run विकल्प के फायदों के बारे में

 (henrikwarne.com)
1 पॉइंट द्वारा GN⁺ 2026-02-02 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • रिपोर्ट जनरेशन एप्लिकेशन विकसित करते समय –dry-run विकल्प जोड़ा गया, ताकि चलाने के परिणाम का सिमुलेशन किया जा सके
  • यह विकल्प बिना वास्तविक बदलाव किए यह दिखाता है कि कौन-सा काम किया जाएगा, जिससे सुरक्षित टेस्टिंग और तेज़ फीडबैक संभव होता है
  • डेवलपर इसके जरिए configuration, accessibility और system state को तुरंत जांच सकते हैं और इसे रोज़मर्रा के validation tool की तरह इस्तेमाल कर सकते हैं
  • कोड में dryRun फ़्लैग को जांचना पड़ता है, जिससे थोड़ी अतिरिक्त जटिलता बढ़ना एक कमी के रूप में बताया गया है
  • command-line एप्लिकेशन में –dry-run फीचर बहुत उपयोगी है, और इसे प्रोजेक्ट की शुरुआत में जोड़ने से development efficiency बढ़ती है

पृष्ठभूमि

  • नया विकसित किया जा रहा रिपोर्ट जनरेशन एप्लिकेशन हर कार्यदिवस रिपोर्ट बनाता है, उसे compress करके sftp server पर upload करता है, error response की जांच करता है और notification mail भेजता है
    • हर चरण में बने फ़ाइल और feedback फ़ाइल को चरण के अनुसार अलग-अलग directory में ले जाया जाता है
  • विकास के शुरुआती चरण में Subversion और कई Linux commands के –dry-run विकल्प को याद कर वही फीचर जोड़ा गया
    • यह विकल्प बिना वास्तविक बदलाव के चलाने पर क्या होगा, यह प्रिंट करता है
  • –dry-run चलाने पर, बनने वाली और छोड़ी जाने वाली रिपोर्टें, compress और move की जाने वाली फ़ाइलें, और sftp upload तथा download के लिए लक्षित फ़ाइलें चरण-दर-चरण प्रिंट होती हैं

उपयोग और फायदे

  • यह इतना उपयोगी फीचर है कि development और testing के दौरान रोज़ इस्तेमाल किया जाता है
  • रन से पहले state check करने के लिए इसका उपयोग करने पर configuration, accessibility और system state को तुरंत जांचा जा सकता है
    • क्योंकि कोई वास्तविक बदलाव नहीं होता, इसलिए इसे सुरक्षित रूप से चलाया जा सकता है
  • रिपोर्ट status फ़ाइल की तारीख बदलने के बाद, उस रिपोर्ट के बनेगी या नहीं, यह तुरंत जांचा जा सकता है
    • वास्तविक रिपोर्ट जनरेशन में समय लगता है, लेकिन dry-run तेज़ फीडबैक देता है
  • पूरे system के test के दौरान भी यह तेज़ validation loop देता है

कमियां

  • कोड में dryRun फ़्लैग को बार-बार जांचना पड़ता है, इसलिए कोड में थोड़ा-बहुत प्रदूषण होता है
    • हर मुख्य चरण पर फ़्लैग जांचकर वास्तविक execution की जगह सिर्फ log प्रिंट किया जाता है
  • हालांकि यह जांच बहुत गहरी नहीं जाती, और रिपोर्ट जनरेशन लॉजिक के अंदर अलग से हैंडलिंग की ज़रूरत नहीं होती
    • सिर्फ उन ऊपरी चरणों में जांच होती है जो execution होगा या नहीं, यह तय करते हैं

निष्कर्ष

  • command-driven तरीके से चलने वाले और परिणाम पैदा करने वाले एप्लिकेशन –dry-run विकल्प के साथ अच्छी तरह मेल खाते हैं
    • इसके विपरीत, संदेशों का इंतज़ार करने वाले reactive एप्लिकेशन के लिए यह उपयुक्त नहीं है
  • इसे प्रोजेक्ट की शुरुआत में जोड़ना development efficiency बढ़ाने में बहुत मददगार रहा
  • यह हर स्थिति में ज़रूरी फीचर नहीं है, लेकिन उपयुक्त मामलों में बहुत उपयोगी टूल माना गया है

संबंधित पढ़ाई

1 टिप्पणियां

 
GN⁺ 2026-02-02
Hacker News टिप्पणियाँ

  • stateful systems के साथ interact करते समय --dry-run में भी race condition हो सकती है
    टूल मौजूदा state के आधार पर दिखाता है कि वह “क्या करेगा”, लेकिन असली execution के समय तक स्थिति बदल सकती है
    इसलिए मैं Terraform के “plan” mode वाला तरीका पसंद करता हूँ। यह mode executable plan बनाकर रखता है, और अगर plan बनाते समय की assumptions बदल जाएँ तो abort या rollback कर सकता है
    साथ ही code में जगह-जगह if dry_run: डालने की ज़रूरत नहीं पड़ती, और plan तथा execution को अलग करके execute(plan()) जैसे रूप में सरल बनाया जा सकता है

    • पहले हुई AWS DNS outage की एक घटना भी इसी तरह की race condition की वजह से हुई थी
      DNS Planner और Enactor के बीच timing issue के कारण पुराना plan नए plan को overwrite कर गया था
      इससे जुड़ी चर्चा पिछले HN thread में भी हुई थी
    • ऐसा करने पर आखिरकार आप compiler (specification→plan) और virtual machine (plan→execution) जैसा कुछ implement कर रहे होते हैं
    • यह Terraform या Ansible जैसे infrastructure tools के लिए आदर्श है, लेकिन साधारण reporting tools में अनावश्यक complexity ला सकता है
      क्योंकि plan mode बनाने के लिए domain-specific language या data structures की ज़रूरत पड़ती है
    • मैं भी sensitive files को modify करने वाली scripts बना रहा हूँ, और इसी approach का इस्तेमाल कर रहा हूँ
      (1) file system state capture करके plan save करना → (2) state बदली नहीं है यह verify करने के बाद execute और log record करना → (3) पिछली state से compare करके data loss हुआ या नहीं यह validate करना
      मैं इन तीनों चरणों को अलग scripts या flags में बाँटकर इस्तेमाल कर रहा हूँ
    • तब यह सोचने की बात है कि rm command पर ऐसा plan mode कैसे लागू किया जा सकता है

  • जब किसी tool में --dry-run नहीं होता, तो लोग खुद भी बना लेते हैं
    उदाहरण के लिए, किसी complex sed command को चलाने से पहले diff से बदलाव पहले ही compare कर लेते हैं
    diff -u <(echo "hello") <(echo "hello" | sed "s/hello/hi/g") जैसे तरीके से फर्क देखा जा सकता है
    इस बारे में मैंने अपने blog में भी लिखा है

  • मुझे --dry-run pattern पसंद है, लेकिन dry path का code असली path की तरह ही काम करना चाहिए
    अगर वह सिर्फ “क्या करेगा” प्रिंट करे और असली logic को skip कर दे, तो real execution में bugs छूट सकते हैं
    database write या API call से ठीक पहले तक behavior एक जैसा रहना चाहिए

    • लेकिन कुछ लोगों का मानना है कि यह integration testing और dry-run को गड़बड़ा देता है
      dry-run का काम “क्या होने वाला है” दिखाना है, जबकि असली testing अलग चीज़ है

  • मैं इसके उलट --commit या --execute flag रखना पसंद करता हूँ, और default execution को read-only (dry) रखता हूँ
    इससे गलती से असली बदलाव हो जाने की संभावना कम हो जाती है

    • मैं पिछले 8 साल से यही तरीका इस्तेमाल कर रहा हूँ, और क्योंकि बदलाव सिर्फ --commit explicitly देने पर ही होता है, यह सुरक्षित रहा है
      इसके उलट --dry-run भूलकर command चलाने से कई बार हादसे हुए हैं
    • मेरा directory deduplication tool भी यही pattern follow करता है
      default में वह सिर्फ compare करता है, और असली hardlink replacement के लिए --execute देना पड़ता है
    • मैंने पहले ऐसे tools भी इस्तेमाल किए हैं जिनमें असली execution से पहले एक खास phrase टाइप करनी पड़ती थी
      इस तरह की confirmation process गलतियाँ कम करने में असरदार होती है
    • व्यक्तिगत रूप से मुझे --wet-run जैसा flag भी पसंद है। कुछ हालात में उल्टे अर्थ वाला flag ज़्यादा intuitive लगता है
    • हाल में बनाई गई एक script में default mode read-only है, और असली deletion के लिए DELETE-ACCOUNT सीधे टाइप करना पड़ता है
      अब तक एक बार भी गलती से account delete नहीं हुआ है

  • code pollution से बचने के लिए persistence को injectable strategy के रूप में अलग करना चाहिए
    हर जगह if dry_run: डालना अच्छा नहीं है
    बल्कि production execution को --wet-run के रूप में explicitly लिखना ज़्यादा सुरक्षित हो सकता है

    • application के behavior को explicitly model करके उसे central place पर handle करना बेहतर है
      इससे dry-run है या नहीं, इसका फैसला सिर्फ एक ही जगह करना पड़ता है — “functional core, imperative shell” style में
    • लेकिन हर बार rm --wet-run tempfile.tmp जैसा टाइप करना झंझट भरा है
      default अगर real execution हो और बदले में --undo option से पिछला action revert किया जा सके, तो वह भी अच्छा हो सकता है
    • --wet-run नाम मुझे खास पसंद नहीं, लेकिन default को dry-run रखकर --no-dry-run explicitly देने पर ही बदलाव होने वाला तरीका भी मैंने इस्तेमाल किया है
      services के मामले में dev/prod execution environment के हिसाब से safe mode अपने-आप चुनना आदर्श होगा
    • ऐसे मामलों में design patterns का उपयोग structure को साफ-सुथरा रख सकता है

  • लेख में कहा गया था कि “शुरुआत में --dry-run जोड़ा था, और वह उम्मीद से ज़्यादा उपयोगी निकला”,
    लेकिन असल में ऐसे flags अक्सर AI coding agents (जैसे Claude) अपने-आप सुझा देते हैं
    आजकल कई CLI tools में मिलते-जुलते patterns दिखने की एक वजह यह agent-driven code convergence भी हो सकती है

    • लेकिन लेखक ने खुद कहा था कि उन्हें Subversion के --dry-run से प्रेरणा मिली थी, इसलिए यह पूरी तरह विश्वसनीय कारण लगता है

  • मैं CLI utilities में --really flag जोड़ता हूँ, ताकि default mode read-only रहे
    मकसद है गलती रोकने के लिए जानबूझकर confirmation step की माँग करना

    • पहले मैंने --i-meant-that flag वाला command भी देखा है।
      वह remote machine delete करने का command था, और default में 10 सेकंड रुककर cancel करने का मौका देता था
      अच्छी बात यह रही कि इस flag का कभी गलत इस्तेमाल नहीं हुआ

  • PowerShell की एक बढ़िया बात यह है कि [CmdletBinding(SupportsShouldProcess)] की सिर्फ एक line जोड़ने पर
    -WhatIf dry-run feature अपने-आप मिल जाता है। यह बहुत सुविधाजनक feature है

    • इसके साथ -Confirm भी enable हो जाता है, और ShouldProcess function के जरिए user confirmation threshold के साथ interact किया जा सकता है। यह सच में शानदार design है

  • जिस internal CLI को मैं manage करता हूँ, उसमें if not dry_run: को REST API call वाले हिस्से के अंदर रखता हूँ
    इससे असली request भेजने की बजाय CURL command logs छोड़ी जा सकती हैं, ताकि पता चले कौन-सी request जाने वाली है
    लेकिन जब APIs के बीच integration जटिल हो जाता है, तो simulation मुश्किल हो जाती है, और यह साधारण if not dry_run: से कहीं ज़्यादा complex बन जाता है

    • अगर structure ऐसा रखा जाए कि असली action सिर्फ एक ही जगह हो, तो code pollution रोका जा सकता है
      मैं automation pipelines के लिए काफी CLI maintain करता हूँ, और लगभग हर tool में यही pattern लागू करता हूँ
    • लेकिन कुछ लोगों का कहना है कि console tools में REST का ज़रूरत से ज़्यादा इस्तेमाल inefficient है
      पहले local tools को ठीक से बनाना ज़्यादा महत्वपूर्ण है

  • अगर --dry-run flag codebase में हर तरफ बिखरा हुआ है, तो state machine pattern लागू करके हर step को साफ़-साफ़ अलग करना बेहतर है