संस्करण नियंत्रण में कोड को कैसे संग्रहीत किया जाना चाहिए?
डेवलपर के अनुकूल ? ताकि प्रोग्रामर जल्दी से नवीनतम और अपने संपादक से कई बदलाव किए बिना चलाने में सक्षम हो सके? (जैसे डीबी को इंगित करने वाली कॉन्फिग फाइल्स
या
यह उत्पादन के अनुकूल होना चाहिए ? स्रोत ऐसे तरीके से होना चाहिए जो उत्पादन वातावरण पर तैनात करना आसान है और जब डेवलपर नवीनतम लेता है, तो उसे अपनी विकास आवश्यकताओं के अनुसार परिवर्तन करना चाहिए।
जवाबों:
क्यों चुना? यह दोनों होना चाहिए।
आपके विकास के वातावरण को कॉन्फ़िगर किया जाना चाहिए ताकि यह एक चेकआउट, ओपन, बिल्ड, रन, डीबग करने के रूप में आसान हो (जैसे: कोई स्थिर पथ!)। आप संकलन निर्देश, विन्यास वर्ग + निर्भरता इंजेक्शन के साथ आसानी से कर सकते हैं, या ASP.NET में perso.config जैसे ट्रिक्स भी कर सकते हैं
विशिष्ट उत्पादन विन्यास, सफाई, पैकेजिंग आदि का ध्यान रखने के लिए आपकी स्वचालित बिल्ड स्क्रिप्ट को पर्याप्त रूप से अनुकूलित किया जाना चाहिए।
जब यह एक ओपन सोर्स प्रोजेक्ट होता है, जहां लोगों से योगदान की उम्मीद की जाती है, तो मैं निश्चित रूप से डेवलपर के अनुकूल होने का विकल्प चुनूंगा।
ओपन सोर्स प्रोजेक्ट्स के बारे में मेरी सबसे बड़ी नापसंद यह है कि बहुत कम ही रिपॉजिटरी में कोड बनाने के लिए आवश्यक सभी निर्भरताएं होती हैं (कभी-कभी व्यावहारिक या कानूनी कारणों के लिए), लेकिन जब वे नहीं करते हैं - तो कुछ आपको यह बताने की जहमत भी नहीं उठाते कि क्या निर्भरताएं हैं आप की जरूरत है, या अधिक महत्वपूर्ण बात, उनमें से जो संस्करण आप की जरूरत है। (और अधिमानतः कहाँ से उन्हें पाने के लिए)
कभी-कभी आप आधे से अधिक दिन बिता सकते हैं और जिस परियोजना के बाद आप हैं उसे बनाने के लिए कई अन्य परियोजनाओं को संकलित कर सकते हैं।
बेशक, यह वास्तव में केवल विंडोज पर विकास के लिए प्रासंगिक है।
दोनों, लेकिन यह इस बात पर निर्भर करता है कि आप कितनी बार अपना उत्पादन करते हैं। कई अनुकूलित आवेदन के लिए, तैनाती मैन्युअल और स्थानीय रूप से की जाती है। दूसरी ओर, डेवलपर लगातार कोड को कम करेगा, चाहे वह परियोजना कितनी भी छोटी या बड़ी हो। मेरी राय में, मुझे लगता है कि यह सुनिश्चित करना अधिक महत्वपूर्ण है कि डेवलपर संस्करण नियंत्रण का सही ढंग से उपयोग कर सकता है, इसलिए उनके जीवन को आसान बना सकता है, इसलिए उनके पास संस्करण नियंत्रण के माध्यम से रास्ता खोजने के बजाय कोड पर ध्यान केंद्रित करने का समय होगा।
यह उत्पादन के अनुकूल होना चाहिए, अन्यथा स्वचालित बिल्ड बनाए रखने के लिए समस्याग्रस्त है।
मैं घर्षण कम करने के लिए हूं, ताकि काम पूरा करना आसान हो, लेकिन आपको विफलता के तरीकों को भी ध्यान में रखना होगा।
यदि स्रोत रिपॉजिटरी संस्करण को हमेशा उत्पादन उपयोग के लिए कॉन्फ़िगर किया जाता है, तो सिस्टम चलाने से पहले एक डेवलपर के परिणाम को फिर से कॉन्फ़िगर करने में विफल क्या होता है? एक डेवलपर उत्पादन के खिलाफ कोड चला रहा है।
भले ही डेवलपर के उत्पादन में यादृच्छिक परिवर्तन करने के तरीके में अन्य बाधाएं हों, एक विफलता मोड में निर्माण जो इसे होने के लिए प्रोत्साहित करता है खतरनाक लगता है।
मेरा सुझाव है कि प्रतिबद्ध कोड में शामिल डिफ़ॉल्ट मान हमेशा सुरक्षित होना चाहिए । स्रोत नियंत्रण में उत्पादन कॉन्फ़िगरेशन फ़ाइलों की भी जांच करें, अगर आपको पसंद है - मैं लगभग हमेशा करता हूं - लेकिन उन्हें कहीं "जीवित नहीं" रखें।
मैं उत्पादन के अनुकूल होने का प्रयास करता हूं। यह आपके बिल्ड को साफ रखता है और बाहरी सेटिंग्स को उत्पादन में बनाने से रोकता है।
निश्चित रूप से डेवलपर के अनुकूल, क्यूए और उत्पादन के लिए परिवर्तनों को स्वचालित करने के लिए स्क्रिप्ट के साथ।
डवलपमेंट कोड के लिए एक ब्रांच (आपके द्वारा उपयोग किए जाने वाले संस्करण पर निर्भर करता है - मैं Git का उपयोग क्यों करता हूं) के आधार पर नहीं है? यह बहुत अच्छा लगता है और सेटअप करने के लिए उतना कठिन नहीं है।
आप काम कर सकते हैं और अपने बदलाव कर सकते हैं और फिर उन्हें तैनाती योग्य संस्करण पर मर्ज कर सकते हैं।