रिलीज के लिए निर्भरताओं के प्रबंधन पर युक्तियाँ?

Question

हमारे सिस्टम में कई .NET वेबसाइटें, कक्षा पुस्तकालय, और एक MSSQL डेटाबेस शामिल हैं। हम स्वचालित रूप से एक टेस्ट सर्वर पर निर्माण करने के लिए स्रोत नियंत्रण और टीमसिटी के लिए एसवीएन का उपयोग करते हैं।

हमारी टीम आम तौर पर एक समय में 4 या 5 परियोजनाओं पर काम कर रही है। हम हर 2-4 सप्ताह में एक बड़े पैमाने पर रोलआउट में कई बदलावों को एक साथ लाने की कोशिश करते हैं।

मेरी समस्या रोलआउट के लिए सभी निर्भरताओं का ट्रैक रखने के साथ है। उदाहरण:

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

यह और भी जटिल हो जाता है - सुनिश्चित करें कि प्रत्येक डेवलपर के प्रोजेक्ट वास्तव में अन्य लोगों के साथ संगत है और एक ही संस्करण के खिलाफ निर्माण कर रहे हैं होने की पुष्टि करने की तरह। हां, यह तकनीकी समस्या जितना अधिक प्रबंधन समस्या है।

वर्तमान में हमारे गैर इष्टतम समाधान है:

• किसी व्हाइटबोर्ड सुविधाओं लिस्टिंग कि अभी तक
• लाइव जब रोलआउट की योजना बना हमारी स्मृति और अंतर्ज्ञान पर भरोसा नहीं गए, जब तक हमें यकीन है कि कर रहे हैं हमने सबकुछ सोचा है ...
• हमारे स्टेजिंग वातावरण पर एक ड्राई-रन। यह एक अच्छा संकेत है, लेकिन हम अक्सर यह सुनिश्चित नहीं करते हैं कि स्टेजिंग लाइव के साथ सिंक में 100% है - समस्या का हिस्सा मैं हल करने की उम्मीद कर रहा हूं।
• रोलआउट दिन पर इसे विंग करने की कुछ मात्रा।

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

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

मुझे इस समस्या का समाधान करने वाली अन्य टीमों से सलाह सुनना अच्छा लगेगा।

Answer 1

ऐसा लगता है कि आपके पास पहले से ही एक Continuos एकीकरण सर्वर है, लेकिन इसका उचित उपयोग न करें। समस्या का एक हिस्सा यह है कि आप नहीं जानते कि कौन से बदलाव रिलीज में खत्म हो जाएंगे और कौन नहीं होगा।

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

आपने उल्लेख किया है कि आपकी टीम लगातार काम कर रही कई परियोजनाएं हैं और उनके पास कुछ परस्पर निर्भरताएं हैं।यह मुझे थोड़ा संदिग्ध बनाता है:

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

मेरे अनुभव में, यह हमेशा द्विआधारी स्तर पर निर्भरता का प्रबंधन करने के (बस अपनी परियोजना में एक पुस्तकालय का उन्नयन) आसान है। दूसरी तरफ, मुझे ऐसी स्थिति कभी नहीं मिली है जहां असंबंधित परियोजनाएं एक ही डीएल पर निर्भर करती हैं (जो स्वयं में एक आवेदन है और केवल उपयोगिता पुस्तकालय या कुछ नहीं)। इस मामले में, स्रोत स्तर पर निर्भरताओं का प्रबंधन करना आसान है।

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