मैं करने से पहले सभी यूनिट परीक्षण पास की गारंटी कैसे दे सकता हूं?

Question

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

यहां के कुछ अन्य प्रश्नों के आधार पर, यह सर्वर पक्ष पर पूर्व-प्रतिबद्ध हुक के रूप में इसे मजबूर करने के लिए एक बुरा विचार ™ प्रतीत होता है, ज्यादातर परीक्षण चलाने के लिए आवश्यक समय की लंबाई के कारण। मैं कुछ Googling किया था और इस पाया (सभी devs TortoiseSVN का उपयोग करें):

http://cf-bill.blogspot.com/2010/03/pre-commit-force-unit-tests-without.html

कौन सा हल होगा कम से कम समस्याओं के दो (यह यूनिक्स पर निर्माण नहीं होगा), लेकिन यह अस्वीकार नहीं करता प्रतिबद्ध अगर यह विफल रहता है। तो मेरे प्रश्न:

• क्या टोर्टोइज़ एसवीएन में प्री-प्रतिबद्ध हुक बनाने का कोई तरीका असफल होने का कारण बनता है?
• क्या मैं सामान्य रूप से करने की कोशिश कर रहा हूं ऐसा करने का एक बेहतर तरीका है?

Answer 1

बिल्कुल कोई कारण नहीं है कि आपका प्री-प्रतिबद्ध हुक यूनिट परीक्षण क्यों नहीं चला सकता!

• चेकआउट एक कार्यशील निर्देशिका
• करने के लिए कोड सब कुछ
• भागो सभी इकाई परीक्षण
• संकलित करें तो हुक में विफल रहते हैं इकाई परीक्षण असफल: सभी अपने पूर्व के लिए प्रतिबद्ध हुक करने के लिए है।

यह करना पूरी तरह से संभव है। और, बाद में, आपकी विकास दुकान में हर कोई आपकी हिम्मत से नफरत करेगा।

याद रखें कि एक पूर्व प्रतिबद्ध हुक में, पूरे हुक से पहले ही अनुमति दे सकते हैं पूरा करने के लिए है जगह लेने के लिए प्रतिबद्ध और नियंत्रण उपयोगकर्ता को लौट जा सकता है।

यूनिट परीक्षणों के निर्माण और चलाने में कितना समय लगता है? 10 मिनटों? कल्पना करें कि प्रतिबद्धता करने के लिए 10 मिनट तक बैठकर बैठे रहें। यही कारण है कि आपको ऐसा करने के लिए कहा नहीं गया है।

आपका निरंतर एकीकरण सर्वर आपके यूनिट परीक्षण करने के लिए एक शानदार जगह है। मैं CruiseControl पर Hudson या Jenkins पसंद करता हूं। वे सेटअप करना आसान है, और उनके वेबपृष्ठ अधिक उपयोगकर्ता के अनुकूल हैं। इससे भी बेहतर उनके पास विभिन्न प्रकार के प्लगइन्स हैं जो मदद कर सकते हैं।

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

हडसन/जेनकिंस में कुछ अच्छे ग्राफ हैं जो आपको यूनिट परीक्षण के परिणाम दिखाते हैं, ताकि आप वेबपृष्ठ से देख सकें कि कौन से परीक्षण पास हुए और असफल रहे, इसलिए यह बिल्कुल स्पष्ट है कि क्या हुआ। (क्रूज़ कंट्रोल का वेबपृष्ठ औसत आंखों के लिए पार्स के लिए कठिन है, इसलिए ये चीजें स्पष्ट नहीं हैं)।

मेरे पसंदीदा हडसन/जेनकींस प्लगइन में से एक निरंतर एकीकरण गेम है। इस प्लगइन में, उपयोगकर्ताओं को अच्छे निर्माण, यूनिट परीक्षणों को ठीक करने और अधिक पास किए गए यूनिट परीक्षण बनाने के लिए अंक दिए जाते हैं। वे खराब निर्माण और यूनिट परीक्षण तोड़ने के लिए अंक खो देते हैं। एक स्कोरबोर्ड है जो सभी डेवलपर के अंक दिखाता है।

मुझे आश्चर्य हुआ कि डेवलपर्स ने कितनी गंभीरता से इसे लिया। एक बार उन्हें एहसास हुआ कि उनके सीआई गेम स्कोर सार्वजनिक थे, वे बहुत प्रतिस्पर्धी बन गए। वे शिकायत करेंगे जब बिल्ड सर्वर स्वयं कुछ अजीब कारणों से विफल रहा, और खराब बिल्ड के लिए 10 अंक खो गए। हालांकि, असफल यूनिट परीक्षणों की संख्या में गिरावट आई, रास्ता नीचे, और यूनिट परीक्षणों की संख्या बढ़ी जो लिखी गई थीं।

Answer 2

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

Answer 3

दो दृष्टिकोण हैं:

1. अनुशासन
2. उपकरण

मेरे अनुभव में, # 1 केवल आप अब तक प्राप्त कर सकते हैं।

तो समाधान शायद उपकरण है। आपके मामले में, बाधा subversion है। इसे Mercurial या Git जैसे DVCS के साथ बदलें। इससे प्रत्येक डेवलपर को सबवर्सन के विलय दुःस्वप्न के बिना अपनी शाखा में काम करने की अनुमति मिल जाएगी।

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

तो लूप है: मुख्य रेपो -> डेवलपर -> स्टेजिंग -> मुख्य।

यहां कई जवाब हैं जो आपको विवरण देते हैं। यहां से शुरू करें: Mercurial workflow for ~15 developers - Should we use named branches?

[संपादित करें] तो आप कहते हैं कि आप अपने विकास की प्रक्रिया में प्रमुख समस्याओं को हल करने का समय नहीं है ... मैं आप अनुमान लगा कि किसी को लगता है दूँगा ...; -)

वैसे भी ... अपने सबवर्जन पेड़ से Mercurial रेपो प्राप्त करने के लिए hg convert का उपयोग करें। यदि आपके पास मानक सेटअप है, तो आपको अपना अधिक समय नहीं लेना चाहिए (इसे केवल आपके कंप्यूटर पर बहुत समय चाहिए लेकिन यह स्वचालित है)।

क्लोन जो एक कार्य रेपो पाने के लिए रेपो।प्रक्रिया इस तरह काम करती है:

• अपने दूसरे क्लोन में विकसित करें। इसके लिए फीचर शाखाएं बनाएं।
• यदि आपको किसी से परिवर्तन की आवश्यकता है, तो पहले क्लोन में कनवर्ट करें। उसमें से अपने दूसरे क्लोन में खींचें (इस तरह, जब आप गड़बड़ करते हैं तो आपके पास हमेशा "साफ" प्रतिलिपि से प्रतिलिपि होती है)।
• अब सबवर्जन शाखा (default) और अपनी सुविधा शाखा को मर्ज करें। यह सबवर्जन के मुकाबले ज्यादा बेहतर काम करना चाहिए।
• जब मर्ज ठीक है (आपके लिए सभी परीक्षण चलते हैं), दो शाखाओं के बीच एक अंतर से पैच बनाएं।
• सबवर्सन से स्थानीय चेकआउट में पैच लागू करें। इसे बिना किसी समस्या के लागू होना चाहिए। यदि ऐसा नहीं होता है, तो आप अपना स्थानीय चेकआउट साफ़ कर सकते हैं और दोहरा सकते हैं। यहां काम खोने का कोई मौका नहीं है।
• उपversण में परिवर्तनों को कम करें, उन्हें वापस रेपो # 1 में परिवर्तित करें और रेपो # 2 में खींचें।

यह बहुत सारे काम की तरह लगता है लेकिन एक सप्ताह के भीतर, आप अधिकांश काम करने के लिए एक स्क्रिप्ट या दो के साथ आते हैं।

जब आप देखते हैं कि किसी ने निर्माण को तोड़ दिया है (परीक्षण अब आपके लिए नहीं चल रहे हैं), मर्ज (hg clean -C) पूर्ववत करें और अपनी कार्यशील विशेषता शाखा पर काम करना जारी रखें।

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