मेरे पास दो उत्तर हैं: हम क्या करते हैं और मैं आपके लिए क्या सुझाव देता हूं।
हमारे लिए, हमारे पास वेब ऐप्स का एक सूट है जिसमें सभी के पास कई साझा घटक हैं। इस प्रकार, हालांकि यह लगभग 50 विभिन्न असेंबली (वीएस प्रोजेक्ट्स) और 5-10 समाधान (आप इसे कैसे देखते हैं इसके आधार पर) हैं, उन सभी में बहुत महत्वपूर्ण ओवरलैप है जिसका अर्थ है कि हम टीएफएस प्रति-देव विलय का उपयोग करना चाहते हैं उन अतिव्यापी संसाधनों को ब्रांचिंग और विलय करने से। इस प्रकार, हम वास्तव में यह सब एक ही टीएफएस परियोजना में रखते हैं। यहाँ है कि कैसे हम हमारे सेटअप (समझ बनाने के लिए बदल गया नाम आपके लिए) है:
"Official Projects" (Collection)
"Production Applications" (Project)
"Technology Proof of Concepts" (Project)
"Reference Projects" (Project) - this is a simple solution/projects using our architecture to make our architecture easier to understand as people join our team. Other reference apps will go here in the future.
"TFS Configuration" (Project)
"Playground" (Collection)
"John Doe" (Project)
"Jane Doe" (Project)
"Security Team" (Project)
"Production Test" (Project)
हमारे सेटअप में, हम आधिकारिक कंपनी कोड के लिए एक जगह है। इसके अलावा, हमारे पास विभिन्न टीएफएस से संबंधित लाभों का लाभ उठाने में सक्षम होने के बावजूद कुछ भी गड़बड़ करने के डर के बिना लोगों को गुमराह करने के लिए एक क्षेत्र है।
हालांकि, आपके परिदृश्य में, यदि मैं सही ढंग से लाइनों के बीच पढ़ रहा हूं, तो मैं कुछ अलग सुझाव दूंगा। मेरे मान्यताओं:
- प्रत्येक परियोजना, एक तरफ कुछ सामान्य विधानसभाओं होने से (मैं प्रवेश, सुरक्षा, और अन्य उपयोगिता विधानसभाओं कि साझा कर रहे हैं कंपनी के व्यापक सोच रहा हूँ), असंबद्ध प्रोजेक्ट कर रहे हैं।
- साझा/आम असेंबली नियमित रूप से नहीं बदला जा रहा है ताकि आप परियोजना संदर्भों के बजाय डीएलएल संदर्भों का उपयोग कर सकें जहां आप हमेशा कोड के नवीनतम अप-टू-मिनट/दिन संस्करण का उपयोग कर रहे हैं।
- (टीएफएस-आधारित धारणा के रूप में मैं अभी भी सीख रहा हूं) आप एक ही संग्रह से परियोजनाओं में शाखा बना सकते हैं लेकिन आप संग्रहों में शाखा नहीं बना सकते हैं।
- उपर्युक्त साझा असेंबली के अलावा, टीमों में कोई अन्य कोड साझा नहीं किया जाता है।
तो इन मान्यताओं के साथ, मैं कुछ इस तरह के साथ जाना होगा:
"Common Resources" (Collection)
"Source" (Project) - everything goes here such as logging assemblies, security assemblies, etc.
"Version 1" (Project) - Branch as you "rev" your common assemblies so people have access to older versions.
"Version 2" (Project)
"Version 3" (Project"
etc.
"Team 1" (Collection)
"Project 1"
"Project 2"
"Project 3"
"Project 4"
"Project 5"
"Team 2" (Collection)
"Project 1"
"Project 2"
"Project 3"
"Team 3" (Collection)
"Project 1"
"Project 2"
etc.
यह इस तरह से कर रहा है, तो आप DLL संदर्भ के माध्यम से आम विधानसभाओं को देखें। जब आप एक आम असेंबली के नए संस्करण का उपयोग करना शुरू करते हैं तो आप एक विशिष्ट परियोजना पर टीम या देव के रूप में निर्णय लेते हैं। ऐसा करने के लिए, आप बस उस संस्करण की शाखा पर नवीनतम प्राप्त करें और फिर इसके लिए एक संदर्भ जोड़ें। अगर मेरी धारणा # 3 गलत है, तो उम्मीद है कि आप इससे बेहतर कुछ कर सकते हैं। अन्यथा, प्रत्येक प्रोजेक्ट में इसकी अपनी जगह होती है (जिसमें केवल एक वीएस समाधान/परियोजना से अधिक हो सकता है जो एक अच्छा विचार है) और आपकी टीम के पास अन्य टीमों के अलावा रहने का अपना संग्रह है।
बस मेरे $ 0.02 मूल्य ...
क्या आप यह इंगित करने के लिए संरचना को अपडेट कर सकते हैं कि आपकी .sln और .csproj फ़ाइलें कहां स्थित हैं? मेरे पास वर्तमान में एक परिदृश्य है जहां हमारे पास प्रति तैनाती योग्य वस्तु (विंडोज सेवा, या वेब अनुप्रयोग) का समाधान है, और इनमें से प्रत्येक समाधान के अंदर परियोजनाओं पर निर्भर हो सकता है (उदाहरण के लिए एक समाधान में एक इंटरफेस प्रोजेक्ट को किसी अन्य समाधान में किसी अन्य प्रोजेक्ट द्वारा संदर्भित किया जा रहा है)। क्या आपका सुझाव इस के लिए पूरा करता है?वर्तमान में हम एक ज्ञात स्थान पर निर्माण करते समय वितरित करने योग्य असेंबली की प्रतिलिपि बनाते हैं, और अन्य परियोजनाओं पर पूर्व-निर्माण जो हम निर्भरताओं में प्रतिलिपि बनाते हैं और प्रतिलिपि का संदर्भ देते हैं। – jamiebarrow