नाइटली बिल्ड बनाम निरंतर एकीकरण: लंबे समय से चलने वाले स्वचालित टेस्ट

Question

हमारे पास एकीकरण परीक्षण के बड़े स्वचालित सूट की "समस्या" है। जबकि हमारे निर्माण के समय उचित हैं (< 1 घंटा), परीक्षण आमतौर पर पूरा होने के लिए 6 घंटे लगते हैं।

हालांकि हमारे निर्माण रनों में परीक्षण की कार्यक्षमता का यह बड़ा हिस्सा होना बहुत अच्छा है, यह स्पष्ट रूप से सीआई को लागू करने में बाधा है, जिसे मैंने "हमेशा बिल्ड करने योग्य" राज्य में स्रोत पेड़ रखने के लिए बहुत मददगार पाया है ।

मैंने this one जैसे चर्चा के थ्रेड की समीक्षा की है, जो भेदों पर विस्तृत है।

यह मैं कुछ सवाल की ओर जाता है:

1. यूनिट बनाम समाकलन परीक्षण स्वचालन की सिफारिश सीआई हुक्म करता है या नहीं? मैंने अतीत में केवल यूनिट सुना है, लेकिन मुझे त्वरित खोज में इस तरह के किसी भी बयान (या तर्क) नहीं मिल रहा है।

2. संयुक्त निर्माण + स्वचालित परीक्षण समय/अनुपात के लिए एक टीम के लिए प्रभावी सीआई रखने के लिए एक अच्छा "सर्वोत्तम अभ्यास" क्या है? मेरा आंत मुझे बताता है कि यह < 2 घंटे सबसे खराब मामले के रूप में होना चाहिए, और शायद < 1 घंटे वास्तव में प्रभावी होना चाहिए। सिद्धांत रूप में, हम समानांतर में चलाने के लिए परीक्षणों को तोड़ सकते हैं और शायद उन्हें 2 घंटे से कम समय में चलते हैं, लेकिन यह अभी भी 3 घंटे का रन होगा।

3. लंबे समय से चलने वाली नाइटली बिल्ड + सीआई को एकीकरण टेस्ट से आगे का सबसे अच्छा तरीका क्या है? मैं केवल कुछ कंकाल यूनिट टेस्ट के साथ सीआई निर्माण के बारे में सोच रहा हूं, जिसमें रात के निर्माण के साथ संयोजन होता है जो एकीकरण परीक्षणों के साथ जारी रहता है।

किसी भी टूलींग सिफारिशों का भी स्वागत है (विंडोज़ केवल सी #/सी ++ codebase)

Answer 1

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

स्रोत: http://martinfowler.com/articles/continuousIntegration.html#KeepTheBuildFast

क्यों यह 6 घंटे लगते हैं करता है? आपके पास कितने परीक्षण हैं? एकीकृत लोगों की तुलना में यूनिट-टेस्ट का अनुपात क्या है? आपके पास संभावित रूप से कई अधिक एकीकृत परीक्षण हैं या आपका यूनिट-टेस्ट वास्तव में इकाई नहीं है। क्या आपके यूनिट परीक्षण डीबी को छू रहे हैं? यह समस्या हो सकती है।

6 घंटे लंबा लंबा समय है। उपरोक्त आलेख में कुछ सुझाव हैं।

Answer 2

यहाँ कुछ चीजें हैं।

आम तौर पर आपके पास कई बिल्ड होंगे, जो & यूनिट परीक्षणों को संकलित करता है, जो ऐसा करता है और स्थानीय स्वीकृति परीक्षण चलाता है, और एक जो एकीकरण परीक्षण चलाता है।

आप निश्चित रूप से को एक भी निर्माण की आवश्यकता नहीं है जो सबकुछ करता है।

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

6 घंटे भी बहुत लंबा समय है। क्या आप सुनिश्चित हैं कि आपके परीक्षण सही सामान का परीक्षण कर रहे हैं? क्या आपके पास बहुत अधिक विस्तृत स्कोप परीक्षण हैं? क्या आप इस तथ्य के लिए हर जगह "नींद()" का उपयोग कर रहे हैं कि आपने अपने टेस्ट कोड में एसिंक्रोनि को अच्छी तरह से मॉडल नहीं किया है?

आपको शायद जेज़ हंबल्स पुस्तक "निरंतर वितरण" पकड़ना चाहिए, और यूनिट/एकीकरण परीक्षण लिखने के तरीके के रूप में बढ़ते ऑब्जेक्ट ओरिएंटेड सॉफ्टवेयर पर एक नज़र डालें। GOOS जावा को कार्यान्वयन भाषा के रूप में उपयोग करता है, लेकिन सभी अवधारणाएं समान हैं।