टीम फाउंडेशन सर्वर स्रोत नियंत्रण संरचना

Question

मैं नए साल के लिए हमारे टीम फाउंडेशन सर्वर रोलआउट के लिए स्रोत नियंत्रण संरचना को मानकीकृत करने पर काम कर रहा हूं। मैंने कोडप्लेक्स पर उपलब्ध Microsoft Team Foundation Server Branching Guidance दस्तावेज़ों का उपयोग करके शुरू किया है।

मैं प्रस्तावित संरचना के बारे में कुछ विशिष्ट प्रश्नों के कुछ प्रतिक्रिया और उत्तर प्राप्त करने की उम्मीद कर रहा था। जब टीएफएस में स्रोत नियंत्रण की संरचना की बात आती है, तो मैंने सीखा है कि चुनने के लिए बहुत सारे "मानक" हैं कि वास्तव में मानक नहीं है।

सबसे पहले, मैं निर्णय और उपयोग की रूपरेखा और वर्णन करूंगा।

$/             
    {Team Project}/        
     {Subproject}/        
      Development/       
       Trunk/        
        Source/ 
        Tests/ 
        Sandcastle/ 
        TeamBuildTypes/ 
         {Build Name}/ 
       Branches/ 
        {Branch Name}/ 
         Source/ 
         Tests/ 
         Sandcastle/ 
         TeamBuildTypes/ 
          {Build Name}/ 

      Integration/ 
       Source/ 
       Tests/ 
       Sandcastle/ 
       TeamBuildTypes/ 
        {Build Name}/ 
      Production/ 
       Releases/ 
        {Release Version}/ 
         Source/ 
         Tests/ 
         Sandcastle/ 
         TeamBuildTypes/ 
          {Build Name}/ 
       Branches/ 
        {Branch Name}/ 
         Source/ 
         Tests/ 
         Sandcastle/ 
         TeamBuildTypes/ 
          {Build Name}/ 

सामान्य तर्क है कि एक टीम परियोजना एक उत्पाद या उपकरण सूट के रूप में या तो एक तार्किक परियोजना (जहां कोई {Subproject} प्रवेश होगा) या अनेक संबंधित परियोजनाओं को शामिल कर सकते हैं। तीन प्रमुख कंटेनर को Development, Integration, और Production कहा जाता है।

Development कंटेनर ट्रंक के भीतर, Source फ़ोल्डर में उत्पाद बनाने वाले दोनों परियोजनाओं के प्रावधान हैं, Tests फ़ोल्डर में उपलब्ध यूनिट परीक्षणों के साथ। Trunk फ़ोल्डर के भाई Branches फ़ोल्डर के माध्यम से शाखाकरण कंटेनर के रूप में कार्य करता है, जो शाखाओं के साथ ट्रंक में बहुमत का विकास होगा। एक या अधिक समाधान फाइलें Trunk के भीतर रहेंगी, जिससे उस स्तर की शाखाओं को समाधान, स्रोत और यूनिट परीक्षणों को कैप्चर करने की अनुमति मिल जाएगी।

Integration कंटेनर जिसे अक्सर गैर-टीएफएस कार्यान्वयन में "मुख्य" कहा जाता है, का उपयोग स्थिर और टेस्टेबल बिल्ड बनाने के लिए Development से परिवर्तनों को एकीकृत करने के लिए किया जाता है। एक बार टेस्ट करने योग्य उत्पाद प्राप्त होने के बाद इसे Development कंटेनर से शाखा के रूप में बनाया गया है। इस कंटेनर से निर्मित हमारे परीक्षण पर्यावरण और लोड परीक्षण पर्यावरण के लिए उपयोग किया जाएगा। हम टेस्टेबल बिल्डों के साथ लोड परीक्षण को शामिल करना चुनते हैं ताकि हम प्रदर्शन में बदलावों की निगरानी कर सकें, जो किसी भी अनियमितताओं में योगदान देने वाले परिवर्तनों को तेज़ी से अलग करने में सक्षम हो।

Production का उपयोग प्री-प्रोडक्शन और उत्पादन गुणवत्ता के निर्माण के लिए किया जाता है। रिलीज के लिए एक स्थिर निर्माण की सिफारिश की जाने के बाद इसे शुरुआत में Integration कंटेनर से शाखा के रूप में बनाया गया है। Releases फ़ोल्डर के भीतर, "रिलीज द्वारा शाखा" संरचना का पालन किया जाता है, जो एक ही स्थान पर स्नैपशॉटिंग और अलगाव प्रदान करता है। (उदाहरण के लिए, Release 1.1 प्री-प्रोडक्शन बिल्ड के लिए तैयार है, स्थिर Integration कंटेनर फ़ोल्डर में Production/Releases संरचना में ब्रांच किया गया है। बाद में आरसी और आरटीडब्ल्यू/आरटीएम को इस फ़ोल्डर में भी बढ़ावा दिया जाता है।) एक शाखा संरचना जैसा कि Branches कंटेनर में देखा गया है भी मौजूद है। यह "हॉटफिक्स" के लिए अनुमति देता है, आमतौर पर एक संशोधन मार्कर (Major.Minor.Revision)। शाखा को वर्तमान रिलीज से बनाया गया है और नए संशोधन मार्कर में वापस विलय किया गया है - जैसे Release 1.1.1। स्वीकृति पर चेंजसेट Development कंटेनर Trunk पर एकीकृत किया जाएगा।

हमें लगता है कि यह संरचना मजबूती और जटिलता के बीच एक उचित संतुलन है। लेकिन कुछ परेशान सवाल हैं कि मैं मॉडल में तर्कसंगत रूप से फिट नहीं हो सकता। वे हैं:

टीम का निर्माण - Development और Integration कंटेनर शुरू में बाहर शुरू कर देंगे के रूप में किया जा रहा है हर रात को, बनाता है अंत में सतत एकीकरण (सीआई) करने के लिए घूम रहा है।उत्पादन कंटेनर मैन्युअल रूप से बनाया जाएगा।

• निर्माण परिभाषा कहां रहनी चाहिए?संपादित करें - कुछ प्रतिक्रियाओं के आधार पर, TeamBuildTypes फ़ोल्डर को ट्रंक में ले जाया गया है और उपयुक्त कंटेनर में ब्रांच किया गया है। हालांकि, यह एक नया प्रश्न (निम्न) का कारण बनता है।

• टीमबिल्ड टाइप्स फ़ोल्डर को उनके उचित कंटेनर में रखते हुए, क्या इसका मतलब यह है कि सभी बिल्ड परिभाषा उचित फ़ोल्डरों के बीच पुन: उत्पन्न की जाएगी? उदाहरण के लिए, विकास की गुणवत्ता के निर्माण के साथ-साथ टेस्टेबल बिल्ड इत्यादि के लिए एक बिल्ड परिभाषा भी है, जो सभी संरचनाओं में सभी टीमबिल्ड टाइप फ़ोल्डर्स में रहती हैं।

प्रलेखन पीढ़ी - हम सैंडकैसल का उपयोग प्रलेखन उत्पन्न करने के लिए। विशेष रूप से, हम आउटपुट प्रबंधित करने के लिए Sandcastle Help File Builder का भी उपयोग करते हैं। यह एसएफएचबी के लिए विशिष्ट प्रारूप में एक प्रोजेक्ट फ़ाइल बनाता है।

• क्या जनरेटिंग स्रोत नियंत्रण संरचना में संग्रहीत किया जाना चाहिए?

• प्रत्येक कंटेनर के लिए दस्तावेज तैयार किए जाने चाहिए, या क्या यह केवल पूर्व-उत्पादन और उत्पादन गुणवत्ता के निर्माण के लिए मूल्य रखता है?

• तेजी से स्थानीय निर्माण के समय को संरक्षित करने के लिए, दस्तावेज़ीकरण निर्माण को बिल्ड परिभाषा के स्वामित्व में होना चाहिए?

• एसएचएफबी-विशिष्ट फाइलें कहां रहेंगी? मेरा प्रारंभिक स्याही इसे Source और Tests फ़ोल्डर में एक सहकर्मी के रूप में रखना है।मैं सिफारिशों से सहमत हूं कि यह Source और Tests पर एक सहकर्मी होगा। इस परिवर्तन को दर्शाने के लिए चित्र बदल गया।

तीसरी पार्टी बाइनरी

• बाइनरी (नियंत्रण, पुस्तकालयों, आदि) स्रोत नियंत्रण में संग्रहित किया जाना चाहिए?

• यदि हां, तो क्या यह स्वयं की टीम परियोजना होनी चाहिए?

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

---

मैं संरचना को अद्यतन कर दूंगा क्योंकि मुझे एक स्पष्ट तस्वीर प्रदान करने के लिए प्रश्नों के उत्तर मिलते हैं। मैं संभावित परिवर्तनों से संबंधित किसी अन्य टिप्पणी का भी स्वागत करता हूं। यदि मेरे कोई अन्य प्रश्न हैं, तो मैं इस पोस्ट को संशोधित करना सुनिश्चित कर दूंगा।

संपादन:

• स्पष्टीकरण। Source और Tests फ़ोल्डर्स Integration कंटेनर के साथ भी रहते हैं।

• दोनों मीका और जोश ने तृतीय पक्ष द्विआधारी के संबंध में महान अंक लाए। इस मुद्दे के बारे में प्रश्न जोड़ा गया।

• दस्तावेज़ीकरण उत्पादन धीमा हो सकता है। इस बारे में प्रश्न जोड़ा गया है कि दस्तावेज निर्माण का एक विशिष्ट टीम बिल्ड प्रकार के स्वामित्व में होना चाहिए या नहीं।

• जोड़ा गैर उत्पन्न प्रलेखन से संबंधित संकल्प, ऐसी जरूरतों, डिजाइन दस्तावेजों, परीक्षण योजना, आदि

• जोड़ा गया निर्माण defintions के लिए TeamBuildTypes फ़ोल्डर से संबंधित संकल्प के रूप में।

• विभिन्न प्रतिक्रियाओं के आधार पर, TeamBuildTypes फ़ोल्डर को ट्रंक/शाखा स्तर पर ले जाया गया।

Answer 1

मुझे स्रोत और टेस्ट में एक सहकर्मी के रूप में Sandcastle फ़ाइलों को डालने का आपका विचार पसंद है, तो मैं एक दस्तावेज़ फ़ोल्डर जोड़ूंगा, जिसमें तब sandcastle फ़ाइलें, और वैकल्पिक रूप से वास्तविक दस्तावेज़ शामिल होंगे।

निश्चित रूप से राय के मतभेद हैं और मुझे यकीन है कि इसके लिए मुझे डाउनवॉट किया जाएगा (क्योंकि मैं पहले से ही हूं)।मैं कारणों की एक जोड़ी के लिए TFS में उत्पन्न प्रलेखन डाल होगा:

1. आपका प्रत्येक रिलीज के साथ अपने दस्तावेज़ चाहते हैं के लिए जा रहा है, और TFS का उपयोग कर यह सुनिश्चित करने के अपने दस्तावेज़ सही जगह में रहता है एक आसान aproach है।
2. स्टोर करने के लिए टीएफएस का उपयोग करना मतलब है कि सभी को पता चलेगा कि दस्तावेज कहां जाना है।

एक बात मैं नहीं दिख रहा है जो मैं हमेशा के साथ संघर्ष तीसरे पक्ष dependancies के लिए जहां है, यह हो सकता है कि वे स्रोत के तहत नीचे हैं ताकि वे एक परियोजना के साथ रहे हैं, हालांकि यदि आप उन्हें परियोजनाओं करवाते साझा करना चाहते थे आप एक नया शीर्ष स्तर नोड जोड़ सकते हैं।

संपादित

मेरी बाइनरी मैं आमतौर पर अंत के लिए

$/Thirdparty/कंपनी/उत्पाद/संस्करण/एसआरसी (वैकल्पिक)

इसलिए उदाहरण के लिए मेरे पास है

$/थर्डपार्टी/ माइक्रोसॉफ्ट/ एंटीलिब/ 3.1 4.0 घटक आर्ट/ वेबयूआई/ 2008.1/ एसआरसी

मैं स्रोत जोड़ना चाहते, मैं सीए के स्रोत है जो मैं करना चाहता हूँ नफरत, लेकिन जब एक तीसरी पार्टी बग को ठीक नहीं करता है तो आप इस का सहारा लेना है पैच करने के लिए किया है।

Answer 2

ग्रेट लेआउट और स्पष्टीकरण। मैंने एक ही मुद्दे के साथ संघर्ष किया है। मैं एक बहुत ही समान संरचना के साथ घायल हो गया है। मेरा थोड़ा बदलता है।

Development/ 
    Trunk/ 
     Binaries/ -- Shared libraries 
     Source/ 
     Test/ 
     Docs/  -- Documentation 
TeamBuildTypes/ -- Build definitions 

• बाइनरी फ़ोल्डर जोड़ने से आप शाखा जहां अपने सभी परियोजनाओं साझा पुस्तकालयों
• संदर्भित कर सकते हैं तो यह साथ यात्रा कर सकते हैं यह विशेष शाखा के साथ हम यहाँ प्रलेखन डाल में एक स्थान की अनुमति देता है।
• हमारी बिल्ड परिभाषा विकास स्तर पर हैं क्योंकि हम उन्हें सभी शाखाओं के लिए एक स्थान पर पहचान सकते हैं, लेकिन यह निश्चित रूप से शाखा स्तर पर हो सकता है जो अधिक समझ में आ सकता है।

बाइनरी (नियंत्रण, पुस्तकालयों, आदि) स्रोत नियंत्रण में संग्रहित किया जाना चाहिए? यदि हां, तो क्या यह अपनी टीम परियोजना होनी चाहिए?

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

Answer 3

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

इसके अलावा एक नए और अधिक परिदृश्य विशिष्ट गाइड सिर्फ http://www.codeplex.com/TFSBranchingGuideII

Answer 4

के साथ-साथ प्रकाशित किया गया था आप अपने ट्रंक के तहत अपने TeamBuilds फ़ोल्डर रखना चाहिए। यह TFS2005 में असंभव था लेकिन माइक्रोसॉफ्ट ने इसे 2008 के लिए तय किया ...

इसका कारण यह है कि आपका निर्माण नए संस्करण (उदाहरण के लिए: नई पैकेजिंग योजनाएं, विभिन्न परीक्षण इत्यादि) के साथ बदल सकता है जो इसे असंगत बना सकता है पुराने रखरखाव रिलीज। यह बात है कि टीम को कोड के संस्करण के साथ टीम को क्यों जोड़ा जाना चाहिए।

इस तरह, मान लें कि आप 1.0 संस्करण जारी करते हैं और इसे रिलीज़ फ़ोल्डर के नीचे डाल देते हैं। आप अपने विकास ट्रंक में v2.0 पर काम करते समय इसे बनाने और पैच जारी करने में सक्षम होंगे (

Answer 5

अपनी बाइनरी के लिए - स्पष्ट रूप से केवल बाइनरी जो संस्करण नियंत्रण में होनी चाहिए "तीसरा -party "विधानसभाएं कि आप किसी भी स्वचालित निर्माण के हिस्से के रूप में" इमारत "नहीं कर रहे हैं। यदि आपके पास अपनी खुद की पुस्तकालय हैं जिनके पास संस्करण नियंत्रण आदि के तहत आपका स्रोत है - आपको

पर मैं उन्हें जोश की तरह व्यवस्थित करता हूं - और फिर बाइनरी को "कॉपी" करने के लिए शाखाकरण का उपयोग करना चाहिए एक _ExternalReferences फ़ोल्डर जो समाधान पेड़ के भीतर .NET प्रोजेक्ट फ़ोल्डर में एक सहकर्मी है। यह एक बहुत ही प्रभावी तरीका सर्वर पक्ष है क्योंकि टीएफएस संस्करण नियंत्रण केवल "डेल्टास" स्टोर करता है - इसलिए अनिवार्य रूप से कई परियोजनाओं में उन बाइनरी के "डुप्लिकेशंस" अनिवार्य रूप से "पॉइंटर" की तरह होते हैं।