2009-11-05 8 views
8

उदाहरण के लिए: प्रत्येक परियोजना SVN में अपनी ही ट्रंक है: [भंडार]/PROJECTAसह-निर्भर परियोजनाओं के निर्माण के लिए CruiseControl.net को कॉन्फ़िगर कैसे करें?

मैं परियोजना ए प्रोजेक्ट ए का निर्माण करना चाहते परियोजना बी और परियोजना सी

संपादित करें पर निर्भर करता है/ट्रंक [भंडार]/ProjectB/ट्रंक [भंडार]/ProjectC/ट्रंक

मेरा प्रश्न भागों की एक जोड़ी है:

  1. इस "आश्रित" निर्माण को प्राप्त करने के लिए सीसीएनईटी के लिए दृष्टिकोण/कॉन्फ़िगरेशन क्या है?
  2. मुझे परियोजनाओं को कैसे कॉन्फ़िगर करना चाहिए ताकि परियोजना बी या सी बनाया जा सके, फिर यह प्रोजेक्ट ए के निर्माण को ट्रिगर करता है?
  3. चूंकि प्रत्येक प्रोजेक्ट निर्भरता प्राप्त करता है, निर्माण प्रक्रिया को मापने के लिए स्केलेबल दृष्टिकोण/कॉन्फ़िगरेशन क्या है?

मैं सीसीएनईटी के लिए नौसिखिया हूं इसलिए यदि कुछ अंतर्निहित अवधारणाएं हैं तो कृपया यह न मानें कि मैं उनसे अवगत हूं। विवरण मेरे दोस्त हैं :- डी

संपादित करें: मैं अपने स्रोत नियंत्रण प्रदाता के रूप में एसवीएन का उपयोग कर रहा हूं।

+1

क्या आप इन परियोजनाओं के लिए अपनी उपversण संरचना के बारे में कुछ और विवरण जोड़ सकते हैं? क्या सभी परियोजनाएं एक ट्रंक के तहत हैं या क्या अलग-अलग भंडार हैं? –

+0

धन्यवाद जेसन पूछने के लिए, प्रश्न में पहला संपादन देखें। – Achilles

+0

http://confluence.public.thoughtworks.org/display/CCNET/Project+Trigger – Achilles

उत्तर

10

आप इस प्रकार का Project Trigger का उपयोग PROJECTA शुरू करने के लिए कर सकते हैं जब ProjectB सफलतापूर्वक बनाया गया है,: ProjectB के लिए

<project name="ProjectA"> 
    <triggers> 
     <projectTrigger project="ProjectB"> 
      <triggerStatus>Success</triggerStatus> 
      <innerTrigger type="intervalTrigger" 
          seconds="60" 
          buildCondition="ForceBuild" /> 
     </projectTrigger> 
    </triggers> 
    ... 
</project> 

इस चुनाव का निर्माण परिणाम हर 60 सेकंड है, और अगर वहाँ एक नया सफल निर्माण है तो PROJECTA है शुरू हो गया। डिफ़ॉल्ट रूप से यह उसी सीसीएनईटी सर्वर पर प्रोजेक्ट की तलाश करेगा, लेकिन आप इसे serverUri विशेषता के साथ किसी अन्य पर इंगित कर सकते हैं। प्रोजेक्ट ए के लिए आप एक और ट्रिगर जोड़ सकते हैं यदि आप इसे तब भी बनाना चाहते हैं जब इसका सबवर्सन रिपोजिटरी अपडेट हो।

यदि आप एक ही सर्वर पर बिल्ड चला रहे हैं तो आप उन्हें एक ही कतार में डाल सकते हैं यदि वे किसी अन्य तरीके से एक दूसरे के साथ हस्तक्षेप कर सकते हैं, अन्यथा आप दोनों एक ही समय में निर्माण कर सकते हैं।

+0

ऐसा लगता है कि मुझे वही चाहिए जो मुझे चाहिए। मैं दूर प्लग और देखता हूं कि यह कितना अच्छा काम करता है। – Achilles

3

मैंने लगभग 20 समाधानों का एक निर्माण प्रणाली स्थापित की है और शायद एक निर्माण इंजन के रूप में सीसीनेट के साथ NANT स्क्रिप्ट का उपयोग करके 100 परियोजनाएं स्थापित की हैं। समाधानों के बीच निर्भरताओं को संभालने के लिए मैंने जावा आधारित टूल Ivy का उपयोग किया।

आईवी बाइनरी निर्भरताओं का उपयोग करता है जहां निर्भरता संस्करण जानकारी के साथ योग्यता प्राप्त करती है। संकलन का आउटपुट बाइनरी रिपोजिटरी में संग्रहीत होता है, यानी फाइल सिस्टम या यहां तक ​​कि उपversण में भी। बाइनरी निर्भरताओं को संकलित करते समय फ़ाइल सिस्टम में डाउनलोड किया जाता है।

यह दृष्टिकोण प्रोजेक्ट के लिए ठीक काम करता है जहां आपके पास अपेक्षाकृत ढीले युग्मित मॉड्यूल (एमएस समाधान द्वारा प्रतिनिधित्व) है जो अपेक्षाकृत स्वतंत्र रूप से स्वतंत्र रूप से विकसित होता है। आपके जैसे सेटअप के लिए जहां आपके पास प्रत्येक प्रोजेक्ट/समाधान के लिए एक अलग ट्रंक है, परियोजनाओं/समाधानों को वास्तव में कम से कम युग्मित होने की आवश्यकता है या अन्यथा आप अपने आप को बहुत अधिक टैगिंग और ब्रांचिंग कर पाएंगे क्योंकि सिस्टम बड़ा हो जाता है।

यदि आपको अपनी परियोजनाओं के बीच अधिक तंग युग्मन करने की आवश्यकता है तो मैं उन्हें उसी ट्रंक में ले जाने की अनुशंसा करता हूं।

नोट: आइवी को कमांड लाइन निष्पादन योग्य के रूप में जाना जाना चाहिए और आपको अच्छा जावा चींटी एकीकरण नहीं मिलता है।

+0

परियोजनाओं को एक ही ट्रंक में स्थानांतरित करना आदर्श होगा, लेकिन मैं लचीलापन चाहता हूं कि उन्हें भंडार में ढीला रूप से व्यवस्थित किया जाए। निर्माण प्रक्रिया के दौरान मुझे लगता है कि कामकाजी निर्देशिका में समाधान की निर्देशिका संरचना का निर्माण करना परियोजनाओं को एक साथ संकलित करना संभव बनाता है? – Achilles

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