निरंतर एकीकरण करते समय कोड समीक्षाएं कब करें?


33

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

तो सवाल यह है कि हम कोड की समीक्षा कब करते हैं?

कोड में जांच करने से पहले हम ऐसा नहीं कर सकते, क्योंकि यह प्रक्रिया को धीमा कर देगा जहां हम दैनिक चेकइन करने में सक्षम नहीं होंगे, अकेले प्रति दिन कई चेकइन दें।

इसके अलावा, यदि हम जिस कोड को केवल कंपाइल में देख रहे हैं, लेकिन वह फीचर पूर्ण नहीं है, तो कोड की समीक्षा करना व्यर्थ है, क्योंकि फीचर को अंतिम रूप दिए जाने पर अधिकांश कोड समीक्षाएं सबसे अच्छी होती हैं। क्या इसका मतलब यह है कि किसी फीचर के पूरा होने पर हमें कोड रिव्यू करना चाहिए, लेकिन वह बिना कोड वाला रिपॉजिटरी में मिल जाएगा?


जब चेकइन / पुश करने की बात आती है, तो अधिकांश जगहों पर एक प्रमुख नियम होता है: निर्माण को मत तोड़ो! यानी ऐसी किसी चीज़ की जाँच न करें जो निर्माण नहीं करेगी। उस स्थान से इतर, मैं छोटे और सीमित चेकइनों को प्राप्त करना चाहता था, लेकिन राशि के बारे में कभी कुछ नहीं कहा।
कुछ प्रोग्रामर

लेकिन कोड की समीक्षा कब होती है, इससे पहले कि आप चेकइन करें, या जब आपका फीचर हो जाए? क्या इसका मतलब है कि आपके पास ऐसा कोड है जिसकी समीक्षा नहीं की गई है और समीक्षा के बाद मिलने वाले किसी भी मुद्दे को आप ठीक करते हैं?

यह भिन्न होता है, लेकिन अधिकांश स्थानों को मुख्य शाखाओं में से एक में विलय होने से पहले निजी शाखाओं पर कोड की समीक्षा करना चाहते हैं,
कुछ प्रोग्रामर ने

जवाबों:


12

IMO, आपको मेनलाइन में प्रकाशित होने से पहले कोड की समीक्षा करनी चाहिए ताकि मेनलाइन में केवल उच्चतम गुणवत्ता कोड हो।

OTOH, एक अच्छी बात यह हो सकती है कि 'सीआई टेस्ट ऑटोमेशन पर नहीं चलने पर समीक्षा क्यों परेशान करती है?' । इस तरह वे पहले प्रतिबद्ध होते हैं और वहां धक्का देते हैं, फिर एक बार जब यह पास हो जाता है तो इसकी समीक्षा करें, फिर मेनलाइन में विलय करें (जहां यह सीआई सर्वर के माध्यम से एक और रन प्राप्त करेगा)।

आपको यह सुनिश्चित करने के लिए निश्चित रूप से गैर-सुविधा-पूर्ण कोड की समीक्षा करनी चाहिए कि भविष्य की सुविधाओं के लिए मचान जगह में है, या कम से कम यह है कि इसमें कुछ भी नहीं डाला जा रहा है जो भविष्य की सुविधाओं को लागू होने से रोक देगा।

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

(पूर्ण प्रकटीकरण: मैं स्मार्टबियर के लिए काम करता था, कोड सहयोगी, एक कोड समीक्षा उपकरण के निर्माता)


4
कोडव्यू-बाय-ईमेल खराब प्रैक्टिस है (हालांकि, कुछ भी नहीं, बेहतर तरीके से, बेहतर) क्योंकि यह बताना मुश्किल है कि समीक्षा कब की गई है। जेरिट या रिव्यूबोर्ड की तरह एक वास्तविक कोड-समीक्षा टूल प्राप्त करें और इसका उपयोग करें और चारों ओर ईमेल पैच बंद करें :)
pjz

1
फिर भी, मुझे नहीं लगता कि यह डीवीसीएस की परवाह किए बिना एक आदर्श प्रक्रिया है या नहीं। कोड समीक्षा की आवश्यकताओं में से एक कोड को देखने के लिए नहीं है, बल्कि वास्तव में कोड को चलाने के लिए या स्वचालित रूप से कोड का परीक्षण करें और देखें कि क्या होता है। तुम बस की एक श्रृंखला के साथ ऐसा नहीं कर सकते।
जॉर्डन

2
सुझाव के लिए +1 कि स्वचालित परीक्षण चलाने के बाद समीक्षा की जानी चाहिए।
विलियम पायने

1
जॉर्डन: असली कोडरव्यू टूल (जेरिट, आदि) केवल भिन्नता से अधिक प्रदान करते हैं - आप सभी संदर्भ को पढ़ते हैं ताकि आप यह पता लगा सकें कि कोड परिवर्तन वास्तव में क्या प्रभावित कर रहा है। यदि आप की आवश्यकता हो सकती है, हाँ, पैच को डाउनलोड करें और इसका निर्माण करें, लेकिन चूंकि यह सभी सीआई से गुजर रहा है, वैसे भी यह माना जाता है कि स्वचालन द्वारा पकड़ी जा सकने वाली त्रुटियां होंगी, इसलिए एकाग्रता स्थिरता और किनारे के मामलों पर अधिक है कि स्वचालन या आकस्मिक परीक्षण नहीं पकड़ सकता है।
pjz

1
क्या सीआई के बिंदुओं में से एक प्रारंभिक और अक्सर मेनलाइन के साथ सिंक करने के लिए नहीं है? आपका दृष्टिकोण सिंक्रनाइज़ करने में देरी करेगा जिसमें कई कमियां हैं।
जैकब आर।

11

जोड़ी प्रोग्रामिंग सेट करें?

सभी कोड की समीक्षा की जाती है क्योंकि यह प्रक्रिया को बढ़ाए बिना या किसी अन्य चरण को शुरू किए बिना टाइप किया जा रहा है।


7

यहाँ निरंतर वितरण लेखक से उद्धरण है:

Jez विनम्र लिखते हैं:

मैं वर्तमान में इस विषय पर एक ब्लॉग पोस्ट लिख रहा हूं। संक्षिप्त उत्तर यह है:

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

संक्षेप में: कोड समीक्षा अच्छी है। इतना अच्छा, हमें इसे लगातार करना चाहिए, जोड़ी प्रोग्रामिंग और समीक्षा के माध्यम से। यदि एक वरिष्ठ देव को एक बुरा वचन मिलता है, तो उसे उस व्यक्ति के साथ जोड़ी बनानी चाहिए जिसने उन्हें समस्या को ठीक करने में मदद करने के लिए प्रतिबद्ध किया है।

एक औपचारिक समीक्षा में मेनलाइन में मर्जिंग खराब है, और ऐसा करने के लिए शाखाएं बनाना अतिरिक्त खराब है, उसी कारण से कि सुविधा शाखाएं खराब हैं।

धन्यवाद,

Jez।

मूल लिंक यह है: https://groups.google.com/forum/# ​​.msg / continuousdelivery / LIJ1nva9Oas / y3sAaMtibGAJ


5

मुझे नहीं पता कि यह करने का सबसे अच्छा तरीका है ... लेकिन मैं बताऊंगा कि हम यह कैसे करते हैं। एक या एक से अधिक डेवलपर्स किसी दिए गए शाखा पर काम करते हैं और अपने कोड को जितनी बार कर सकते हैं उतनी बार मर्ज पर समय बर्बाद करने से बचने के लिए करते हैं जो अन्यथा नहीं हुआ होता। कोड तैयार होने पर ही इसे सिर में लगाया जाता है। अब वह कमिट्स और ब्रांच / हेड चीज़ के लिए है।

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

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

इसलिए हमारे पास दो कोड समीक्षाएं, एक स्वचालित और एक "मानव" है और हम HEAD शाखा में बिना कोड वाले कोड को कम करने से बचने की कोशिश करते हैं। अब ... यह विभिन्न कारणों से कभी-कभी होता है, हम एकदम सही हैं, लेकिन हम गुणवत्ता और लागत (समय) के बीच उचित संतुलन रखने की कोशिश करते हैं!

@pjz एक अच्छा उत्तर भी प्रदान करता है, और वह कोड समीक्षा टूल का उल्लेख करता है। मैं किसी भी तरह का इस्तेमाल किया है, इसलिए मैं उस बारे में कुछ नहीं कह सकता ... हालांकि मैं अतीत में क्रूसिबल के साथ काम करने के लिए लुभाया गया हूं क्योंकि हम पहले से ही जिरा का उपयोग कर रहे हैं ।


दिलचस्प विचार है कि समीक्षा को किसी विशेष समय / दिन के लिए निर्धारित किया जाना चाहिए ...
विलियम पायने

@WilliamPayne धन्यवाद। एक और चीज जो हमारे लिए काम करती है वह है कोड समीक्षा बैठकों को शेड्यूल करना, इसलिए यह कैलेंडर पर स्पष्ट रूप से दिखाई देता है कि हम "व्यस्त" हैं। यह लोगों को चेतावनी देने में मदद करता है कि यद्यपि हम यहाँ हैं ... हम वास्तव में नहीं हैं :-)
जलयेन

4

मुझे लगता है कि मुख्य अवधारणा जो "स्टेजिंग" क्षेत्र की मदद करेगी।

हां, आप उस कोड की जांच नहीं करना चाहते हैं जो टूट गया है। लेकिन आपको बार-बार कोड की जाँच भी करनी चाहिए। क्या यह पूरी तरह से पूर्णता है? ;) नहीं। कई क्षेत्रों का उपयोग करें और git की तरह एक DVCS।
इस तरह से आप परिवर्तन (स्थानीय रूप से) करते हैं और जब तक आप परीक्षण करते हैं और परीक्षण पास होने तक उनका विकास करते हैं। फिर आप कोड की समीक्षा के लिए एक स्टेजिंग क्षेत्र पर धक्का देते हैं।

फिर आपको स्टेजिंग से लेकर अन्य QA प्रयासों जैसे कि ब्राउज़र परीक्षण और उपयोगकर्ता परीक्षण पर जोर देना चाहिए। अंत में आप वॉल्यूम परीक्षण क्षेत्र में जा सकते हैं, फिर अंत में उत्पादन कर सकते हैं।

इसके भीतर भी वर्कफ़्लोज़ हैं जैसे कि सभी लोग मुख्य शाखा पर काम कर रहे हैं या सभी प्रयासों के लिए व्यक्तिगत शाखाओं का उपयोग कर रहे हैं।

निरंतर एकीकरण स्वयं भी कई स्तरों पर हो सकता है। यह एक डेवलपर्स मशीन के लिए स्थानीय हो सकता है 'जब तक कि परीक्षण पास न हो जाए' और यह स्टेजिंग और क्यूए क्षेत्रों में भी हो सकता है जब कोड उनके पास जाता है।



2

हम अपनी रिपॉजिटरी के लिए git flow का उपयोग करते हैं , और जब हम विकसित शाखा में विलय करने की बात करते हैं तो हम अपनी कोड समीक्षा करते हैं।

विकसित में कुछ भी पूर्ण, तैनाती योग्य और कोड की समीक्षा की गई है।

हमारे पास हमारे विकसित और मास्टर शाखाओं के लिए CI सेट अप भी है।


2

मुझे वास्तव में-वास्तव में लगता है कि आपको स्वाभाविक रूप से ऐसा करने के लिए एक डीवीसीएस (जैसे मर्क्यूरियल, गिट) की आवश्यकता होगी। CVCS के साथ आपको एक शाखा की आवश्यकता होगी और आपके पास जो भी भगवान है, वह विलय योग्य नरक नहीं होगा।

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

ऐसा करने का एक पहला तरीका, विशेष रूप से यदि आपके पास रिपॉजिटरी प्रबंधन सॉफ़्टवेयर नहीं है जो व्यक्तिगत रिपॉजिटरी (जैसे बिटबकेट, गिटब, रोडबॉस्क) को प्रकाशित करने में मदद कर सकता है, तो पदानुक्रमित एकीकरण भूमिकाएं होती हैं। निम्नलिखित आरेखों में, आप लेफ्टिनेंट की समीक्षा डेवलपर्स के काम कर सकते हैं, और तानाशाह के पास मुख्य समन्वयक की समीक्षा के रूप में है कि लेफ्टिनेंट कैसे काम में विलय कर देते हैं।

यहाँ छवि विवरण दर्ज करें

यदि आपके पास रिपॉजिटरी प्रबंधन सॉफ्टवेयर है, तो इसे करने का एक और तरीका है, निम्नलिखित की तरह वर्कफ़्लो का उपयोग करना:

यहाँ छवि विवरण दर्ज करें

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

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

पुनश्च: छवियों के लिए क्रेडिट git-scm.com पर जाएं


1
गिथब के लोग कोड समीक्षा करने के लिए पुल अनुरोधों का उपयोग करते हैं और स्कॉट चाकोन , ज़च होल्मन और अन्य के अनुसार यह अच्छी तरह से काम करता है।
स्पिकाइ

1

एक से अधिक भंडार क्यों नहीं हैं? एक "दैनिक" काम के लिए, एक निरंतर एकीकरण सर्वर ड्राइविंग, सभी यूनिट परीक्षण और एकीकरण परीक्षण चलाने के लिए अच्छा तंग फीडबैक लूप, और एक और "स्थिर" काम के लिए, जहां कम लगातार होते हैं, लेकिन समीक्षा के माध्यम से जाना है।

पथ पर निर्भर करता है कि वे सिस्टम के माध्यम से आगे बढ़ते हैं, यह एक जटिल समाधान का एक सा हो सकता है, और Git या Mercurial Queues जैसे उपकरण का उपयोग करते समय सबसे अच्छा काम कर सकता है, (चेतावनी: मैंने न तो क्रोध में इस्तेमाल किया है) लेकिन बहुत सारे संगठन कुछ ऐसा ही करते हैं।


1

क्या इसका मतलब यह है कि किसी फीचर के पूरा होने पर हमें कोड रिव्यू करना चाहिए, लेकिन वह बिना कोड वाला रिपॉजिटरी में मिल जाएगा?

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

  • दूसरी ओर, एकमात्र मामला जब मैं परियोजना में सीआई के साथ प्री-कमिट कोड समीक्षाओं को "शादी" करने की कोशिश कर रहा था, बल्कि दर्दनाक था। खैर जब चीजें 100% सुचारू रूप से चली गईं, तो यह ठीक था - लेकिन यहां तक ​​कि अनंतिम रुकावटें (जैसे कि जब मुख्य और बैकअप समीक्षक दोनों कुछ घंटों के लिए अनुपलब्ध थे) ने ध्यान देने योग्य तनाव बनाया। मैंने यह भी देखा कि टीम का मनोबल कुछ कमज़ोर था - थोड़ा बहुत संघर्ष भी हुआ।

-2

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

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

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

सवाल पर लौटें। कोड समीक्षा कब करनी है, इसके लिए कोई मानक उत्तर नहीं है, और यह आपकी मूल विकास प्रक्रिया और आपके निरंतर एकीकरण के वास्तविक कार्यान्वयन पर निर्भर करता है।

हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.