हम टीमसिटी और गिटहब एंटरप्राइज़ का उपयोग करते हैं। हम Git के साथ एक खुला स्रोत-esque कार्यप्रवाह का उपयोग करें: वहाँ प्रत्येक घटक के लिए एक mainline भंडार है, और जब लोगों को परिवर्तन करना चाहते हैं, वेमैं स्रोत-कोड एकीकरण के लिए गिटहब पुल-अनुरोध मॉडल का समर्थन करने के लिए टीमसिटी को कैसे कॉन्फ़िगर करूँगा?
- कांटा
mainlineअपने स्वयं के खाते में (ताकि वहाँ कई कांटे हो सकता है) - उनके कांटा में एक शाखा बनाने
- परिवर्तन
- परिवर्तन है कि इस बीच
- में हुआ है
mainline/masterसाथ तारीख तक लाने के लागूfork/feature-branchका एक पुल अनुरोध सबमिट -> +०१२३४३११८६१
हम इस वर्कफ़्लो से बहुत खुश हैं; यह एक कोड-समीक्षा (अच्छी तरह से, कम से कम एक मैन्युअल चरण को मजबूर करता है, जो उम्मीद है कि में वास्तव में कोड पढ़ रहा है और इसके परीक्षण चला रहा है) मेनलाइन से पहले कोई बदलाव दिखाई देता है, जो ऐतिहासिक रूप से एक समस्या है। अगर हम पुल-अनुरोध को देख रहे व्यक्ति हैं, तो मर्ज बटन गैर-हरे रंग को बदलने के लिए हम जीएच स्टेटस एपीआई (blog post, API doc) का उपयोग करना चाहते हैं, लेकिन बाद में यह है।
हमारे पास मुख्य श्रेणी भंडार देखने और परिवर्तनों को देखने पर निर्माण करने के लिए टीमसिटी 7.1 स्थापित है। हालांकि, जिस तरह से यह वर्तमान में स्थापित है, सीआई केवल तभी बनाता है जब यह mainline/master में परिवर्तन देखता है।
हमें टीमसीटी में हमारी वीसीएस जड़ों को कैसे कॉन्फ़िगर करना चाहिए ताकि हम एक ही वर्कफ़्लो प्राप्त कर सकें, लेकिन सीआई मेनलाइन रेपो के कांटे में शाखाओं के आधार पर एक बिल्ड ट्रिगर करेगा? पसंदीदा रूप से हमारे प्रत्येक फोर्क को अलग-अलग पंजीकृत करने के बिना?
मैं TeamCity 7.1 के फीचर-शाखा प्रलेखन (blog post, release notes, documentation) पढ़ा है, लेकिन मैं के रूप में हर किसी के लिए विरोध कैसे मनमाना संख्या के- कांटे की हमारे मॉडल पर लागू करने का नहीं दिख रहा है करता है करने के लिए मुख्य लाइन में सुविधा शाखाओं।
बस याद रखें कि उपयोगकर्ता खाते जिसे आपने टीसी को _must का उपयोग करने के लिए कॉन्फ़िगर किया है, यदि आप स्थिति के गितब को सूचित करने के लिए कहते हैं तो पहुंच पहुंच_ है। – oligofren