दोनों का उपयोग करना संभव है, मैं अपनी लाइब्रेरी प्रोजेक्ट्स को NuGet पैकेज में परिवर्तित कर रहा हूं और उन्हें एक आंतरिक NuGet फ़ीड पर होस्ट कर रहा हूं। यह बहुत अच्छा काम कर रहा है और डेवलपर्स पर हेलर वर्गों को फिर से बनाने और "पहिया को पुनर्निर्मित करने" पर कटौती कर चुका है। एक और बड़ा प्लस यह है कि अन्य टीमें अब हमारी परियोजनाओं से "रिलीज" पुस्तकालयों का उपभोग कर सकती हैं। असल में यह अब तक एक बड़ी जीत रही है।क्या यह स्थानीय NuGet रिपोजिटरी और रिमोट रिपोजिटरी
एकमात्र समस्या जिसका सामना हम कर रहे हैं वह स्थानीय बनाता है। हम क्या करना चाहते हैं यह NuGet फ़ीड में निर्माण को धक्का देने से पहले हमारी उपभोग करने वाली परियोजनाओं में परीक्षण पुस्तकालय है। हम एक समस्या में भाग रहे हैं क्योंकि इन पुस्तकालयों का उपभोग करने वाली परियोजनाओं को स्थानीय फ़ीड का उपयोग करने के लिए सेटअप किया गया है (बिल्ड सर्वर पर पैकेज पुनर्स्थापना हमारे मुख्य ट्रंक को नवीनतम "रिलीज़" पुस्तकालयों के साथ बनाने की अनुमति देता है)।
स्थानीय भंडार से स्थानीय निर्माण करने का कोई तरीका है? मैंने लाइब्रेरीज़ के लिए निर्माण कार्य के बाद काम करना शुरू कर दिया है जो स्थानीय पैकेज फ़ाइलों को बनाता है। NuGet.config का उपयोग करके मुझे लगता है कि मुझे कुछ रिपॉजिटरीज़ मास्क करने में सक्षम होना चाहिए और फिर बिल्ड सर्वर पर कॉन्फ़िगरेशन फ़ाइलों को मुखौटा करना चाहिए। मेरा सिद्धांत यह है कि स्थानीय निर्माण का उपयोग करते समय स्थानीय भंडार उठाया जाना चाहिए और बिल्ड सर्वर पर फ़ीड का उपयोग किया जाएगा।
क्या यह संभव है? क्या कोई और है जिसने दस्तावेज किया है कि यह कैसे करें?
<PropertyGroup>
<PackOutputDir>$([System.IO.Path]::Combine($(SolutionDir), "..\Prerelease"))</PackOutputDir>
<BuildSpecCommand>$(NuGetCommand) spec $(ProjectFileName) -force -NonInteractive -Verbosity detailed</BuildSpecCommand>
<PackCommand>$(NuGetCommand) pack $(ProjectFileName) -OutputDirectory "$(PackOutputDir)"</PackCommand>
</PropertyGroup>
<Target Name="AfterBuild" Condition=" '$(Configuration)|$(Platform)' == 'Debug|AnyCPU' ">
<Exec Command="$(BuildSpecCommand)" LogStandardErrorAsError="true" Condition=" '$(OS)' == 'Windows_NT' " />
<Exec Command="$(PackCommand)" LogStandardErrorAsError="true" Condition=" '$(OS)' == 'Windows_NT' " />
</Target>
मैं अपनी टीम परियोजना की जड़ में यह NuGet.config रखा:
यहाँ के बाद निर्माण कार्य मैं स्थानीय संकुल बनाने के लिए उपयोग कर रहा हूँ है। इस फ़ाइल का निर्माण सर्वर पर आच्छादित है:
<configuration>
<packageSources>
<add key="NuGet official package source" value="https://nuget.org/api/v2/" />
<add key="LocalNuGetFeed" value="http://team2:12345/nuget" />
</packageSources>
<disabledPackageSources>
</disabledPackageSources>
<activePackageSource>
<add key="All" value="(Aggregate source)" />
</activePackageSource>
</configuration>
अद्यतन:
<configuration>
<packageSources>
<add key="NuGet official package source" value="https://nuget.org/api/v2/" />
<add key="TestSource" value="Source\Prerelease" />
</packageSources>
<disabledPackageSources>
<add key="LocalNuGetFeed" value="LocalNuGetFeed" />
</disabledPackageSources>
<activePackageSource>
<add key="All" value="(Aggregate source)" />
</activePackageSource>
</configuration>
यहाँ NuGet.config कि मैं एक फ़ोल्डर है कि निर्माण सर्वर पर पदानुक्रम में उठाया जाना चाहिए में रखा है एक प्रदत्त उत्तर के आधार पर मैंने nuget.targets फ़ाइल को बदल दिया। आदर्श रूप में मैं ऐसा नहीं करना चाहूंगा, लेकिन अगर मैं इसे पूरा करना चाहता हूं तो यह सबसे अच्छा तरीका है, तो मैं इस प्रकार के संपादन के साथ ठीक हूं।
<ItemGroup Condition=" '$(PackageSources)' == '' And '$Configuration' == 'Release'">
<PackageSource Include="https://nuget.org/api/v2/" />
<PackageSource Include="http://team2:12345/nuget/" />
</ItemGroup>
<ItemGroup Condition=" '$(PackageSources)' == '' And '$Configuration' != 'Release'">
<PackageSource Include="https://nuget.org/api/v2/" />
<PackageSource Include="C:\temp\NuGet\Prerelease" />
</ItemGroup>
विचार यहां निर्माण कार्य पुस्तकालय परियोजनाओं के लिए पहले पोस्ट का उपयोग करने के लिए इतना है कि अपने पैकेजों डिस्क पर एक अस्थायी फ़ोल्डर में उत्पादन हो रहा है। उपर्युक्त कोड उन परियोजनाओं के लिए nuget.targets फ़ाइल में होना चाहिए, जिन्हें डेवलपर्स को स्थानीय मशीनों पर काम करते समय तुरंत लाइब्रेरी अपडेट में कोई बदलाव करने की आवश्यकता होगी, हालांकि बिल्ड सर्वर केवल हमारे स्थानीय फ़ीड से बात करेगा टीम निर्माण प्रक्रिया।
क्या यह सही है?
एक और विचार ... सहकर्मी के साथ चर्चा करने के बाद हम एक और समाधान के साथ आए जो अभ्यास में अधिक प्रभावी हो सकता है। हमने इसे AvalonDock प्रोजेक्ट पर मॉडल करने का निर्णय लिया। जब आप स्रोत डाउनलोड करते हैं और उस प्रोजेक्ट के लिए समाधान खोलते हैं तो आप केवल यूआई नियंत्रण बनाने के लिए कोड नहीं देखते हैं, लेकिन आप एक उदाहरण प्रोजेक्ट भी देखते हैं जो कहा गया नियंत्रण की सभी सुविधाओं का उपयोग करता है।
उनका विचार था कि हमारी लाइब्रेरी परियोजनाओं में जहां कोड केवल सी # पुस्तकालय है कि इकाई परीक्षण किसी भी मुद्दे को कवर करने के लिए पर्याप्त प्रभावी होना चाहिए। यह भी बनाता है कि इन पुस्तकालयों को धक्का दिया जाता है, जिसका अर्थ यह है कि निर्माण (और परीक्षण) पूर्ण होने पर केवल चेकिन लागू होते हैं।
यूआई नियंत्रणों के लिए उन्होंने AvalonDock के उपर्युक्त उदाहरण की ओर इशारा किया। सभी नियंत्रणों का उपयोग करने वाली एक परियोजना सहित अधिकांश मुद्दों को कम करना चाहिए। चूंकि यूआई नियंत्रणों पर यूनिट परीक्षण सीमित है, फिर भी यह कोड को करने और निर्माण प्रक्रिया शुरू करने से पहले परीक्षण परियोजना के भीतर नियंत्रण की जांच करने के लिए डेवलपर पर ऑनस लगाएगा।
इस दृष्टिकोण की सामान्य राय क्या है?
मैंने प्रश्न अपडेट किया और मुझे लगता है कि आप क्या सोच रहे हैं में जोड़ा गया है। कृपया उस पर एक नज़र डालें और मैंने जो अतिरिक्त टिप्पणियां जोड़ दी हैं और मुझे आपकी राय बताएं। –
मैंने देखा है कि आप अभी भी दोनों कॉन्फ़िगरेशन में आधिकारिक न्यूज फ़ीड शामिल करते हैं, इसलिए आपका बिल्ड सर्वर संकुल के लिए nuget.org पर भी देखेंगे। असल में, 'यह सूची में पहला है, यह nuget.org पर और फिर दूसरे पीकेजी स्रोत पर दिखेगा। यकीन नहीं है कि आप क्या चाहते हैं? आप अपने स्थानीय भंडारों पर nuget.org निर्भरताओं की प्रतिलिपि क्यों नहीं बनाते? –
हम लॉग 4नेट जैसे हमारे समाधानों में तीसरे पक्ष की परियोजनाओं का उपयोग करते हैं। मैं उन पैकेजों के लिए nuget भंडार का उपयोग करना चाहता हूँ। इसके साथ मेरा लक्ष्य यह है कि यदि डेवलपर कुछ भी नहीं के साथ कोड खींचता है तो वे निर्भरताओं के किसी भी अतिरिक्त सेटअप के बिना शुरू कर सकते हैं। –