2011-09-30 13 views
14

मैं टीएफएस 2010 का उपयोग कर रहा हूं। वर्तमान में मैं केवल गंदे चेक-इन का उपयोग ट्रंक (MAIN) शाखा पर बनाता हूं। और, मैं डीई और रिलीज शाखाओं पर सीआई का उपयोग करता हूं।गेटेड चेक-इन का उपयोग कब करें?

  • क्यों सभी शाखाओं पर गेटेड चेक-इन निर्माण का उपयोग नहीं करते?
  • किन परिदृश्यों में, आपको DEV और RELEASE शाखाओं पर गेटेड चेक-इन निर्माण का उपयोग नहीं करना चाहिए?
  • क्या हर शाखा पर हमेशा गेटेड चेक-इन बिल्ड का उपयोग करना बेहतर होता है?
+0

क्या आप अपने शब्दों में व्याख्या कर सकते हैं, एक ट्रिगर निर्मित के बीच का अंतर और निरंतर इंटिग्रेशन कर सकते हैं? – kroonwijk

+0

क्रूनविज्क; मैंने अपना प्रश्न सही किया। यह गेटेड चेक-इन कहना चाहिए, ट्रिगर नहीं। –

+0

धन्यवाद! अब यह स्पष्ट है। – kroonwijk

उत्तर

9

हमारी बहुत बड़ी टीम में, हम देव/फीचर शाखाओं (उनमें से कई) में मुख्य शाखा और सीआई में भी गेट करते हैं।

गेटेड शाखा के लिए अधिक सुरक्षा प्रदान करता है लेकिन एक बहुत बड़ी टीम और बड़े कोड बेस के साथ, अगर वह पूरी शाखा टीम उस शाखा में बदलाव कर रही है तो यह कतार का बैक अप ले सकती है।

सीआई डेवलपर्स में थोड़ा और विश्वास के साथ सुरक्षा प्रदान करता है यह भी जानकर कि किसी भी मुद्दे को जल्दी से पकड़ा जाएगा। यह थोड़ा अधिक आशावादी है और टीम को देव शाखा के लिए उपयुक्त तेज़ी से आगे बढ़ने की अनुमति देता है।

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

पूरी टीम चक्र के बहुमत के लिए सीआई का उपयोग करके फीचर/देव शाखाओं में है और अंत में स्थिरीकरण के दौरान कई लोगों के साथ उच्च शाखाओं में है - उन दोनों स्थितियों में गेटेड के मामले का समर्थन किया जाता है।

एक बड़ी टीम में, हमें सीआई बिल्ड और रोलिंग परीक्षणों को समानांतर में करने के लिए समानांतर में किया जाना चाहिए, जब समय कम नहीं होता है और पूर्ण परीक्षण सूट भी तुच्छ नहीं होते हैं। उस परिदृश्य में, लोग जांच कर रहे हैं, सीआई चेकइन के आखिरी बैच को उठा रहा है, एक बिल्ड चला रहा है और जब कोई बिल्ड दूसरी मशीन छोड़ देता है तो टेस्ट सूट उठा रहा है और चल रहा है।

+0

यह वही है जो हम करते हैं। –

+0

यदि गेटेड कतार बैक अप ले रहे हैं, तो ऐसा लगता है कि टीम को सबमिशन विलय करने से फायदा होगा। मानते हैं कि अधिकतर बदलावों को खारिज नहीं किया जा रहा है, एक समय में 2 या अधिक परिवर्तनों को मान्य करने से कतार प्रतीक्षा समय कम हो सकता है। –

4

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

निरंतर एकीकरण (रोलिंग बिल्ड के रूप में अनुकूलित मेरी राय में) डेवलपर को अनिश्चितता के बिना अपने कोड को चेक-इन करने की अनुमति देता है यदि यह स्वीकार किया जाएगा या नहीं। महत्वपूर्ण यह है कि देव को हमेशा चेक-इन के नकारात्मक अंत परिणामों के साथ जल्द से जल्द सामना करना पड़ेगा। यदि आप इसे प्राप्त कर सकते हैं, तो मुझे गेटेड चेक-इन से बेहतर पसंद है।

+2

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

3

मैं गेटेड चेक-इन को हर जगह पसंद करता हूं क्योंकि यह पूरी टीम के साथ उस दर्द को साझा करने के बजाय डेवलपर चेक-इन में दर्द को सीमित करता है जब कोई (अनिवार्य रूप से) गलती करता है।

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

+1

मुझे यकीन नहीं है कि समस्या हल हो जाती है। मेरे काम पर एक पूर्ण निर्माण + सभी परीक्षण नए हार्डवेयर पर 24 घंटे लगते हैं। हमारे पास धूम्रपान परीक्षण हैं जो हम लगभग 30 मिनट में चला सकते हैं लेकिन समस्या यह है कि स्वाभाविक रूप से अधिक गहन या केवल विरासत में अधिक समय लेने वाले परीक्षण (जैसे परीक्षण कि आप डेटाबेस के एक संस्करण से दूसरे डेटा में सफलतापूर्वक माइग्रेट कर सकते हैं) बहुत सारे डेटा प्राप्त करते हैं) "लंबी" श्रेणी में धक्का दिया। अक्सर धूम्रपान कुछ भी नहीं पकड़ेगा तो सीआई "लंबी" श्रेणी चलाएगा और एक दर्जन परीक्षण विफल हो जाएंगे। तब तक समीक्षक ने कोड को पहले से ही मंजूरी दे दी है और किसी भी दर पर बाकी टीम को चोट पहुंच गई है – Mike

संबंधित मुद्दे