2015-01-29 9 views
6

मेरे पास एक परीक्षण वीसीएस रूट के साथ एक बिल्ड कॉन्फ़िगरेशन है जो गिट शाखा dev, 3 बिल्ड चरण और 1 ट्रिगर से कनेक्ट होता है। ये अपने निर्माण कदम हैं:फीचर शाखाओं पर चल रहे परीक्षण

  • बिल्ड परीक्षण
  • भागो परीक्षण
  • बिल्ड & तैनात

मैं इन सब शाखा dev के लिए चरणों लेकिन उनमें से केवल दो (निर्माण को चलाने के लिए चाहते हैं feature/* से मेल खाने वाली शाखाओं के लिए परीक्षण बनाएं और चलाएं)। मैं इसे अपने निर्माण विन्यास के तहत प्रदर्शित करना चाहता हूं। इसलिए बिल्ड कॉन्फ़िगरेशन में एक डिफ़ॉल्ट dev शाखा है जो परीक्षण और तैनाती चलाती है, लेकिन feature/* अतिरिक्त शाखाएं केवल परीक्षण चलाती हैं।

मैं इसे कैसे प्राप्त कर सकता हूं?

यदि मैं शाखा विनिर्देश (डिफ़ॉल्ट शाखा के नीचे) में /refs/heads/(feature/*) जोड़ता हूं, तो यह पूरी तरह से काम करता है, लेकिन यह हमेशा तैनात करता है - जो मैं नहीं चाहता हूं।

enter image description here

संपादित करें 1: वहाँ एक चर उपलब्ध %teamcity.build.branch% है कि आप उपयोग कर सकते हैं नामित हो रहा है। लेकिन यह जांचने के लिए तैनाती चरण में सशर्त कैसे करें कि शाखा dev शाखा है या नहीं। मुझे यकीन नहीं है।

संपादित करें 2: एक परिवर्तनीय नाम %vcsroot.branch% भी है जो VCS रूट में डिफ़ॉल्ट शाखा का नाम है। इसलिए हमें अभी भी ऐसी स्थिति की आवश्यकता है जो जांचता है कि %teamcity.build.branch% चर %vcsroot.branch% के बराबर है, तो तैनाती चरण चलाएं।

+0

4 साल पुराना फीचर अनुरोध यहां है: https://youtrack.jetbrains.com/issue/TW-17939 – Arjan

+0

बिल्कुल, यही वजह है कि टीमसिटी हमारे रोडमैप पर है। – Gaui

उत्तर

5

आप जो चाहते हैं उसे हासिल करने का तरीका 2 बिल्डों में अपना निर्माण विभाजित करना और उनके बीच निर्भरता है। तो आप बिल्ड के बीच अलग ट्रिगर्स हो सकते हैं।

तो इसलिए बनाता है आप का निर्माण किया है विभाजित एक जो

  • बिल्ड परीक्षण
  • भागो परीक्षण

और बी जो

  • बिल्ड & शामिल तैनात
  • निर्माण होता है

को निर्माण बी का निर्माण ए

पर एक स्नैपशॉट निर्भरता फिर जब एक VCS चेक-इन का पता चला है एक निर्माण करने के लिए एक ट्रिगर जोड़ें। यह सुनिश्चित करेगा कि किसी भी सुविधा शाखा पर निर्माण और परीक्षण चल रहे हैं।

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

अद्यतन इस बहुत ज्यादा परेशानी है तो आप एक छोटे चाल लेकिन भागो परीक्षण के बीच एक निर्माण कदम बनाने खेलते हैं और निर्माण करने में सक्षम और तैनात जो एक कमांड लाइन या powershell स्क्रिप्ट कॉल हो सकता है। %teamcity.build.branch% में गुजरने वाली स्क्रिप्ट को कॉल करें और फिर स्क्रिप्ट यह जांच सकती है कि इसे dev और Exit 0 के साथ बुलाया गया है और यदि Exit -1 यदि नहीं है और यह चरण तब निर्माण को विफल करने और तैनाती को रोकने में विफल होना चाहिए। इसका मतलब यह होगा कि बिल्ड विफल हो जाएगा लेकिन उस चरण को रोक देगा जो आप चलने से बचाना चाहते हैं। यह चरण विफल होने के कारण बिल्डिंग की रिपोर्ट न करने के लिए टीमसिटी प्राप्त करना संभव हो सकता है, मुझे यकीन नहीं है कि

आप अन्य विकल्प यह है कि आप एक स्क्रिप्ट लिखते हैं जो मैन्युअल रूप से निर्माण और तैनाती करता है और फिर इस स्क्रिप्ट को पास करता है %teamcity.build.branch% में और dev पर जल्दी से बाहर निकलें और केवल dev पर वास्तविक निर्माण और तैनाती करने के लिए आगे बढ़ें। इसका परिणाम असफल निर्माण नहीं होगा, लेकिन इसका मतलब है कि टीम चीजें अब आपके लिए काम कर रही चीजों को करने के लिए स्क्रिप्ट लिखनी है।

+0

एक और आसान तरीका होना चाहिए? हमारे पास 100+ बिल्ड कॉन्फ़िगरेशन (टेस्ट/स्टेजिंग/लाइव) है। यह रास्ता बहुत परेशानी है। – Gaui

+0

आपने बिल्ड कॉन्फ़िगरेशन की संख्या के बारे में किसी भी बाधा का उल्लेख नहीं किया है। मेरा मानना ​​है कि यह 'सही' तरीका है, लेकिन मैं एक हैक के साथ जवाब अपडेट करूंगा जो * काम * कर सकता है। –

+0

कृपया धन्यवाद। – Gaui

1

आप यह जांचने के लिए "टेस्ट" बिल्ड चरण (उदा। पावरहेल स्क्रिप्ट) बनाकर ऐसा कर सकते हैं कि आपका %teamcity.build.branch% आपके feature/* पैटर्न से मेल खाता है या नहीं। पिछले चरण सफल होने पर ही आप निम्न चरणों को चलाते हैं (इस मामले में & परिनियोजित करें)। स्पष्ट रूप से "परीक्षण" चरण निर्माण में विफल नहीं होना चाहिए।

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