22

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

समस्या यह है कि प्रत्येक ग्राहक स्थानीय राज्य या यहां तक ​​कि काउंटी कानून या नौकरशाही के आधार पर अक्सर अपने स्वयं के स्थानीय परिस्थितियों और शर्तों के लिए आवश्यक है, जो अक्सर अपनी स्थानीय परिस्थितियों और शर्तों के लिए आवश्यक है। इसलिए जब संभवतः 90-95% सिस्टम सभी ग्राहकों में समान है, तो हमें इन छोटे अनुकूलन का निर्माण और समर्थन करना होगा।

इसके अलावा, सिस्टम अभी भी बहुत काम प्रगति पर है। कोर सिस्टम पर लगातार बढ़ रहे संवर्द्धन और बग फिक्स हैं जिन्हें सभी ग्राहकों पर लागू करने की आवश्यकता है।

हम .NET (एएसपी, सी #) में कोड लिख रहे हैं, एमएस-एसक्यूएल 2005 हमारे डीबी सर्वर है, और हम SourceGear Vault का उपयोग हमारे स्रोत नियंत्रण प्रणाली के रूप में कर रहे हैं। मैंने पहले वॉल्ट में ब्रांचिंग के साथ काम किया है, और यह बहुत अच्छा है अगर आपको केवल 2 या 3 शाखाओं को सिंक्रनाइज़ करने की आवश्यकता है - लेकिन हम सैकड़ों शाखाओं को बनाए रखने की सोच रहे हैं, जो कि सिर्फ असंभव है।

मेरा प्रश्न है: हम आपको यह सब कैसे प्रबंधित करने की सलाह देते हैं?

मुझे उम्मीद है कि उत्तर ऑब्जेक्ट आर्किटेक्चर, वेब सर्वर आर्किटेक्चर, स्रोत नियंत्रण प्रबंधन, डेवलपर टीम आदि जैसी चीजों को संबोधित करेंगे। मेरे पास कुछ विचार हैं, लेकिन मुझे इस तरह के कुछ प्रबंधन में कोई वास्तविक अनुभव नहीं है, और मैं वास्तव में उन लोगों से सुनवाई की सराहना करता हूं जिन्होंने इस तरह की चीज पहले की है।

धन्यवाद!

उत्तर

19

मैं के खिलाफ अलग कोड शाखाओं ग्राहक प्रति बनाए रखने की सिफारिश करेंगे। यह आपके कोर के खिलाफ कामकाजी कोड बनाए रखने के लिए एक दुःस्वप्न है।

मुझे सलाह है कि आप Strategy Pattern को कार्यान्वित करें और स्वचालित परीक्षणों के साथ अपने "ग्राहक अनुकूलन" को कवर करें (उदा। यूनिट कार्यात्मक) जब भी आप अपना कोर बदल रहे हों।

अद्यतन:

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

उदाहरण के लिए, जब आपने अभी ग्राहक एक्स (उम्मीद है कि वेब के माध्यम से सभी) साइन अप किया है, तो उनकी वेबसाइट XX मिनट में बनाई जाएगी और ग्राहक को यह ईमेल तैयार करने के लिए एक ईमेल भेज देगा।

आप निश्चित रूप से निरंतर एकीकरण (सीआई) वातावरण स्थापित करना चाहते हैं। TeamCity एक शानदार उपकरण है, और मुफ्त।

इस जगह के साथ, आप एक स्टेजिंग वातावरण में अपने अपडेट की जांच कर पाएंगे और फिर अपने उत्पादन उदाहरणों में उन पैच को लागू कर सकते हैं।

बॉटम लाइन: एक बार जब आप ग्राहकों के एक मुट्ठी भर से अधिक मिलता है, आप अपने आप के लिए एक और आवेदन के रूप में अभी तक अपने संचालन और अपने तैनाती को स्वचालित के बारे में सोचना शुरू की जरूरत है।

अद्यतन: यह post प्रति ग्राहक ब्रांचिंग के नकारात्मक प्रभावों को दर्शाता है।

+0

+1 धन्यवाद - महान सलाह –

+0

+ उत्तर क्रेडिट - इस प्रश्न पर बहुत सारे अच्छे उत्तर, लेकिन मुझे लगता है कि आपका सबसे उपयोगी और संक्षिप्त है। धन्यवाद! –

10

यह ऐसा कुछ नहीं है जिसे आप स्रोत नियंत्रण प्रबंधन के साथ हल करना चाहते हैं, लेकिन आपके आवेदन की वास्तुकला के भीतर।

मैं आर्किटेक्चर जैसे किसी प्रकार की प्लगइन के साथ आउंगा। कौन सी प्लगइन्स का उपयोग करने के लिए कौन सी वेबसाइट कॉन्फ़िगरेशन समस्या बन जाएगी, न कि स्रोत नियंत्रण समस्या।

यह उन चीजों के लिए शाखाओं आदि का उपयोग करने की अनुमति देता है जिनके लिए वे हैं: (या शायद यहां तक ​​कि ओवर) रिलीज के बीच कोड के समानांतर विकास। प्रत्येक प्लगइन आपके स्रोत कोड सिस्टम के भीतर एक अलग परियोजना (या उपप्रोजेक्ट) बन जाता है। यह आपको निर्भरता एनालिसिस आदि के साथ मदद करने के लिए सभी प्लगइन और आपके मुख्य अनुप्रयोग को एक दृश्य स्टूडियो समाधान में गठबंधन करने की अनुमति देता है।

आपके आवेदन में विभिन्न घटकों को संक्षेप में जोड़ना सबसे अच्छा तरीका है।

0

एप्लिकेशन को लेयर करें। उन परतों में से एक में अनुकूलन शामिल है और शेष प्रणाली पर किसी भी समय प्रभावित किए बिना किसी भी समय बाहर निकाला जा सकता है। आवेदन- और डीबी-स्तरीय "ट्रिगर्स" (उद्धृत क्योंकि वे वास्तविक डीबी ट्रिगर्स को नियोजित नहीं कर सकते हैं) या जो ग्राहक-विशिष्ट कोड को कॉल करते हैं या ग्राहक कुंजी के साथ parametrized हैं) बहुत उपयोगी हैं।

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

2

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

हमारे उत्पाद इस दृष्टिकोण का उपयोग करते हैं और हमारे पास जो कुछ है (कोर) की कार्यक्षमता कुछ है सभी क्लाइंट्स के लिए, एक या अधिक क्लाइंट्स और कोर पर उपयोग किए जाने वाले कस्टम मॉड्यूल एक "कस्टमाइज़ेशन" एक साधारण वर्कफ़्लो इंजन है जो विभिन्न क्लाइंट्स के लिए अलग-अलग वर्कफ़्लो का उपयोग करता है, इसलिए प्रत्येक क्लाइंट को कोर कार्यक्षमता मिलती है, इसका अपना वर्कफ़्लो होता है और मॉड्यूल के कुछ विस्तारित सेट जो क्लाइंट विशिष्ट हैं या एक क्लाइंट के लिए सामान्यीकृत हैं।

यहाँ आप बहु किरायेदारी वास्तुकला पर आरंभ करने के लिए कुछ न कुछ है:

Multi-Tenant Data Architecture

10

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

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

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

हम क्योंकि हमारे ग्राहकों के कई के लिए मुख्य रूप से प्रत्येक ग्राहक के लिए एक अलग डेटाबेस का उपयोग,, कानून या ग्राहक खुद को यह गोपनीयता की चिंताओं, आदि की वजह से की आवश्यकता होती है ...

मैं कहूँगा कि व्यापार तर्क मतभेद शायद हमारे लिए अनुभव का कम से कम कठिन हिस्सा रहा है (आपका लाभ आवश्यक अनुकूलन की प्रकृति के आधार पर भिन्न हो सकता है)। हमारे लिए, व्यापार तर्क में सबसे अधिक विविधताओं विन्यास मानों का एक सेट है जो हम चाहते हैं कि (यदि मशीन विशिष्ट) तैनाती पर संशोधित किया गया है या एक क्लाइंट-विशिष्ट फ़ोल्डर में संग्रहीत और स्रोत नियंत्रण में रखा एक xml फ़ाइल में स्टोर में बांटा जा सकता है (विस्तार से बताया नीचे)। व्यवसाय तर्क इन मानों को रनटाइम पर प्राप्त करता है और उचित रूप से इसके निष्पादन को समायोजित करता है। आप इसे विभिन्न रणनीति और फैक्ट्री पैटर्न के साथ संगीत कार्यक्रम में भी उपयोग कर सकते हैं - कॉन्फ़िगर फ़ील्ड में रणनीतियों आदि के नाम हो सकते हैं ...। इसके अलावा, यूनिट परीक्षण का उपयोग यह सत्यापित करने के लिए किया जा सकता है कि जब आप परिवर्तन करते हैं तो आपने अन्य क्लाइंट के लिए चीजें तोड़ नहीं दी हैं। वर्तमान में, सिस्टम में सबसे नए ग्राहकों को जोड़ने में उचित कॉन्फ़िगरेशन मानों को मिलाकर/मिलान करना शामिल है (जहां तक ​​व्यवसाय तर्क का संबंध है)।

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

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

+1

+1 - इसे लिखने के लिए धन्यवाद - वास्तव में उपयोगी सामान! –

1

अधिक जानकारी के बिना, जैसे क्लाइंट विशिष्ट अनुकूलन के प्रकार, कोई केवल अनुमान लगा सकता है कि परिवर्तन कितने गहरे या सतही हैं। कुछ सरल/मानक विधियों पर विचार करना:

  • आप ग्राहक
  • करने के लिए ग्राहक से विशिष्टता को निर्दिष्ट एक केंद्रीय config रखने आप एक वर्ग के लिए व्यापार के नियम या वर्गों के समूह को केंद्रीकृत कर सकते हैं कर सकते हैं
  • आप तो डेटाबेस में व्यापार के नियम की दुकान और ग्राहक
  • के आधार पर बाहर खींच कर सकते हैं व्यापार के नियम सभी DB/एसक्यूएल आधारित (प्रत्येक ग्राहक के लिए अपने स्वयं के डीबी

कुल मिलाकर कठिन कोडिंग विभिन्न होने जा सकता है, तो क्लाइंट नाम/आईडी के आधार पर nces बहुत ही समस्याग्रस्त है, प्रति क्लाइंट के अलग-अलग कोड आधारों को महंगा रखना (90% के लिए आवश्यक पूर्ण परीक्षण/रीस्टस्टिंग समय के बारे में सोचें) जो ...मुझे लगता है कि उचित जानकारी देने के लिए अधिक जानकारी की आवश्यकता है (कुछ विनिर्देश दें)

0

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

अभी हम नियम इंजन का उपयोग कर प्रक्रिया में बदलना चाहते हैं, लेकिन कुछ चिंता है कि प्रक्रियाओं की संख्या के लिए परफॉर्मेंस नहीं होगा, जिसे हमें संसाधित करने में सक्षम होना चाहिए। हालांकि, आपकी परिस्थितियों में, यह एक व्यवहार्य विकल्प हो सकता है।

0

मैं कुछ अनुप्रयोगों कि पेशकश की निम्नलिखित अनुकूलन का उपयोग किया है:

  1. वेब पृष्ठों विन्यास थे - हम, दृश्य से बाहर खेतों खींचें सकता है उन्हें स्थिति है जहाँ हम क्षेत्र लेबल के लिए अपने स्वयं के नाम के साथ करना चाहता था।
  2. अपने स्वयं के विचार या संग्रहित प्रक्रियाएं जोड़ें और इनका उपयोग करें: डेटा ग्रिड (एक अद्यतन प्रो के साथ) और रिपोर्ट। प्रत्येक ग्राहक को अपने डेटाबेस की आवश्यकता होगी।
  3. सिस्टम में डेटा आयात करने के लिए एक्सेल फ़ाइलों का कस्टम मैपिंग।
  4. हमारे स्वयं के गणना किए गए फ़ील्ड जोड़ें।
  5. विभिन्न घटनाओं के दौरान प्रपत्रों पर कस्टम स्क्रिप्ट चलाने की क्षमता।
  6. अपने स्वयं के कस्टम फ़ील्ड की पहचान करें।

आप ग्राहकों बड़ी कंपनियों रहे हैं, तो आप लगभग अपनी खुद की एसडीके, एपीआई, आदि की जरूरत के लिए जा रहे

0

अन्य महान संसाधन था, आप बहु किरायेदारी के लिए अपने ब्लॉग पर खोज श्रृंखला Ayende है ।

संबंधित मुद्दे