निर्भरता को बढ़ावा देने की रणनीति: मौन या आर्केस्ट्रा?

Question

हमारे पास बहुत सारी ऐप और वेब सेवाएं हैं (कुछ सार्वजनिक सामना करने वाले उत्पाद, कुछ आंतरिक और एक निजी "बैकएंड" का हिस्सा) जो एक दूसरे पर निर्भर हैं। इन घटकों में से प्रत्येक में 4 वातावरण हैं (विशिष्ट उद्देश्यों की पूर्ति के लिए सर्वर / नोड्स के क्लस्टर):

• गैर-उत्पादन
  • DEV- समेकित विकास वातावरण जहां सीआई पुश परिवर्तन का निर्माण करता है; इंजीनियरों के लिए मुश्किल से मुश्किल कीड़े खोजने के लिए उपयोगी है जो स्थानीय रूप से प्रतिलिपि प्रस्तुत करने योग्य नहीं हैं
  • QA - पृथक क्यूए / परीक्षण वातावरण
  • DEMO - व्यवसाय हितधारकों के लिए स्थिर यूएटी वातावरण
• उत्पादन
  • LIVE - हमारे लाइव / उत्पादन वातावरण

कोड प्रचार जाता है: LOCAL(डेवलपर की मशीन) => DEV=> QA=> DEMO=>> LIVE।

मान लें कि हमारे पास एक एप्लिकेशन है जिसे myappRESTful वेब सेवा द्वारा समर्थित किया जाता है myws, जिसे स्वयं एक DB नाम से समर्थित किया जाता है mydb।

वर्तमान में, हमारे पास इन निर्भरताओं के बीच " ऑर्केस्ट्रेटेड " पदोन्नति को क्या कहेंगे : जिन myapp-devबिंदुओं का myws-devउपयोग करता है mydb-dev। इसी प्रकार, जिन myapp-qaबिंदुओं का myws-qaउपयोग करता है mydb-qa। के लिए DEMOऔर LIVE।

इसके साथ समस्या यह है कि कभी भी मैं इसमें बदलाव करता हूं, कहता हूं myapp, इसके लिए मुझे mywsऔर mydbसाथ ही बदलाव करने की आवश्यकता है । लेकिन क्योंकि प्रत्येक DEVपर्यावरण अपनी निर्भरता के DEVवातावरण की ओर इशारा करता है, इसका मतलब है कि मुझे इन सभी परिवर्तनों को एक ही समय में शेड्यूल और रोलआउट करना होगा। इसके अलावा, अगर एक निर्माण अस्थिर / टूट जाता है, तो यह अक्सर अन्य अपस्ट्रीम घटकों को नीचे लाता है; उदाहरण के लिए अगर कोई डेवलपर बदलते समय कुछ तोड़ता है mydb-dev, myws-devऔर myapp-devक्लस्टर आमतौर पर अस्थिर हो जाते हैं।

इसे हल करने के लिए, मैं एक प्रस्ताव रख रहा हूं कि मैं " साइलेंट " प्रचार रणनीति क्या कहूंगा : सभी अंतर-घटक निर्भरताएं इस दिशानिर्देश का पालन करती हैं:

• नदी के ऊपर निर्भरता पर निर्भर करते हैं DEMO, उनके नीचे की ओर निर्भरता के लिए पर्यावरण उनके गैर उत्पादन वातावरण के सभी के लिए ( DEV, QAऔर DEMO); तथा
• अपस्ट्रीम निर्भरता LIVEउनके उत्पादन पर्यावरण के लिए उनके डाउनस्ट्रीम निर्भरता के लिए पर्यावरण पर निर्भर करती है

इस सम्मेलन का उपयोग करते हुए, myapp-devएक्टुवल इंगित करेगा myws-demo, जो उपयोग करेगा mydb-demo। इसी तरह, myapp-qaयह भी इंगित करेगा myws-demoऔर mydb-demo।

यहाँ जो लाभ मुझे मिल सकता है वह है स्थिरीकरण का निर्माण : यह बहुत कम संभावना है कि DEMOकिसी विशेष घटक के लिए पर्यावरण अस्थिर हो जाएगा, क्योंकि कोड इसे DEMOकठोर परीक्षण के बिना DEVऔर दोनों पर नहीं बना सकता है QA।

केवल नुकसान मैं इस विधि के लिए मिल सकता है, अगर DEMOएक विशेष घटक के लिए ब्रेक करता है, सभी सभी नदी के ऊपर निर्भरता के लिए गैर उत्पादन वातावरण अचानक टूट कर दिया जाएगा। लेकिन मैं इस बात का जवाब दूंगा कि परीक्षण DEVऔर प्रदर्शन के कारण ऐसा बहुत कम ही होना चाहिए QA।

यह है मिल गया कि कई डेवलपर्स (बहुत चालाक और अपने आप की तुलना में अनुभव) को हल किया है एक समस्या हो सकता है, और मैं इस समस्या और उसके समाधान उन्हें पहले से ही नाम है, तो हैरान नहीं किया जाएगा (मैं क्या बोल रहा हूँ करवाया / डाल दिए अलावा)। इसलिए मैं पूछता हूं: क्या किसी भी प्रचार में मौन प्रचार की रणनीति के गुण किसी भी विपक्ष से आगे निकल जाते हैं, और क्या विपक्ष है कि मैं यहां से गुजर सकता हूं?

Comments

यह एक उत्कृष्ट प्रश्न है, पूछने के लिए धन्यवाद!

— क्रिस क्रेफ़िस

Answer 1

अगर मैं आपकी पोस्ट को सही से पढ़ रहा हूं, तो ऐसा नहीं लगता कि यह प्रस्ताव वास्तव में कथित समस्याओं में से एक है।

कभी भी, मैं, myapp को बदलने के लिए कहता हूं, इससे मुझे myws और mydb में भी बदलाव करने की आवश्यकता है। लेकिन क्योंकि प्रत्येक DEV पर्यावरण अपनी निर्भरता के DEV वातावरण की ओर इशारा करता है, इसका मतलब है कि मुझे इन परिवर्तनों को एक ही समय में शेड्यूल और रोलआउट करना होगा

"साइलेंट प्रमोशन स्ट्रैटेजी" ऐसा लगता है कि यह केवल बदतर बना देगा। यदि myapp v2, myws v2 और mydb v2 केवल DEV पर हैं, और myapp v2 mydb v2 पर निर्भर करता है दुर्घटनाग्रस्त नहीं होने के लिए, तब जब मैं DEV पर myapp v2 चलाने का प्रयास करता हूं तो मैं mydb v1 DEMO को हिट करूंगा और यह क्रैश हो जाएगा। आप अनिवार्य रूप से या तो लगातार सिलोस को ओवरराइड करने के लिए मजबूर होंगे, या mydb v2 को ठेस पहुंचाने से पहले सभी तरह से तैनात कर सकते हैं, यहां तक ​​कि आप myapp v2 पर काम करना भी शुरू कर सकते हैं। इससे भी महत्वपूर्ण बात, आप कभी भी DEV पर mydb v2 का परीक्षण नहीं करेंगे, इसलिए यदि यह टूट गया है तो आपको यह पता भी नहीं चलता है कि यह DEMO पर टूटता है या नहीं, और फिर आप वर्ग एक पर वापस आते हैं।

कुछ हद तक, आप जिस समस्या का वर्णन करते हैं वह अपरिहार्य है चाहे आपका वर्कफ़्लो सेट अप हो, लेकिन इसे कम से कम किया जा सकता है। चाल यह सुनिश्चित करने के लिए है कि mydb और myws के बीच का इंटरफ़ेस (और myws और myapp के बीच का इंटरफ़ेस) कड़ाई से परिभाषित किया गया है, और उस इंटरफ़ेस के सभी अपडेट को पूरी तरह से पीछे की ओर संगत करने की आवश्यकता है । मेरी नौकरी में हमारे पास एक XML स्कीमा है जो हमारे ऐप्स और सेवाओं के बीच इंटरफेस को परिभाषित करता है, और हमारे कई आंतरिक उपकरण बस हमें उन स्कीमाओं के लिए असंगत अपडेट नहीं करने देंगे।

इसके अलावा, अगर एक निर्माण अस्थिर / टूट जाता है, तो यह अक्सर अन्य अपस्ट्रीम घटकों को नीचे लाता है; उदाहरण के लिए अगर कोई डेवलपर mydb-dev को बदलते समय कुछ तोड़ता है, तो myws-dev और myapp-dev क्लस्टर आमतौर पर अप्राप्य हो जाते हैं।

यह मुझे एक गंभीर समस्या की तरह लगता है, लेकिन तैनाती की समस्या नहीं है। एक टूटा हुआ डेटाबेस निश्चित रूप से सेवा और ऐप को ठीक से काम करने से रोकेगा, लेकिन उन्हें "अस्थिर" नहीं बनना चाहिए। उन्हें किसी तरह का त्रुटि संदेश लौटाया जाना चाहिए, ताकि कोई भी देव पर myapp चलाए, "हमें खेद है, हमारा डेटाबेस आज समस्या है" बस दुर्घटनाग्रस्त होने के बजाय।

यदि समस्या यह है कि एक टूटा हुआ डेटाबेस इन समस्याओं का कारण बनता है, तो आप क्या कर सकते हैं कुछ "अस्थायी सिलिंग" प्रणाली स्थापित की गई है जो आपको बताती है कि "mydb DEV अब टूट गया है, कृपया mydb पीईएमओ के लिए सभी myws DEV प्रश्नों को रूट करें समय है"। लेकिन यह केवल अस्थायी सुधार करने का एक तरीका होना चाहिए जब तक कि mydb DEV सामान्य रूप से फिर से काम नहीं कर रहा है। अगर सब कुछ डिफ़ॉल्ट रूप से "चुप" हो जाता है, तो आप मेरे द्वारा बताई गई समस्याओं पर वापस लौट आएंगे क्योंकि कोई भी कभी भी mydb DEV के खिलाफ नहीं चलता है।

मुझे लगता है कि मैं शायद आपके प्रस्ताव को किसी तरह से गलत समझ रहा हूं, लेकिन उम्मीद है कि यह जवाब कम से कम यह स्पष्ट करता है कि गलत समझा जा रहा था और इसे कैसे फिर से लागू करना सबसे अच्छा है।

Comments

धन्यवाद @Ixrec (+1) - नहीं, मुझे नहीं लगता कि आप मेरे प्रश्न को समझ पाए हैं, और आपने सफलतापूर्वक मुझसे बात की, बंद कर दिया।

— स्माइब

अरे वाह, मुझे बहुत खुशी है कि मुझे यह सब लिखने में परेशानी हुई। आपका स्वागत है। =)

— Ixrec

यदि कोई तरीका है जिससे आप अनुबंधों को परिभाषित कर सकते हैं, तो आप अपस्ट्रीम घटकों को तैनात करने से पहले अनुबंधों का परीक्षण करने के लिए स्वचालित परीक्षण मामलों को जोड़ने में सक्षम हो सकते हैं। यदि ये परीक्षण विफल होते हैं, तो आप उस घटक और डाउनस्ट्रीम घटकों में परिवर्तन रोलबैक करते हैं।

— नवीन