कई समाधानों में टीएफएस और साझा परियोजनाएं

Question

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

- = folder, | = Visual Studio Solution 
-SVN 
    - Internet 
     | Ourcompany.com 
     | Oursecondcompany.com 
    - Intranet 
     | UniformOrdering website 
     | MessageCenter website 
    - Shared 
     | ErrorLoggingModule 
     | RegularExpressionGenerator 
     | Anti-Xss 
     | OrgChartModule etc... 

तो ..

इंटरनेट फ़ोल्डर में OurCompany.com समाधान के लिए एक वेबसाइट के लिए होता है प्रोजेक्ट, और इसमें साझा निर्देशिका से ErrorLoggingModule, RegularExpressionGenerator, और एंटी-एक्सएसएस प्रोजेक्ट भी शामिल होंगे।

इसी तरह, हमारे वर्दी ऑर्डरिंग वेबसाइट समाधान में इन परियोजनाओं में से प्रत्येक समाधान भी शामिल होगा।

हम एक .dll संदर्भ के लिए एक परियोजना संदर्भ करना पसंद करते हैं क्योंकि, सबसे पहले, अगर हमें OurCompany.com वेबसाइट पर काम करते समय ErrorLoggingModule में कोई फ़ंक्शन जोड़ने या ठीक करने की आवश्यकता है, तो यह ठीक है। इसके अलावा, यह हमें प्रत्येक समाधान का निर्माण करने और देखने के लिए अनुमति देता है कि साझा कोड में परिवर्तन किसी अन्य एप्लिकेशन को तोड़ते हैं या नहीं। यह एक बिल्ड सर्वर पर अच्छी तरह से काम करना चाहिए, साथ ही अगर मैं सही हूं।

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

अब, हालांकि, हमें वास्तव में हमारी विकास प्रक्रियाओं को ठीक करने का सामना करना पड़ रहा है, और टीएफएस का एप्लीकेशन लाइफसाइक्ल मैनेजमेंट बिल्कुल वही है जो हम चाहते हैं, और हम कैसे काम करना चाहते हैं। हमारा एक चिपकने वाला बिंदु साझा कोड मुद्दा है।

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

क्या किसी और का सामना करना पड़ा है और समाधान के साथ आया है?

यदि आपने कोई लेख देखा है या इस पर पोस्ट किया है कि आप मेरे साथ साझा कर सकते हैं, तो इससे भी मदद मिलेगी।

हमेशा की तरह, मैं की तरह "आप इसे देख रहे हैं जवाब के लिए खुला रहा हूँ सब गलत, कपाल, यहाँ जिस तरह से यह किया जाना चाहिए।

Answer 1

मुझे लगता है कि यहाँ कुछ गलतफहमी नहीं है। सबसे पहले, आप कर सकते हैं एक ही टीएफएस प्रोजेक्ट में कई (जितना चाहें) समाधान। इसके अलावा, एक एकल विजुअल स्टूडियो प्रोजेक्ट में इसका कोई समाधान हो सकता है।

दूसरा, आप किस टीएफएस का उपयोग कर रहे हैं? 2010 से अलग है 2005/08 में यह टीएफएस परियोजनाओं को कैसे संभालता है।

2008 के तहत, आप जो चाहते हैं उसके आधार पर इस दृष्टिकोण के कई तरीके हैं इससे बाहर निकल जाओ। आप या तो कई टीएफएस परियोजनाएं या एक टीएफएस परियोजना कर सकते हैं।

मैं एकाधिक से शुरू करूंगा।

आपके साझा लाइब्रेरी प्रकार कोड के लिए एक टीएफएस प्रोजेक्ट सेट करें, और आपके पास प्रत्येक नियमित परियोजना के लिए अन्य। इस साझा लाइब्रेरी पर विकास प्रक्रिया के हिस्से के रूप में, पूर्ण असेंबली में जांचें। फिर उन असेंबली को किसी अन्य टीएफएस प्रोजेक्ट में ब्रांच करें, जिसे आप इनका उपयोग करना चाहते हैं। जब आप साझा लाइब्रेरी में फीचर अपडेट या बग फिक्स करते हैं, तो बस शाखा को किसी भी अन्य टीएफएस प्रोजेक्ट में मर्ज करें जिसे आप अपडेट करना चाहते हैं।

यह आपको उन सभी को धक्का दिए बिना एक ऐप के लिए साझा परिवर्तन करने की अनुमति देता है।

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

Answer 2

केवल उम्मीद में यह रिकॉर्डिंग कि यह किसी और दिन की मदद करता है, मुझे डर है कि मैं आपके मूल प्रश्न का उत्तर देने में बहुत देर हो चुकी हूं;) हमारे पास एक समान स्थिति है, और आपका प्रश्न (और बाद के उत्तरों) टीएफएस को ठीक से स्थापित करने के लिए हमारे लिए बहुत आसान बना दिया।

अपने उदाहरण का उपयोग करने के हमारे सेटअप व्याख्या करने के लिए:

# = Project Collection, > = Team Project, | = VS project 
# SVN 
    > Internet 
     | OurCompany 
     | OurCompany2 
    > Intranet 
     | UniformOrdering 
     | MessageCentre 
    > Shared 
     | ErrorLogging 
     | RegularExpression 

इसका मतलब यह है कि काम टीम परियोजनाओं (जो हमारे मामले में सास क्षुधा कर रहे हैं) में से किसी को (शेयरप्वाइंट में स्क्रम टेम्पलेट का उपयोग कर) सौंपा जा सकता है और डेवलपर नौकरी पाने के लिए किसी भी या सभी वीएस परियोजनाओं को खोलने का विकल्प चुन सकता है।

वरिष्ठ डेवलपर्स (जो कि कई उत्पादों में हैं) के बहुमत में एक वीएस समाधान (शायद "व्हाल एन्टरिप्रिप एसएलएन" समानता जारी रखने के लिए) है जिसमें सभी अलग-अलग वीएस प्रोजेक्ट शामिल हैं और इसलिए किसी भी/सभी पर काम कर सकते हैं उन्हें किसी भी समय। हम यह भी सुनिश्चित कर सकते हैं कि परियोजनाएं ठीक तरह से निर्माण करें, और अपडेट को धक्का देने से पहले सभी निर्भरता अद्यतित हैं।

आपकी ऑपरेटिंग सिस्टम में इसकी संरचना पूरी तरह से आपके ऊपर है! हम में से कुछ ने टीएफएस की संरचना को दोहराया है, दूसरों के पास पूरी तरह से सपाट पदानुक्रम है ... यह दिन के अंत में कोई फर्क नहीं पड़ता है।