टीम विकास के साथ NuGet का उचित तरीके से उपयोग कैसे करें?

Question

तो मैं अपनी टीम के एक विशिष्ट प्रोजेक्ट के लिए उपयोग की जाने वाली विभिन्न परियोजनाओं का प्रबंधन करने के लिए NuGet का उपयोग करना चाहता हूं और मैं काम कर रहा हूं। इस बिंदु तक, मैंने अपने वेब समाधान (एएसपी.नेट एमवीसी 2) की/स्क्रिप्ट निर्देशिका में मेरी .js लाइब्रेरी फ़ाइलों को रखा है और उनको संदर्भित किया है। बेशक, यह मैनुअल था और अपग्रेड के दौरान प्रबंधन करने के लिए परेशान था।

अब जब मैं NuGet का उपयोग कर रहा हूं, मुझे एहसास है कि NuGet का पूरा लक्ष्य यह काफी दर्द रहित बनाना है। इसके अलावा, ऐसा प्रतीत होता है कि मुझे अपने पैकेज को मेरे भंडार में जांचना नहीं चाहिए (AKA मुझे अब मेरे बाहरी पुस्तकालयों को प्रबंधित करने की आवश्यकता नहीं है)। हालांकि, जब मैं NuGet से jQuery (उदाहरण के लिए) को पकड़ता हूं, तो यह मेरी विशिष्ट फ़ाइलों को मेरी प्रोजेक्ट की/स्क्रिप्ट निर्देशिका में रखता है।

जहां मैं भ्रमित हो जाता हूं - क्या, यदि कुछ भी है, तो मुझे इस बिंदु पर स्रोत नियंत्रण में जांच करनी चाहिए? क्या मैं अभी भी/स्क्रिप्ट निर्देशिका में जांच करता हूं?

इसके अलावा, अगर कोई और इस परियोजना पर काम कर रहा है और स्रोत नियंत्रण से समाधान की जांच करता है, तो क्या पैकेज स्वचालित रूप से डाउनलोड होते हैं (मानते हैं कि समाधान वैध संकुल.कॉन्फिग के साथ आता है)?

मैं NuGet पूर्ण-समय का उपयोग शुरू करने से पहले कुछ बिंदुओं को स्पष्ट करने की कोशिश कर रहा हूं।

Answer 1

NuGet बनाम वीसीएस के लिए दो परिदृश्य हैं: चेक-इन करने के लिए या चेक-इन करने के लिए, यह सवाल है। दोनों मेरी राय में मान्य हैं, लेकिन टीएफएस का उपयोग वीसीएस के रूप में करते समय, मैं निश्चित रूप से no-checkin policy for NuGet packages के लिए जाऊंगा।

कहा जा रहा है कि, NuGet संकुल के लिए नो-चेकइन नीति का उपयोग करते समय भी, मैं अभी भी सामग्री परिवर्तनों की जांच करूँगा कि उन NuGet पैकेजों ने मेरी परियोजनाओं के साथ किया है। \Scripts फ़ोल्डर को पूरी तरह से चेक-इन किया जाएगा (चुनिंदा नहीं, अनदेखा नहीं किया गया)।

मेरे लिए पैकेज के लिए नो-चेकइन नीति का अर्थ है: \Packages\repositories.config फ़ाइल को छोड़कर, \ Packages फ़ोल्डर (cloak it, इसे अनदेखा करें) में जांच न करें।

इस प्रकार, आप प्रभावी रूप से NuGet पैकेज नहीं कर रहे हैं, और NuGetPowerTools से Enable-PackageRestore का उपयोग करते समय (यह NuGet v1 में अंतर्निहित होगा।6 बस कोने के आसपास), कोई भी मशीन जो कोड और बिल्ड की जांच करती है, प्री-बिल्ड चरण में सभी आवश्यक NuGet निर्भरताओं को लाएगी। यह स्थानीय समाधान मशीनों के लिए दोनों के लिए सच है, क्योंकि आपके समाधान में Enable-PackageRestore सक्षम है और सही NuGet रिपॉजिटरीज़ (स्थानीय, आंतरिक, बाहरी) को इंगित करता है।

यदि आप इसके बारे में सोचते हैं, तो एक NuGet पैकेज स्थापित करते समय केवल कुछ बाइनरी के संदर्भ जोड़ते हैं, तो आप पहले से ही नो-चेकइन परिदृश्य में समेकन कर रहे होंगे: आप \Packages फ़ोल्डर के उपफोल्डर्स को प्रतिबद्ध नहीं करेंगे, लेकिन फिर भी, आप परियोजना परिवर्तन (जोड़ा संदर्भ) प्रतिबद्ध करेंगे।

मैं कहूंगा, लगातार (किसी भी प्रकार के पैकेज के लिए) हो, चाहे इसमें केवल बाइनरी हों, सामग्री केवल, या मिश्रण हो। Do not commit the packages themselves, अपने स्रोतों में परिवर्तन करें। (अगर केवल सामग्री को बदलने के लिए परेशानी से बचने के लिए)

Answer 2

NuGet, जैसे Nexus, आर्टिफैक्ट रिपोजिटरी (आर्टिफैक्ट किसी भी प्रकार का वितरण योग्य है, संभावित रूप से बड़ी बाइनरी सहित)।

पक्ष प्रभाव है कि आप एक VCS (संस्करण नियंत्रण प्रणाली) तत्व है कि में दुकान नहीं करने के लिए:

• VCS विशेषताएं (, शाखाओं में विलय) से लाभ नहीं होता
• काफी बढ़ जाएगी (कोई डेल्टा या कमजोर डेल्टा भंडारण) VCS भंडार के आकार
• एक VCS रिपोजिटरी से दूर करने के लिए

( लिए मुख्य रूप से तैयार किया गया है रखने इतिहास) काफी मुश्किल होगा

लेकिन लक्ष्य है आप करने के लिए आपको क्या चाहिए घोषित (और NuGet यह तुम्हारे लिए लाने जाने) के लिए के बजाय भंडारण यह अपने आप को।
तो आप प्लेसहोल्डर के रूप में संस्करण /Scripts कर सकते हैं, लेकिन अब आपको इसकी किसी भी सामग्री को स्वचालित रूप से प्राप्त करने के लिए अब और आवश्यकता नहीं है।