2009-06-12 17 views
5

हमारी .NET सॉफ़्टवेयर विकास दुकान में, हमारे पास 28 परियोजनाओं के निर्माण के लिए क्रूज़ कंट्रोल.NET स्थापित है, जिनमें से कुछ परस्पर निर्भर हैं। प्रत्येक प्रोजेक्ट लगभग विजुअल स्टूडियो प्रोजेक्ट्स या फ्लेक्स लाइब्रेरी का प्रतिनिधित्व करता है जो इकाई परीक्षणों के साथ जोड़ा जाता है। जो मुझे नाराज है, वह यह है कि मुझे यह सुनिश्चित करने का एक अच्छा तरीका नहीं मिला है कि परियोजनाएं निर्भरताओं का प्रतिनिधित्व करने वाले आदेश में निर्माण करें।परियोजना निर्भरताओं के साथ CruiseControl.NET में ऑर्डर बनाएं

यहाँ मैं क्या कर रहा हूँ है:

  1. सब कुछ एक ही निर्माण कतार में है। मैंने ऐसा किया ताकि निर्माण क्रमशः किया जा सके और इसलिए मैं कई कार्यशील निर्देशिकाओं की आवश्यकता से बच सकता हूं।
  2. मैंने परियोजनाओं पर कतार प्राथमिकताएं निर्धारित की हैं, जिन्हें मैंने सोचा था कि उनके निर्माण आदेश को प्रभावित करेगा। लेकिन दस्तावेज़ीकरण को और सावधानी से पढ़ने के बाद, मैंने पाया कि कतार में कई निर्माण अनुरोध होने पर यह प्राथमिकता को नियंत्रित करता है।
  3. बिल्ड को लात मारने के लिए अंतराल ट्रिगर्स का उपयोग करने के अलावा, मैं प्रोजेक्ट ट्रिगर्स का उपयोग करता हूं ताकि जब निर्भरता सफलतापूर्वक निर्माण हो, तो उनके आश्रित भी निर्माण करते हैं।

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

क्रूज़ कंट्रोल.नेट सर्वर पर परस्पर निर्भरता को सही तरीके से प्रबंधित करने के लिए आप किस अभ्यास का उपयोग करते हैं? इस बिंदु पर, मैं TeamCity जैसे गैर-मुक्त सतत एकीकरण पैकेज में बदलने के लिए तैयार नहीं हूं।

उत्तर

8

CC.NET प्रोजेक्ट सेटिंग्स में निर्भरता न डालें। आपको एनएएनटी स्क्रिप्ट के माध्यम से प्रोजेक्ट बिल्ड ऑर्डर को नियंत्रित करने की आवश्यकता है। आपको समाधान स्तर पर निर्माण करने की आवश्यकता नहीं है, आप एक व्यक्तिगत परियोजना स्तर पर निर्माण कर सकते हैं।

<target name="Project1" depends="Projects2" description="Builds project 1"> 
    <msbuild> 
     <executable>C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\MSBuild.exe</executable> 
     <workingDirectory>C:\dev\ccnet</workingDirectory> 
     <projectFile>CCNet.sln</projectFile> 
     <buildArgs>/noconsolelogger /p:Configuration=Debug /v:diag</buildArgs> 
     <targets>Build;Test</targets> 
     <timeout>900</timeout> 
     <logger>C:\Program Files\CruiseControl.NET\server\ThoughtWorks.CruiseControl.MsBuild.dll</logger> 
    </msbuild> 
</target> 

<target name="Project2" depends="Projects3" description="Builds project 2"> 
    <msbuild> 
     <executable>C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\MSBuild.exe</executable> 
     <workingDirectory>C:\dev\ccnet</workingDirectory> 
     <projectFile>CCNet.sln</projectFile> 
     <buildArgs>/noconsolelogger /p:Configuration=Debug /v:diag</buildArgs> 
     <targets>Build;Test</targets> 
     <timeout>900</timeout> 
     <logger>C:\Program Files\CruiseControl.NET\server\ThoughtWorks.CruiseControl.MsBuild.dll</logger> 
    </msbuild> 
</target> 

<target name="Project3" description="Builds Project 3"> 
    <msbuild> 
      <executable>C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\MSBuild.exe</executable> 
      <workingDirectory>C:\dev\ccnet</workingDirectory> 
      <projectFile>CCNet.sln</projectFile> 
      <buildArgs>/noconsolelogger /p:Configuration=Debug /v:diag</buildArgs> 
      <targets>Build;Test</targets> 
      <timeout>900</timeout> 
      <logger>C:\Program Files\CruiseControl.NET\server\ThoughtWorks.CruiseControl.MsBuild.dll</logger> 
    </msbuild> 
</target> 

आप एक व्यक्तिगत परियोजना स्तर पर अपने यूनिट परीक्षण चला सकते हैं, इसलिए आपको कई परियोजनाओं पर डुप्लिकेट रन बनाने की आवश्यकता नहीं है।

+0

ऐसा करने का अर्थ यह होगा कि मुझे प्रत्येक निर्भर परियोजना में प्रत्येक निर्भर परियोजना के लिए निर्माण निर्देशों को डुप्लिकेट करना होगा। लेकिन मुझे लगता है कि अगर यह पता चला कि मैं CC.NET में बिल्ड ऑर्डर को नियंत्रित नहीं कर सकता, तो मुझे अनावश्यक होना होगा। कम से कम मैं एक परियोजना के निर्माण चरणों को समाहित करने के लिए एक्सएमएल इकाइयों के लिए सीसी.NET के समर्थन का उपयोग कर सकता हूं। – Jacob

+0

जरूरी नहीं है। NANT स्क्रिप्ट को स्टोर करने के लिए एकल क्रूज़.बिल्ड फ़ाइल का उपयोग करें। परियोजनाओं में इस एकल क्रूज़.बिल्ड फ़ाइल को साझा करें, इस तरह वे सभी निर्भरता पदानुक्रम का पालन करते हैं और आप स्क्रिप्ट को डुप्लिकेट नहीं कर रहे हैं। –

+0

हालांकि यह बेकार है कि बिल्ड बॉक्स को अभी भी डुप्लिकेट बिल्डिंग करना होगा, ऐसा लगता है कि इसके चारों ओर कोई अच्छा तरीका नहीं है। यह उत्तर सबसे अच्छा दिखता है। दुर्भाग्यवश शायद – Jacob

2

मेरा सुझाव है कि आप एक दृश्य स्टूडियो परियोजना के साथ एक क्रूज़ कंट्रोल परियोजना की अवधारणा को पार नहीं करते हैं! मैं आम तौर पर एक सीसी परियोजना स्थापित करता हूं जिसमें काम के एक शरीर को शामिल किया जाता है। मेरे लिए इसका मतलब है कि सीसी परियोजना एक एनएएनटी स्क्रिप्ट चलाएगी। एनएएनटी स्क्रिप्ट में जो कुछ भी मैं करता हूं उस पर बहुत बढ़िया नियंत्रण होता है। इसका मतलब है कि मैं अपना समाधान बना सकता हूं (जो जानता है कि कौन सा प्रोजेक्ट पहले निर्माण करना है!), मेरे यूनिट परीक्षण चलाएं, डेटाबेस रीसेट करें, कुछ कोड तैनात करें, कुछ ईमेल भेजें, कुछ कोड विश्लेषण करें (एनडॉन्से और एनसीओवर महान हैं!), इत्यादि। इसका मतलब है कि मेरे पास सीसीटीआरई में एक प्रोजेक्ट दिखाई देता है और यह चीजों को वास्तव में जो कुछ भी है, उससे ज्यादा सच रखता है। मैं तब सीसी में नियंत्रण करने के लिए सीसी में एक नई परियोजना बना सकता हूं जब मैं DEV से STAGING और STAGING से PROD तक दबाता हूं ताकि हम इस कार्य को "पुश बटन" कर सकें। लेकिन यह क्रूज नियंत्रण में केवल 3 परियोजनाएं पैदा करता है और यह काफी अधिक उपयोगकर्ता के अनुकूल है।

+0

सहमत हैं। वीएस समाधान फ़ाइल की अवधारणा हमारे सीसी के निर्माण के समान ही समान है। हमारी सीसी परियोजनाएं प्रत्येक "उत्पाद" का प्रतिनिधित्व करती हैं और प्रत्येक उत्पाद में कई, कई .csproj फ़ाइलें होती हैं। – womp

+0

मुख्य कारण यह नहीं है क्योंकि मेरे पास यूनिट परीक्षण है जो प्रत्येक वीएस प्रोजेक्ट से संबंधित है, और मैं प्रोजेक्ट को साझा करने वाले प्रत्येक समाधान के लिए एक ही यूनिट परीक्षण नहीं करना चाहता हूं। – Jacob

2

हालांकि आप पहले ही एक उत्तर स्वीकार कर चुके हैं, मैं कुछ और सुझाव दूंगा: आपको दो परियोजनाओं के बीच प्रत्यक्ष निर्भरता नहीं होनी चाहिए। "प्रत्यक्ष" से मेरा मतलब है कि प्रोजेक्ट में प्रत्येक बार बाइनरी एक बदलाव होता है, इसका मतलब यह नहीं होना चाहिए कि आप स्वचालित रूप से प्रोजेक्ट बी बनाने के लिए उनका उपयोग करते हैं।

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

मैं स्रोत नियंत्रण के तहत lib निर्देशिका (और उपनिर्देशिका) के तहत सभी बाहरी बाइनरी रखने के लिए रहता हूं और जब मैं ऐसा करने का निर्णय लेता हूं तो उन्हें अपडेट करता हूं। और "बाहरी" से मेरा मतलब है कि मेरी पार्टी में अन्य तृतीय पक्ष पुस्तकालयों और अन्य परियोजनाओं के लोग (उदाहरण: http://code.google.com/p/projectpilot/source/browse/#svn/trunk/lib)