2011-12-27 12 views
5

हो सकता है कि सिर्फ एक पागल आदमी का सपना है, लेकिन ..अनुकूलन compiletime सतत एकीकरण में

मेरी कंपनी में हम 3.5 Mio ~ 25 समाधान (बहुत पुरानी) के साथ एक बड़ी सी # नेट परियोजना है, और ~। loc। जिन समस्याओं का सामना कर रहा हूं वह है: बहुत धीमी बिल्डिंग टाइम्स, अभी एसएसडी (देव मशीन) के साथ 7 मिनट लगते हैं, 15 मिनट + सामान्य हार्डड्राइव के साथ वीएम में (टीमसिटी बिल्ड सिस्टम मैं तैनात करना चाहता हूं)। मुझे पता है, निर्माण प्रणाली सबसे तेज होनी चाहिए, लेकिन यह कुछ भी नहीं है जिसे मैं अल्प अवधि में बदल सकता हूं।

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

अब जब कि बेहद नीचे प्रतिक्रिया पाश (15 मिनट से कम एक मिनट के लिए, असली इकाई परीक्षण दिया) में कटौती करेगा छोटे प्रतिबद्ध के लिए।

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

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

पीएस .: इसके अलावा, मैं केवल उन परियोजनाओं के लिए यूनिट परीक्षण चला सकता हूं, जहां अंतिम प्रतिबद्धता में परिवर्तन किया गया था, या कम से कम उन्हें प्राथमिकता दी गई थी। लेकिन यह एक विचारधारा है।

+0

की [बहुत धीमी गति से दृश्य स्टूडियो पर बार संकलन] संभव डुप्लिकेट (http कर सकते हैं : //stackoverflow.com/questions/55517/very-slow-compile-times-on-visual-studio) – Oded

+0

हाँ, उसने देखा, लेकिन .. 1) यह बहुत पुराना है, 2) कई उत्तरों सी # के साथ प्रयोग योग्य नहीं हैं, 3) कुछ जो मदद करेंगे (जैसे कस्टम वीएस एडिन के साथ) किसी भी लिंक का समर्थन नहीं करते हैं और इतने गहरे दफन किए जाते हैं मैं समय में कुछ मूल्यवान फीडबैक की उम्मीद नहीं कर सकता – hko

+0

@hko मुझे पता है कि यह एक अकल्पनीय संख्या प्रतीत होता है बहुत सारे अंक बर्बाद करने के लिए, लेकिन मैं दूसरे प्रश्न पर एक बक्षीस डालने का विचार करता हूं और/या उत्तरों में हर लिंक का पालन करता हूं दोनों तरफ। –

उत्तर

0

एमएसबिल्ड बिल्ड स्क्रिप्ट लक्ष्यों के लिए "निर्माण" और "पुनर्निर्माण" के बीच अंतर करता है - सामान्य निर्माण केवल उन परियोजनाओं को बनाता है जो पिछले निर्माण के बाद से बदलते हैं।

यह कहा गया है कि स्रोत नियंत्रण से स्रोत प्राप्त करते समय टीमसिटी एजेंट की बिल्ड निर्देशिका को साफ नहीं करना चाहिए (ऐसा करने की क्षमता एससीएम पर निर्भर हो सकती है - ऐसा लगता है कि यह मर्कुरियल के साथ ठीक काम करता है) और बस एक निर्माण को ट्रिगर करें, पुनर्निर्माण नहीं।

यूनिट परीक्षणों के संबंध में, टीमसीआईटी पहले असफल लोगों को निष्पादित कर सकता है, लेकिन यह पता लगाना कि कौन से परीक्षण पते स्रोत स्रोत भागों को मेरे लिए मुश्किल काम लगता है, और कोई भी टीमसिटी AFAIK द्वारा समर्थित नहीं है।

+0

एचआरएम .. ठीक लगता है, लेकिन: मैं इसे पैच का परीक्षण करने के लिए उपयोग करता हूं, क्योंकि वे असफल होते हैं, वे "स्थिर" बेसलाइन (एचजी का उपयोग करके) में नहीं आते हैं .. इसलिए मुझे बिल्ड निर्देशिकाओं को "रीसेट" करना होगा gbaseline से आखिरी प्रतिबद्ध .. करने के लिए बहुत मुश्किल नहीं है, लेकिन मैं अभी भी थोड़ा आश्चर्यचकित हूं कि एक स्थापित समाधान प्रतीत नहीं होता .. – hko

3

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

यह सुझाया गया है (by this book) सबसे जटिल परियोजनाओं के लिए पहले 4 चरणों को कम करने के लिए 2-5 मिनट तक कम होने के लिए, यदि यह ऊपर जाता है तो आपके कॉन्फ़िगरेशन और सीआई का उपयोग करने के तरीके में कोई समस्या है प्रक्रिया।

 
Code commit 
triggers ---> 

Step 1. Automatic checkout on CI side 
Step 2. Compile code, ideally 1-2 mins 
Step 3. Save binaries to the artifact repository 
Step 4. Unit test, ideally 1-2 mins 
Step 5. Deploy to staging 
Step 6. Automated integration testing 
Step 7. Automated acceptance testing 
------------------------------------ 
Manual testing 
Manual deploy to production 

विशेष चरण 2 आप कर सकते हैं:

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

बी। TeamCity कॉन्फ़िगरेशन में आप निर्दिष्ट कर सकते हैं कि क्लीन चेकआउट करना है या पहले से उपलब्ध स्रोत का उपयोग करना है (चरण 1 पर समय बचा सकता है)। जांचें कि MSBuild का लक्ष्य पर सेट बनाएं जो अंतिम निर्माण (चरण 2 पर समय बचाने के बाद) से केवल स्रोत फ़ाइलों को उठाएगा।

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

+0

जानना अच्छा है, लेकिन उनमें से अधिकतर सवाल का जवाब नहीं देते हैं, मेरी समस्या चरण 2 में निहित है। :) "आप बड़ी परियोजनाओं को छोटे से विभाजित करके संकलित समय को भी कम कर सकते हैं और केवल उन पुस्तकालयों को संकलित कर सकते हैं जो बदल गए हैं।" -> जो वास्तव में मेरी समस्या का समाधान करेगा, यह समझाने की देखभाल करेगा कि पूरी तरह से स्वचालित निर्माण प्रणाली में यह कैसे संभव है जैसे कि मैं स्थापित करने का इरादा रखता हूं, बस काम करने के आधार पर? टीमसिटी को कैसे पता चलेगा कि केवल एक प्रमाणित परियोजना बदल गई है? शायद यह हो सकता है, लेकिन यह गारंटी नहीं है .. – hko

+0

@hko मैंने जवाब के नीचे अद्यतन किया है, कृपया देखें कि यह मदद करता है या नहीं। – oleksii

1

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

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

एक पूर्ण निर्माण के लिए आपके पास एक और सीआई प्रोजेक्ट हो सकता है जो रूट फ़ोल्डर को किसी भी बदलाव के लिए देखता है और पूरे समाधान के निर्माण को बंद कर देता है।

यह स्थापना ऊपर इस तरह आप प्रत्येक परियोजना का निर्माण किया है और परिणाम जल्दी से लौट जब कोड में और परियोजना के लिए परीक्षण पर एक धीमी वापसी चेक किया गया है

+0

हम Mercurial का उपयोग करें। निश्चित नहीं है कि क्या टीमसिटी रेपो परिवर्तन पर स्वचालित रूप से एक विशेष निर्माण (रेपो सबफ़ोल्डर पर आधारित) बनाने में सक्षम है, या कोई सीआई सिस्टम कर सकता है या नहीं। – hko

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