2009-01-19 11 views
5

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

संपादित करें: अभी हमारा वेब ऐप घर चलाता है और हम क्रूज़ कंट्रोल .NET और MSBuild के साथ WDP के साथ निर्माण करते हैं। ग्राहक को तैनाती के लिए एक अच्छा विकल्प क्या होगा? हम उनके लिए अपनी साइट अपडेट नहीं कर पाएंगे, इसलिए एक समाधान जो उनके लिए तैनाती और अद्यतन करना आसान है वांछनीय है।

उत्तर

12

अपना कोड ब्रांच करें।

उम्मीद है कि आपका कोड स्रोत नियंत्रित है (यदि नहीं, तो अभी शुरू करें!), आपको आधार से "ग्राहक एक्स" शाखा में शाखा बनाना चाहिए और उस शाखा में थोड़ा सा कॉस्मेटिक संशोधन करना चाहिए। उसके बाद उस ग्राहक के लिए उस शाखा का निर्माण और तैनाती करें।

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

टिप्पणियों की समीक्षा करने के बाद: यह ध्यान रखना अच्छा है कि कॉन्फ़िगरेशन व्यावहारिक है, लेकिन केवल तभी परिवर्तनों में से # मामूली हैं, अन्यथा आप कॉन्फ़िगरेशन तर्क के साथ अपने कोड को प्रदूषित करेंगे। (धन्यवाद टिप्पणीकर्ता)

तो: बहुत सारे बदलाव -> शाखा (अधिक रखरखाव योग्य), कुछ मामूली परिवर्तन -> कॉन्फ़िगर करने योग्य (अधिक व्यावहारिक) बनाएं।

+0

+1 इसे कॉन्फ़िगर करने योग्य बनाने के लिए। यदि यह बिल्कुल व्यावहारिक है, तो यह रास्ता तय करने का तरीका है। यह रखरखाव दुःस्वप्न को रोक देगा। – rmeador

+0

बहुत अधिक विन्यास योग्यता रखरखाव दुःस्वप्न भी हो सकता है। हजारों बड़े झंडे होने की तरह कुछ भी नहीं है जो आपके प्रोग्राम को जिस तरह से बदलता है, जिससे बग को ट्रैक करने में कठिनाई होती है। – Kibbee

+0

+1 कॉन्फ़िगर करने योग्य, फिर अगली प्रोजेक्ट में टिप्पणियों के लिए – ccook

0

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

1

हम आमतौर पर डेटा संचालित होने से उन मतभेदों को बनाते हैं। ग्राहक का अंतर सिर्फ एक अलग सेटिंग है; भविष्य में कोई भी अन्य उपयोगकर्ता बाद में उसी "कस्टम" विकल्पों का पुन: उपयोग कर सकता है।

"वन-ऑफ" बनाना स्केल नहीं करता है।

2

हमें इसे हर समय करना है। हम कॉन्फ़िगर करने योग्य संस्करणों के बीच अंतर को सामान्य बनाने और बनाने का प्रयास करते हैं। अनुकूलन के लिए सबसे आम कारण हैं:

  • अतिरिक्त डेटाबेस फ़ील्ड: हम DB में इन वस्तुओं को स्टोर करने के लिए एक गतिशील तरीका लागू किया
  • यूआई लेआउट: हम विशेष फ़ोल्डरों जहाँ हम छवियों और सीएसएस फ़ाइलें, जिस पर लोड किए गए हैं डाल दिया है
  • विभिन्न अनिवार्य इनपुट फ़ील्ड की मांग: हम विन्यास में परिभाषा की दुकान और उन्हें प्रोग्राम के रूप में सक्रिय करने
  • विशेष रिपोर्ट: हम क्रम में कस्टम फ़ोल्डर में टेम्पलेट फ़ाइलों डाल मानक टेम्पलेट
के बजाय चुना जाना

कुछ बदलावों को प्रोग्रामिंग नए मॉड्यूल की आवश्यकता होती है। हम उन्हें एक कस्टम लाइब्रेरी में कोड करते हैं जो मुख्य अनुप्रयोग के अंदर गतिशील रूप से लोड हो जाएगा।

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