4 पॉइंट द्वारा GN⁺ 2024-12-23 | 2 टिप्पणियां | WhatsApp पर शेयर करें

धीमी डिप्लॉयमेंट से मीटिंग्स शुरू होती हैं

  • सॉफ़्टवेयर डिज़ाइन मानवीय रिश्तों का अभ्यास है। सॉफ़्टवेयर डेवलपमेंट में इस्तेमाल होने वाली अन्य स्किल्स में भी यही सच लागू होता है।
  • “कोड को डिप्लॉय नहीं कर पा रहे क्योंकि मीटिंग्स बहुत ज़्यादा हैं” जैसी इंजीनियरों की शिकायत डिप्लॉयमेंट क्षमता की सीमा से भी आ सकती है।
  • Chuck Rossi ने Facebook में यह देखा कि एक डिप्लॉयमेंट में हैंडल किए जा सकने वाले बदलावों की संख्या निश्चित (फिक्स्ड) होती है। यदि अधिक बदलाव चाहिए, तो अधिक डिप्लॉयमेंट करने पड़ते हैं।
  • Facebook ने पिछले 5 वर्षों में डिप्लॉयमेंट गति को हफ्तावारी से दिन में एक बार और दिन में तीन बार तक बढ़ाया; मोबाइल ऐप डिप्लॉयमेंट साइकिल को भी 6 हफ्तों से घटाकर 4 हफ्ते और फिर 2 हफ्ते कर दिया।
  • “डिप्लॉयमेंट प्रति बदलाव” एक कठोर (inflexible) metric है, इसमें सुधार संभव है लेकिन इसमें समय लगता है। यदि बदलावों की संख्या मौजूदा थ्रेशहोल्ड से ऊपर चली जाए तो बदलावों की गिनती घटानी पड़ती है।
  • यदि संगठनात्मक ओवरहेड बढ़ाया जाता है तो एक पॉज़िटिव फीडबैक लूप शुरू होता है: काम का बोझ कम होता है -> दबाव बढ़ता है -> गलतियाँ बढ़ती हैं -> प्रति डिप्लॉयमेंट बदलाव घटते हैं -> ओवरहेड बढ़ता है -> काम का बोझ और कम होता है।
  • अधिक बदलाव संभालने के लिए डिप्लॉयमेंट क्षमता बढ़ानी होगी। या तो डिप्लॉयमेंट की आवृत्ति कम करनी होगी, या प्रति डिप्लॉयमेंट बदलाव बढ़ाने होंगे।
  • ओवरहेड घटाने का प्रयास अंततः मीटिंग्स तक ले जा सकता है। यह एक साथ बहुत अधिक कोड डिप्लॉय करने की कोशिश को रोक देता है।

सॉफ़्टवेयर डिज़ाइन: Tidy First?

  • सॉफ़्टवेयर डिज़ाइन मानवीय रिश्तों का अभ्यास है। किसी तकनीकी कौशल को सुधारना रिश्तों को बेहतर बनाने के तरीकों में से एक है।

2 टिप्पणियां

 
roxie 2024-12-24

यह राय अच्छी है

 
GN⁺ 2024-12-23
Hacker News टिप्पणी
  • तैनाती के जोखिम को कम करने के लिए टेस्टिंग और संगठनात्मक व्यवहार में सुधार करना महत्वपूर्ण है, लेकिन यही अकेला तरीका नहीं है

    • प्रत्येक डिप्लॉयमेंट में बदलावों की संख्या घटाना अधिक प्रभावी रहता है
    • छोटे बदलावों को बार-बार डिप्लॉय करने से जल्दी value deliver होती है और छोटे-छोटे विफलताओं का अनुभव होता है
    • Canary deployment और gradual rollout के साथ जोड़ने पर डिप्लॉयमेंट बड़ा जोखिम नहीं रह जाता
    • DORA रिसर्च, Accelerate, The Phoenix Project और The Goal में यह approach समर्थन करता है
  • "software literacy" या सॉफ्टवेयर साक्षरता की अवधारणा समझाने की कोशिश की गई

    • यानी कंपनी का कोड के ज़रिये ऑपरेट हो सकना
    • अगर सभी decision-makers का फोकस कोड पर नहीं है तो software literacy की कमी मानी जाती है
    • कंपनी को नए concepts के साथ ऑपरेट होने में सक्षम होना चाहिए
  • CI pipeline में टेस्टिंग समय लंबा हो जाने पर recovery पर फोकस करने का फैसला लिया गया

    • टेस्टिंग को सरल बनाकर और recovery पर ध्यान देकर deployment strategy के तौर पर Canary का इस्तेमाल किया गया
    • यह approach उनके लिए एक ताज़ा अनुभव था
  • संगठन deployment सुधार में बाधा बन सकता है

    • अधिकतर संगठनों में नौकरशाही से लड़ना लगभग असंभव है
    • धीमी deployment समस्या है, लेकिन यही अकेली समस्या नहीं
  • बड़े बदलाव के डर से टेस्टिंग बढ़ती जाती है

    • मीटिंग ही लक्ष्य बन जाने की प्रवृत्ति दिखती है
    • गैर-तकनीकी management के साथ तकनीकी बदलाव चलाने के तरीके पर सलाह की जरूरत है
  • CloudFormation धीमा क्यों है, इस पर प्रश्न

  • माइक्रोसर्विसेस deployment frequency को हरीजॉन्टल तरीके से स्केल करने में मदद करती हैं

  • सॉफ्टवेयर performance, यानी human performance, महत्वपूर्ण है

    • तेजी से repeat करने और risk घटाने के लिए तेज़ टेस्ट ऑटोमेशन ज़रूरी है
  • तेज़ deployment incident response मीटिंग्स को ट्रिगर करता है