मैं एक बड़े सॉफ्टवेयर प्रोजेक्ट पर काम कर रहा हूं, जो दुनिया भर के विभिन्न ग्राहकों के लिए अत्यधिक अनुकूलित है। इसका मतलब है कि हमारे पास शायद 80% कोड है जो विभिन्न ग्राहकों के बीच आम है, लेकिन बहुत सारे कोड भी हैं जिन्हें एक ग्राहक से दूसरे में बदलना होगा। अतीत में हमने अलग-अलग रिपॉजिटरी (एसवीएन) में अपना विकास किया और जब एक नई परियोजना शुरू हुई (हमारे पास कुछ, लेकिन बड़े ग्राहक हैं) ने हमारी पिछली जरूरतों के लिए सबसे अच्छा कोड आधार जो भी था, उसके आधार पर एक और रिपॉजिटरी बनाई। यह अतीत में काम किया है, लेकिन हम कई समस्याओं में भाग गए:
- कीड़े जो एक रिपॉजिटरी में तय किए गए हैं, अन्य रिपॉजिटरी में पैच नहीं किए गए हैं। यह संगठन की समस्या हो सकती है, लेकिन मुझे 5 विभिन्न रिपॉजिटरी में बग को ठीक करना और पैच करना मुश्किल लगता है, यह ध्यान में रखते हुए कि इस रिपॉजिटरी को बनाए रखने वाली टीम दुनिया के किसी अन्य हिस्से में हो सकती है और हमारे पास उनके परीक्षण का वातावरण नहीं है , न तो उनके कार्यक्रम को जानते हैं या उनकी क्या आवश्यकताएं हैं (एक देश में "बग" दूसरे में "सुविधा" हो सकती है)।
- एक परियोजना के लिए किए गए सुविधाएँ और सुधार, जो किसी अन्य परियोजना के लिए भी उपयोगी हो सकते हैं, खो गए हैं या यदि वे किसी अन्य परियोजना में उपयोग किए जाते हैं, तो अक्सर बड़े सिरदर्द होते हैं, जो उन्हें एक कोड आधार से दूसरे में विलय कर देते हैं (क्योंकि दोनों शाखाएं एक वर्ष के लिए स्वतंत्र रूप से विकसित हो सकती हैं। )।
- एक विकास शाखा में किए गए रिफलेक्टरिंग और कोड सुधार या तो खो जाते हैं या अच्छे से अधिक नुकसान का कारण बनते हैं यदि आपको इन सभी परिवर्तनों को शाखाओं के बीच विलय करना है।
अब हम चर्चा कर रहे हैं कि इन समस्याओं को कैसे हल किया जाए और अब तक निम्नलिखित विचारों के साथ इसे कैसे हल किया जाए:
अलग-अलग शाखाओं में विकास करते रहें, लेकिन केंद्रीय भंडार होने से बेहतर आयोजन होता है जहां सामान्य बग फिक्स को मर्ज कर दिया जाता है और सभी परियोजनाओं को इस केंद्रीय भंडार से एक नियमित (जैसे दैनिक) आधार पर विलय कर दिया जाता है। इसके लिए विशाल अनुशासन और शाखाओं के बीच विलय के लिए बहुत प्रयास की आवश्यकता होती है। इसलिए मुझे यकीन नहीं है कि यह काम करेगा और हम इस अनुशासन को बनाए रख सकते हैं, खासकर जब समय दबाव डालता है।
अलग-अलग विकास शाखाओं का त्याग करें और एक केंद्रीय कोड रिपॉजिटरी है जहां हमारे सभी कोड रहते हैं और प्लगेबल मॉड्यूल और कॉन्फ़िगरेशन विकल्प होने से हमारा अनुकूलन करते हैं। हम अपने कोड में निर्भरता को हल करने के लिए पहले से ही डिपेंडेंसी इंजेक्शन कंटेनरों का उपयोग कर रहे हैं और हम अपने यूआई से व्यापार तर्क को अलग करने के लिए अपने अधिकांश कोड में MVVM पैटर्न का पालन कर रहे हैं।
दूसरा दृष्टिकोण अधिक सुरुचिपूर्ण प्रतीत होता है, लेकिन हमें इस दृष्टिकोण में कई अनसुलझी समस्याएं हैं। उदाहरण के लिए: अपने मॉडल / डेटाबेस में परिवर्तन / परिवर्धन कैसे करें। हम एंटिटी फ्रेमवर्क के साथ .NET का उपयोग कर रहे हैं। मैं यह नहीं देखता कि हम उन संपत्तियों को कैसे संभाल सकते हैं जो एक ग्राहक के लिए आवश्यक हैं, लेकिन हमारे डेटा मॉडल को अव्यवस्थित किए बिना किसी अन्य ग्राहक के लिए बेकार हैं। हम उपग्रह सारणी का उपयोग करके डेटाबेस में इसे हल करने के बारे में सोच रहे हैं (एक अलग तालिका होने पर जहां एक विशेष इकाई के लिए हमारे अतिरिक्त कॉलम मूल इकाई के लिए 1: 1 मैपिंग के साथ रहते हैं), लेकिन यह केवल डेटाबेस है। आप इसे कोड में कैसे संभालेंगे? हमारा डेटा मॉडल एक केंद्रीय पुस्तकालय में रहता है जिसे हम इस दृष्टिकोण का उपयोग करके प्रत्येक ग्राहक के लिए विस्तारित नहीं कर पाएंगे।
मुझे यकीन है कि हम इस समस्या से जूझने वाली एकमात्र टीम नहीं हैं और मैं इस विषय पर इतनी कम सामग्री पाकर हैरान हूं।
तो मेरे सवाल निम्नलिखित हैं:
- आपके पास अत्यधिक अनुकूलित सॉफ़्टवेयर के साथ क्या अनुभव है, आपने क्या दृष्टिकोण चुना और यह आपके लिए कैसे काम किया?
- आप किस दृष्टिकोण की सलाह देते हैं और क्यों? क्या एक बेहतर दृष्टिकोण है?
- क्या इस विषय पर कोई अच्छी किताबें या लेख हैं जिन्हें आप सुझा सकते हैं?
- क्या आपके पास हमारे तकनीकी वातावरण (.NET, Entity Framework, WPF, DI) के लिए विशिष्ट सिफारिशें हैं?
संपादित करें:
सभी सुझावों के लिए शुक्रिया। अधिकांश विचार उन लोगों से मेल खाते हैं जो हमारे पास पहले से ही हमारी टीम में थे, लेकिन यह वास्तव में आपके द्वारा उनके साथ अनुभव करने और उन्हें बेहतर तरीके से लागू करने के लिए युक्तियों को देखने के लिए मददगार है।
मुझे अभी भी यकीन नहीं है कि हम किस रास्ते पर जाएंगे और मैं (अकेले) निर्णय नहीं कर रहा हूं, लेकिन मैं इसे अपनी टीम में पास करूंगा और मुझे यकीन है कि यह मददगार होगा।
फिलहाल टेनर विभिन्न ग्राहक विशिष्ट मॉड्यूल का उपयोग करके एकल रिपॉजिटरी लगता है। मुझे यकीन नहीं है कि हमारी वास्तुकला इस पर निर्भर है या हमें इसे फिट बनाने के लिए कितना निवेश करना है, इसलिए कुछ चीजें कुछ समय के लिए अलग रिपॉजिटरी में रह सकती हैं, लेकिन मुझे लगता है कि यह एकमात्र दीर्घकालिक समाधान है जो काम करेगा।
तो, सभी प्रतिक्रियाओं के लिए फिर से धन्यवाद!