आप एक बहु-पक्षीय परियोजना में संस्करण को कैसे संभालते हैं?

Question

मुझे पता है कि यह एक व्यापक प्रश्न है, इसलिए मैं यथासंभव विशिष्ट होने की कोशिश करूंगा। यह प्रश्न एक तकनीकी से अधिक "संगठनात्मक" प्रश्न है।

हमारे पास इन मुख्य घटकों के साथ एक बहु-पक्षीय परियोजना है:

• कोर बिजनेस लॉजिक (डेटा मॉडल) की मेजबानी करने वाला एक सर्वर
• मुख्य व्यवसाय तर्क का उपयोग करने वाले ग्राहकों के लिए एक बैकऑफ़िस
• एक एप्लिकेशन API (REST) ​​जो मुख्य व्यवसाय तर्क का भी उपयोग करता है
• एप्लिकेशन API का उपयोग करके स्मार्टफोन एप्लिकेशन (iOS और Android) हैं
• एक ही एप्लिकेशन एपीआई का उपयोग करके स्मार्टफोन से अलग एक अन्य टैबलेट ऐप (एंड्रॉइड) है।

जल्द ही, मैं सक्रिय ग्राहकों के साथ उत्पादन करूंगा। और किसी भी परियोजना के रूप में, मुझे समय के साथ सभी विभिन्न घटकों को बनाए रखने की आवश्यकता होगी। इसका मतलब है कि निम्नलिखित में से सभी को उन्नत किया जा सकता है:

• सर्वर में कोर बिजनेस लॉजिक का कोड (बैक-ऑफिस, एपीआई और साइड इफेक्ट के रूप में मोबाइल ऐप द्वारा उपयोग किया जाता है)
• एपीआई ही (स्मार्टफोन और टैबलेट ऐप दोनों द्वारा उपयोग किया जाता है)
• सभी मोबाइल एप्लिकेशन (appstore / googleplay के माध्यम से)

बेशक, सर्वर-साइड पार्ट्स (कोर बिजनेस लॉजिक कोड और एपीआई कोड) को खुद से तुरंत बदला जा सकता है। हालाँकि, नए मोबाइल ऐप को ग्राहकों द्वारा ऐपस्टोर / googleplay पर डाउनलोड किया जाना चाहिए, और मुझे यकीन नहीं हो रहा है कि वे अद्यतित हैं।

क्या आप किसी भी मार्गदर्शन, अच्छी प्रथाओं के सुझाव प्रदान कर सकते हैं, ताकि ग्राहक के लिए शोध को सुचारू बनाया जा सके?

मुझे "संस्करण" के लिए किस घटक की आवश्यकता है? अगर क्लाइंट अपने मोबाइल ऐप को अपग्रेड नहीं करता है तो भी सब कुछ कैसे सुनिश्चित किया जाए? क्या मुझे अपना काम आसान करने के लिए उसे अपग्रेड करने के लिए मजबूर करना चाहिए?

एक शब्द में, मुझे समय के साथ अपने बहु-पक्षीय-परियोजना को लाइव करने के लिए कैसे व्यवस्थित करना चाहिए?

Comments

क्या आपकी समस्या अलग रूप एपि वर्जनिंग है ?

— k3b

हां, इनमें से अधिकांश विषय सार्वजनिक एपीआई के मामले में एपीआई संस्करण के बारे में प्रतीत होते हैं। मेरा एपीआई 'एप्लिकेशन / निजी' एपीआई है, इसका उपयोग केवल मेरे मोबाइल एप्लिकेशन को काम करने के लिए किया जाता है। इसके अलावा, मेरा प्रश्न व्यापक है क्योंकि यह एक विशेष घटक की चिंता नहीं करता है, लेकिन पूरी परियोजना :)

— डेविड डी।

Answer 1

जब आप नियंत्रित नहीं कर सकते हैं जब मोबाइल एप्लिकेशन को एक नए रिलीज़ में अपडेट किया जाएगा, तो आपको कम से कम अपने REST API को संस्करणित करना होगा। यदि आप ऐसा नहीं करते हैं, तो उस इंटरफ़ेस में पीछे-असंगत परिवर्तन करना असंभव होगा।

REST API के अलावा, एक अन्य इंटरफ़ेस इंटरफ़ेस जो नेटवर्क इंटरफ़ेस पर भी जाता है, को भी संस्करणित करना एक अच्छा विचार है। इस तरह, आपको सर्वर के रूप में एक ही समय में सभी बैकऑफ़िस क्लाइंट को अपग्रेड करने के लिए मजबूर नहीं किया जाता है और आप "बीटा टेस्ट" अवधि के साथ एक नए संस्करण में क्रमिक माइग्रेशन को लागू कर सकते हैं।

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

Comments

इसके लिए धन्यवाद। समझने के लिए सुनिश्चित करें, क्या आप एक उदाहरण प्रदान कर सकते हैं कि "अन्य संचार इंटरफ़ेस" क्या हो सकता है?

— डेविड डी।

@ डेविड: अन्य संचार इंटरफेस का एक उदाहरण बैकऑफ़िस क्लाइंट और कोर बिजनेस सर्वर के बीच का इंटरफ़ेस होगा। या एपीआई सेवा और मुख्य व्यवसाय सेवा के बीच।

— बार्ट वैन इनगेन शानौ

Answer 2

यह पोस्ट आपके प्रश्न के बारे में एक दिलचस्प बात बताती है।

अधिक व्यावहारिक तरीके से, यदि आपके पास 3 घटक हैं:

• 2 उपभोक्ता: एक फ्रंट-एंड और एक मोबाइल ऐप
• 1 एपीआई प्रदाता: एक बैक-एंड

आप प्रत्येक के लिए विशिष्ट Mmp (Major.minor.patch) संस्करण योजना का उपयोग कर सकते हैं, लेकिन अपने बैक-एंड url पर आप कुछ के रूप में डाल सकते हैं http://youhost/M.m/resourceURI।

जैसा कि आप विकसित होते हैं और एपीआई में परिवर्तन आपके अनुबंध को प्रभावित नहीं करते हैं, M.mजैसा कि आप URL में रखते हैं। जिस क्षण से आप बैकएंड में बदलाव करते हैं जो आपके उपभोक्ताओं को प्रभावित करता है (जैसा कि यह व्यवहार में परिवर्तन या एक वस्तु जो अलग है) आप एक का उपयोग करते हैं M.m+1, M+1.m+1या M+1.m।

चीजों को चालू रखने का तरीका नए बैक-एंड को पुराने के साथ समवर्ती रूप से तैनात करना है, जबकि आपके उपयोगकर्ता नए उपभोक्ता स्थापित करते हैं, और पुराने एपीआई को धीरे-धीरे बंद करते हैं।

आप खदान से बेहतर रास्ता देख सकते हैं, यहां: स्टैकओवरफ्लो पर वर्जन रीस्ट एपीआई

Comments

मुझे लगता है कि मेरी परियोजना में 1 से अधिक मुख्य व्यावसायिक तर्क होना असंभव है (अन्यथा मुझे कई डेटाबेस की आवश्यकता होगी)। लेकिन मैं यह सुनिश्चित कर सकता हूं कि सभी REST API अभी भी इस वर्तमान मुख्य व्यवसाय तर्क के साथ कंपेटिबल रहें। यह मत भूलो कि मेरे एपीआई सार्वजनिक एपीआई नहीं हैं और उपभोक्ताओं को सीधे यूआरआई का उपयोग नहीं करना चाहिए। मेरे ग्राहक अनुप्रयोग करते हैं। M / m + 1 अंकन धन्यवाद के लिए अच्छा बिंदु।

— डेविड डी।

ठीक है, अगर आपके पास किसी प्रकार का प्रॉक्सी / लोड बैलेंसर है जो एपीआई URL को छुपाता है तो आप केवल एक कस्टम HTTP हैडर जोड़ सकते हैं और लोड बैलेंसर को कॉन्फ़िगर कर सकते हैं प्रत्येक कार्यान्वयन को इंगित करने के लिए प्रत्येक उपभोक्ता को उसी URL पर HTTP संदेश भेजना होगा लेकिन हेडर में अपेक्षित एपीआई संस्करण का संकेत।

— मिमसुगारा

Answer 3

मैं आपको एक निरंतर एकीकरण सर्वर स्थापित करने की सलाह देता हूं, इसे अपने कोड रिपॉजिटरी और एक स्नैपशॉट / रिलीज रिपॉजिटरी पर हुक करें और इन बिल्ड को स्वचालित करें। इससे कई फायदे होंगे:

1. रिलीज़ होने पर हर घटक का संस्करण होगा। इसमें निम्न-स्तरीय लाइब्रेरी के साथ-साथ आपके अंतिम उत्पाद भी शामिल हैं।
2. हर कोड कमिट एक स्नैपशॉट बिल्ड को ट्रिगर करेगा। यह आपके डेवलपर्स को ईमानदार रखने में मदद करता है, खासकर यदि आप उस अपराधी को ईमेल करने के लिए सुविधा का उपयोग करते हैं जिसने बिल्ड को तोड़ दिया था।
3. प्रत्येक बिल्ड इकाई परीक्षण चला सकता है। यह स्पष्ट रूप से कोड की गुणवत्ता में सुधार करता है।
4. हर रिलीज को टैग किया जाएगा, इसलिए यदि उत्पादन तय करना आवश्यक है, तो टैग से शाखा लगाना और फिक्स करना आसान है।
5. आपको किसी प्रकार के संगतता रजिस्टर को बनाए रखने की आवश्यकता होगी। (उदा। बैकऑफिस 1.0.23 REST एपीआई 2.0.267 आदि के साथ संगत है)। मुझे इस क्षेत्र में मदद करने वाले उपकरण का पता नहीं है।

मेरा अनुभव ओपन सोर्स टूल्स के साथ रहा है: एसवीएन, मेवेन 2, जेनकिन्स और नेक्सस, लेकिन इन सभी के विकल्प हैं।

अपनी टीम को गति प्राप्त करने के लिए सीखने के समय को कम मत समझो। लेकिन एक बार जब वे गति में आ जाते हैं, तो वे कभी पीछे नहीं हटेंगे।

Comments

दिलचस्प बिंदु धन्यवाद। अगर मेरा प्रोजेक्ट 3 git repos (बैकएंड के लिए 1, टैबलेट ऐप के लिए 1, स्मार्टफोन ऐप के लिए 1) में फैला हुआ है तो क्या ऑटो-स्नैपशॉट बिल्ड काम कर सकता है?

— डेविड डी।

@ डेविड डब्ल्यू जेनकिन्स निश्चित रूप से इसका समर्थन करते हैं, क्योंकि प्रत्येक नौकरी का अपना कोड रिपॉजिटरी URL होता है।

— कीवरोन

Answer 4

विकास और परिनियोजन के लिए अपेक्षाकृत छोटी टीम के लिए, आईबीएम जैज द्वारा नियोजित क्लाइंट एन -1 संगतता मॉडल बहुत अच्छा काम कर सकता है

क्लाइंट और सर्वर को एक ही वर्जन नंबर पर रखने की कोशिश करें । [स्वतंत्र संस्करणों और उनकी संगतता के मैट्रिक्स के प्रबंधन के बजाय]

एक नीति बनाएं कि क्लाइंट संस्करण Xyy Xyy के ऊपर सभी सर्वर संस्करणों के साथ काम करे लेकिन X + 2.0.0 से कम हो

सर्वर संस्करण 4.0 के लिए, आदर्श रूप से प्रत्येक क्लाइंट प्रकार के लिए क्लाइंट संस्करण 4.0 होना चाहिए। हालांकि, ग्राहकों और सर्वरों के थोड़े अलग संस्करणों की अनुमति देने के लिए संगतता को बनाए रखा जाना चाहिए।

एक क्लाइंट संस्करण 4.x सर्वर संस्करण 4.x और इसके बाद के संस्करण 6.0 के साथ संगत होना चाहिए; एक सर्वर 4.x को सभी क्लाइंट संस्करण 3.0 और उससे अधिक के साथ संगत होना चाहिए, लेकिन 4.x से कम या उसके बराबर

इस तरह आप क्लाइंट के नए संस्करणों की तत्काल रिलीज की चिंता किए बिना सर्वर पर एक संस्करण को अपडेट कर सकते हैं, लेकिन बनाए रखने के लिए संगतता की केवल एक अच्छी तरह से परिभाषित विंडो होगी।

Ref: आईबीएम जैज मॉडल [ https://www.ibm.com/support/knowledgecenter/en/SSYMRC_6.0.0/com.ibm.jazz.install.doc/topics/c_n-1.html]

Answer 5

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

1. संस्करण नियंत्रण - संस्करण नियंत्रण एक विन्यास प्रबंधन उपकरण है जो आपको स्नैपशॉट और आपके विकास के इतिहास पर नज़र रखने में मदद करता है। सभी कोड के अनजाने संस्करण नियंत्रण होना चाहिए। मुझे परवाह नहीं है अगर यह सिर्फ आपके बिन फ़ोल्डर में जोड़ने वाली सुविधा स्क्रिप्ट है, जो कुछ भी लिखने के समय बिताने के लायक था, एक संशोधन नियंत्रण सॉफ्टवेयर में जोड़ने के लिए दो सेकंड के लायक है।
2. कॉन्फ़िगरेशन प्रबंधन - मैं निर्माण में क्या है इसे कैसे नियंत्रित करता हूं। सभी सॉफ़्टवेयर में कुछ हद तक कॉन्फ़िगरेशन प्रबंधन होना चाहिए। मैं प्रबंधकों को संस्करण नियंत्रण और कॉन्फ़िगरेशन प्रबंधन के बीच के अंतर का वर्णन करना पसंद करता हूं क्योंकि संस्करण नियंत्रण विकास के इतिहास पर नज़र रखने के लिए सिर्फ एक उपकरण है, जबकि कॉन्फ़िगरेशन प्रबंधन हम कैसे इतिहास बनाते हैं, और कैसे हम कोड तय करते हैं जैसी चीजें करते हैं। अच्छा है।
3. सॉफ्टवेयर संस्करण - कोड के रिलीज के लिए नाम निर्दिष्ट करना। यह वह चीज है जिसे बहुत से लोग तब देखते हैं जब वे पहली बार समस्या देखते हैं क्योंकि वे "MineSweeper 7.1.29290149210" या जो भी सामान खरीदते हैं, उसे देखने के लिए उपयोग किया जाता है, लेकिन ईमानदारी से मुझे यह एक बहुत बड़ी समस्या का सबसे मामूली हिस्सा लगता है। ईमानदार होने के लिए, बस 1 से उत्पन्न हैश का उपयोग करना और सभी को इतना ध्यान नहीं देना चाहिए कि इसका मानव पढ़ने योग्य नहीं है।

इसलिए चूंकि यह मेरे लिए सबसे अधिक अस्पष्ट और सबसे दिलचस्प है, मैं सिर्फ # 2 पर ध्यान केंद्रित करने जा रहा हूं। कॉन्फ़िगरेशन प्रबंधन के लिए कोई एक आकार-फिट-सभी, कुकी-कटर समाधान नहीं है। नियम जो 2 या 3 की टीम के लिए अच्छी तरह से काम करते हैं, सैकड़ों श्रमिकों को लेने वाली परियोजना में विवेक रखने के लिए बहुत ढीले हो सकते हैं। बड़ी टीम के काम करने वाले नियमों को छोटी टीम के लिए बहुत अधिक ओवरहेड की आवश्यकता हो सकती है। आप सबसे अधिक संभावना है कि आप कुछ पाने के लिए अपने स्वयं के कुछ को कोबल करेंगे, लेकिन मैं निम्नलिखित सूची का उपयोग आपके कॉन्फ़िगरेशन प्रबंधन प्रणाली के लिए चश्मा विकसित करने के तरीके के रूप में करूंगा:

1. मैं संस्करणों (और उनसे जुड़ी समस्याओं) का ट्रैक कैसे रख सकता हूं जो मैं बाजार में समर्थन कर रहा हूं?
2. मैं यह कैसे तय करूंगा कि उत्पादन प्रणालियों को जारी करने के लिए कौन से विकास पथ तैयार हैं? (यह किसी प्रक्रिया में किसी अन्य चरण के लिए भी तैयार हो सकता है)
3. सिस्टम के विन्यास का नियंत्रण / प्रबंधन किसके पास होना चाहिए? अन्य डेवलपर्स को वितरित किए जाने वाले कोड को जोड़ने के लिए वर्कफ़्लो क्या है?
4. मैं बातचीत करने वाले भागों के बीच की बातचीत को कैसे नियंत्रित करने जा रहा हूं? मुझे कैसे पता चलेगा कि कोई हिस्सा बदलने से बाकी सिस्टम टूट जाएगा?
5. हम समय के साथ अपनी विन्यास प्रबंधन प्रणाली को कैसे सुधारेंगे।

उपरोक्त प्रश्नों का उत्तर देने में सहायता चाहिए? आपको शायद एक सलाहकार या सॉफ्टवेयर इंजीनियरिंग प्रबंधक को नियुक्त करना चाहिए ... उत्तर देना जो पाठ्यपुस्तकों को भर सकता है और इस प्रकार के फोरम के लिए गुंजाइश से बाहर है।

Comments

बहुत दिलचस्प जवाब, इसके लिए धन्यवाद। # 1 प्रश्न "एक-घटक" परियोजना में उत्तर देना आसान है और एक बहु घटक परियोजना में बहुत जटिल लगता है।

— डेविड डी।