निरंतर एकीकरण: कौन सी आवृत्ति?

Question

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

सबसे पहले, कुछ विवरण:

• ऑब्जेक्टिव-सी (iOS 5) प्रोजेक्ट
• 10 विकासशील
• प्रत्येक बिल्ड वास्तव में ~ 1 मिनट लेता है, और बिल्ड और यूनिट परीक्षण शामिल है।
• एकीकरण सर्वर एक मैक मिनी है, इसलिए कंप्यूटिंग शक्ति वास्तव में यहां कोई समस्या नहीं है
  • हम XCode प्लगइन के साथ जेनकिंस का उपयोग करते हैं

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

तो, इस पर आपकी क्या राय है?

Comments

सुनिश्चित करें कि आपका निर्माण समय 2 या 3 महीने में ~ 1min होगा, 10 devs लगातार अपनी परियोजना में यूनिट परीक्षणों सहित अधिक कोड जोड़ रहे हैं?

— डॉक्टर ब्राउन

परिवर्तन का अनुरोध करने के लिए आर्किटेक्ट के तर्क का पता लगाना दिलचस्प होगा; आपके अंक अच्छे हैं, लेकिन क्या वे वास्तविक मुद्दे को संबोधित करते हैं?

Answer 1

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

हर कमिट पर निर्माण करना सही काम है।

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

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

Comments

+1। झुंझलाहट के लगातार "बिल्ड फेल" संदेशों का उत्तर यह है कि बिल्ड को बार-बार न तोड़ें।

— suszterpatt

शांत समय पर - जेनकिंस का तीसरा विकल्प, "पोल एससीएम", बस उसी के लिए है। जब रिपॉजिटरी में परिवर्तन पाए जाएंगे तो यह केवल अपडेट / परीक्षण चलाएगा। उदाहरण के लिए, हमारे पास प्रत्येक 5 मिनट चलाने के लिए एक नौकरी सेट है यदि कोई परिवर्तन (यूनिट परीक्षण) हैं, और कोई भी परिवर्तन (एकीकरण परीक्षण) होने पर हर 3 घंटे में चलाने के लिए एक दूसरा सेट है। दोनों रात / सप्ताहांत में शांत हैं क्योंकि कोई भी कुछ भी नहीं कर रहा है।

— इज़काता 19

Answer 2

हर 15 मिनट में एक बिल्ड करने का कोई मतलब नहीं है अगर कुछ भी नहीं बदला है। लेकिन समान रूप से कोई नकारात्मक पहलू नहीं है, afaik, jenkins केवल असफलता पर ई-मेल करेंगे और फिर सफलता और बीच में सब कुछ नहीं (जैसे 10 विफल)।

हम इसे हर कमिट पर करते हैं। हालाँकि हम हर पंद्रह मिनट में रिपॉजिटरी का चुनाव करते हैं और बदलावों की जाँच करते हैं, हो सकता है कि yr के सहयोगियों का जिक्र हो।

आप उम्मीद करते हैं कि आपके 10 देवता हर पंद्रह मिनट में एक से अधिक बार प्रतिबद्ध होंगे? यह एक उच्च अनुमान की तरह लगता है। 10 देव का मतलब है कि हर 150 मिनट के बाद एक ही व्यक्ति फिर से कर रहा है, इसलिए 2.5 घंटे। तो आपके औसत दिन में प्रत्येक देव 3 बार काम करता है। व्यक्तिगत रूप से मैं एक कमिट करता हूं ~ 2 दिन ... कभी-कभी अधिक कभी कभी कम।

Comments

वास्तव में, कमिट्स यहां बहुत तेजी से चलते हैं, इसलिए यह पूरी तरह से संभव है, लेकिन हां, मैं देख रहा हूं कि आपका क्या मतलब है।

— वैलेंटाइन रोचर

@NimChimpsky: आप हर 3 दिन में एक काम करते हैं? अगर यह सच है, तो मेरा सुझाव है कि आपको अपनी प्रतिबद्ध रणनीति पर गंभीरता से पुनर्विचार करना चाहिए। जब भी आप किसी पिछली स्थिति में कुछ रीसेट करने जा रहे हैं, तो आप 3 दिन तक काम करेंगे! आप अपने परिवर्तन लॉग में कुछ शब्दों में 3 पूर्ण दिनों के परिवर्तनों का वर्णन कैसे करते हैं? वह आवाज बहुत ही बेतुकी है। व्यक्तिगत रूप से, जब भी मैंने अपने कार्यक्रम में एक कार्य सुविधा स्लाइस को जोड़ा है, आमतौर पर एक दिन में कई बार करता हूं।

— डॉक ब्राउन

@DocBrown अपनी बेतुकी बातों से दूर। मैं एक मिनट में तीन बार विभिन्न परियोजनाओं और विभिन्न रिपॉजिटरी के लिए प्रतिबद्ध हो सकता हूं। दूसरी ओर मैं एक पूरे हफ्ते के लिए कोई भी कोड नहीं लिख सकता। मेरा सुझाव है कि आप अपनी टिप्पणी की रणनीति पर गंभीरता से विचार करें।

— निमचम्प्सकी

@NumChimpsky: मैं मान रहा था कि आप ओपी द्वारा वर्णित एक स्थिति की तुलना में बात कर रहे थे। हम एक ही प्रोजेक्ट पर काम करने वाले 10 देवों के बारे में बात कर रहे हैं। यदि प्रति देवता के बीच औसत समय 3 दिन है, तो उस परियोजना में बहुत कुछ गलत हो जाता है।

— डॉक्टर ब्राउन

@DocBrown wtf? आप नहीं जानते कि आप किस बारे में बात कर रहे हैं ... मुझे लगता है कि आप एक साथ कई परियोजनाओं पर काम नहीं करते हैं।

— निमचम्पस्की

Answer 3

यह मेल के साथ बाढ़ डेवलपर्स के लिए जा रहा है और अधिक करता है, तो यह केवल हर 15 मिनट है। ऐसा इसलिए है क्योंकि यह निश्चित नहीं होगा कि किसने निर्माण को तोड़ा और इस तरह अधिक लोगों को मेल किया।

मेट्रिक्स के रूप में, अगर यह वास्तव में एक समस्या है - जो मैं नहीं बता सकता क्योंकि मुझे नहीं पता कि वे क्या मैट्रिक्स के साथ सोचते हैं कि इसमें कोई समस्या है-, आप हमेशा मेट्रिक्स इकट्ठा करने के लिए एक और काम कर सकते हैं।

Answer 4

शायद आवश्यकता को " 15 मिनट में अधिकतम एक बार बिल्ड " किया जाए। यह बहुत लगातार प्रतिबद्ध गतिविधि वाली परियोजनाओं के लिए समझ में आ सकता है (यानी कुछ मिनटों के भीतर कई काम करता है) और शायद लंबे समय का निर्माण। बेशक यह इस बात पर भी निर्भर करता है कि बिल्ड का उपयोग कैसे किया जाता है। परीक्षकों के लिए यह 15 मिनट के भीतर कई बिल्ड प्राप्त करने के लिए कुछ भ्रामक हो सकता है ...

लेकिन मैं मानता हूं कि अगर कुछ भी नहीं बदला है, तो इसका कोई मतलब नहीं है।

Answer 5

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

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

या, बेहतर (!), अपने देवों को केवल छोटे हिस्से में काम करने के लिए मार्गदर्शन करने का प्रयास करें, एक समय में केवल एक ही चीज, केवल "कार्यात्मक पूर्ण" शारीरिक कमिट करना बहुत आसान बना देता है। फिर हर प्रतिबद्धता के बाद एक निर्माण बेमतलब काम करेगा।

Answer 6

यहां तक ​​कि अगर आपके पास एक परियोजना या इसके किसी भी निर्भरता के लिए स्रोत नियंत्रण पर बनाने के लिए जेनकींस स्थापित है, तो यह पहली बार स्रोत नियंत्रण के बिना विरूपण साक्ष्य भंडार को तैनात करने से एक डेवलपर को रोकता नहीं है। अगर वे विरूपण साक्ष्य भंडार में निर्भरता में एक uncoordinated एपीआई परिवर्तन या एक बग को तैनात करते हैं, तो यह जेनकींस की नौकरी को ट्रिगर किए बिना आपके निर्माण को तोड़ सकता है। मैं व्यक्तिगत रूप से इस ASAP के बारे में जानना चाहूंगा।

आदर्श रूप में आप हर कमिटमेंट के लिए निर्माण करेंगे और एक शेड्यूल पर जैसे मैं अभी वर्णित स्थितियों की जाँच करूँगा। इसका मतलब है कि आप हर 15 मिनट में कम से कम एक बार निर्माण करेंगे ।

यदि आपके पास अपने जेनकिंस की नौकरियां निर्भरता विरूपण साक्ष्य के डिप्लॉय पर चलाने के लिए स्थापित हैं (और यदि आप करते हैं ... ब्रावो), तो आप अनुसूचित बिल्ड को कुल्हाड़ी मार सकते हैं यदि आपकी इकाई परीक्षण ठोस हैं (मतलब वे निर्भरता का परीक्षण नहीं करते हैं) और आपके एकीकरण / कार्यात्मक परीक्षण जेनकिंस नौकरी का हिस्सा नहीं हैं।

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

Answer 7

आपने कहा कि आप उनके तर्क को नहीं समझ सकते, इसलिए आपको उनसे पूछना होगा। वे जो चाहते हैं, उस पर केवल अनुमान न लगाएं और उस पर अमल करने की कोशिश करें, और निश्चित रूप से केवल वही नहीं लागू करें जो उन्होंने बिना सोचे समझे पूछा था कि वे इसके लिए क्यों पूछते हैं।

कहा कि, सामान्य प्रश्न का उत्तर देने के लिए, यह आपके द्वारा उपयोग किए जाने वाले विकास दर्शन पर निर्भर करता है। यदि हर कमिट में काम करने की उम्मीद है, तो हर कमिटमेंट का परीक्षण किया जाना चाहिए। यदि आप दर्शन के साथ एक डीवीसीएस का उपयोग करते हैं जो कि प्रत्येक पुश को काम करना चाहिए, तो प्रत्येक पुश का परीक्षण करें।

सामान्य तौर पर, लोगों को कुछ ऐसा बताना बेहतर होता है जो वे नहीं जानते हैं, फिर जो वे जानते हैं उसे दोहराने के लिए। उदाहरण के लिए, यदि वे बेमानी ईमेलों की संख्या कम करना चाहते हैं, तो ईमेल सेटिंग्स को ट्विस्ट करें, न कि बिल्ड फ्रीक्वेंसी को।