“बिल्ड सर्वर” का क्या मतलब है? [बन्द है]


101

मैंने बहुत बड़े संगठनों के लिए काम नहीं किया है और मैंने कभी भी "बिल्ड सर्वर" वाली कंपनी के लिए काम नहीं किया है।

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

एकमात्र जगह जो मुझे बिल्ड सर्वर के उपयोगी होती है वह है बिल्ड सर्वर के साथ निरंतर एकीकरण के लिए जो लगातार रिपॉजिटरी के लिए प्रतिबद्ध है। क्या यह है कि मैंने अभी बड़ी परियोजनाओं पर काम नहीं किया है?

कोई, कृपया मुझे बताएं: बिल्ड सर्वर का उद्देश्य क्या है?

जवाबों:


94

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

इस मामले पर जोएल स्पोल्स्की।


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

1
वास्तव में यह केवल स्वच्छ चेकआउट से निर्माण का कारण है, न कि एक समर्पित बिल्ड-सर्वर पर समर्पित बिल्ड-एजेंट से निर्माण के लिए। एक स्थानीय डेवलपर्स मशीन पर रिपॉजिटरी के एक साफ चेकआउट में एक स्वचालित बिल्ड-स्क्रिप्ट चलाने से पहले से ही समर्पित बिल्ड-सर्वर के अधिकांश फायदे मिलते हैं।
कैसरलुडी

एक प्रमुख लाभ, IMHO, यह है कि यह आपको एक बिल्ड-सिस्टम का उपयोग करने के लिए मजबूर करता है जो 100% स्वचालित रूप से चलेगा और अत्यधिक आपको इसे शुरू करने के लिए पुश करने के लिए शून्य बटन रखने के लिए प्रोत्साहित करता है। यह सिर्फ इतना ही नहीं है कि आपके पास रिलीज और टेस्ट बिल्ड के लिए एक ही स्रोत है, बल्कि यह सुनिश्चित करने के बारे में भी है कि लोग आपके बिल्ड सिस्टम को खराब न करें।
क्लियर

48

बिल्ड सर्वर कई कारणों से महत्वपूर्ण हैं।

  • वे पर्यावरण को अलग करते हैं स्थानीय कोड बंदर डेवलपर का कहना है कि "यह मेरी मशीन पर संकलन करता है " जब यह आप पर संकलन नहीं करेगा। इसका मतलब आउट-ऑफ-सिंक चेक-इन हो सकता है या इसका मतलब यह हो सकता है कि एक आश्रित पुस्तकालय गायब है। जार नर्क .dll नर्क जितना बुरा नहीं है; किसी भी तरह, बिल्ड सर्वर का उपयोग करना सस्ता बीमा है जो आपके बिल्ड रहस्यमय तरीके से विफल नहीं होगा या गलत पुस्तकालयों को गलती से पैकेज नहीं करेगा।

  • वे बिल्ड से जुड़े कार्यों पर ध्यान केंद्रित करते हैं। इसमें बिल्ड टैग को अपडेट करना, कोई वितरण पैकेजिंग बनाना, स्वचालित परीक्षण चलाना, बिल्ड रिपोर्ट बनाना और वितरित करना शामिल है। स्वचालन कुंजी है।

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


12
+1 प्रोग्रामर को अपने बिल्ड माहौल में परिवर्तन के लिए दस्तावेज़ प्राप्त करना हेरिंग बिल्लियों की तरह है। वे बस याद नहीं कर सकते कि किस स्तर पर उन्होंने अपने .Net या बूस्ट लीब को अपडेट किया, अगर उन्हें एहसास हुआ कि उन्होंने ऐसा किया है। एक केंद्रीय सर्वर का दैनिक निर्माण करने के बाद शाम को उन्हें कोड में जांचने के बाद एक्ट में पकड़ लिया जाता है- और यह बताने के लिए प्रेरित करने जैसा कुछ भी नहीं है, "आपने टीम बिल्ड को तोड़ दिया, आप क्या भूल गए?"
किमी जूल

28

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

डेवलपर्स अपने स्थानीय मशीनों पर परियोजना का निर्माण क्यों नहीं कर रहे हैं, या वे कर रहे हैं?
क्योंकि जटिल सॉफ्टवेयर के साथ, आश्चर्यजनक रूप से बहुत सी चीजें गलत हो सकती हैं जब सिर्फ "संकलन" के माध्यम से। जिन समस्याओं का मैंने वास्तव में सामना किया है:

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

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

क्या कुछ परियोजनाएं इतनी बड़ी हैं कि उचित समय में इसे बनाने के लिए अधिक शक्तिशाली मशीनों की आवश्यकता है?

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

क्या यह है कि मैंने अभी बड़ी परियोजनाओं पर काम नहीं किया है?

आकार निश्चित रूप से एक कारक है, लेकिन केवल एक ही नहीं है।


8

एक बिल्ड सर्वर कंटीन्यूअस इंटीग्रेशन सर्वर के लिए एक अलग अवधारणा है। जब परिवर्तन किए जाते हैं तो CI सर्वर आपकी परियोजनाओं का निर्माण करने के लिए मौजूद होता है। इसके विपरीत एक बिल्ड सर्वर एक स्वच्छ वातावरण पर परियोजना (आमतौर पर एक रिलीज, एक संशोधित संशोधन के खिलाफ) के निर्माण के लिए मौजूद है। यह सुनिश्चित करता है कि कोई भी डेवलपर हैक, ट्वीक्स, अनअप्रूव्ड कॉन्फिगरेशन / आर्टिफिशियल वर्जन या अनक्मिटेड कोड इसे जारी किए गए कोड में नहीं बनाता है।


बहुत बढ़िया जवाब। नाम के लिए भी उत्थान।
फिलिप शिफ

6

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


5

जो पहले ही कहा जा चुका है उस पर जोड़ने के लिए:

एक पूर्व-सहकर्मी ने Microsoft Office टीम पर काम किया और मुझे बताया कि एक पूर्ण निर्माण में कभी-कभी 9 घंटे लगते थे। यह अपनी मशीन पर यह करने के लिए चूसना होगा , है ना?


4

पिछले संस्करणों (और कॉन्फ़िगरेशन परिवर्तन) की कलाकृतियों से मुक्त "स्वच्छ" वातावरण का होना आवश्यक है ताकि यह सुनिश्चित हो सके कि निर्माण और परीक्षण काम करते हैं और कलाकृतियों पर निर्भर नहीं होते हैं। अलग करने का एक प्रभावी तरीका एक अलग बिल्ड सर्वर बनाना है।


4

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


बिल्कुल @Greg! यहाँ सभी को लगता है कि वह हिस्सा छूट गया है। मैं अभी अनुपालन के लिए एक परिवर्तन नियंत्रण प्रक्रिया पर काम कर रहा हूं जिसके लिए उत्पादन के लिए एक द्वितीयक विभाग की आवश्यकता है। खैर, जब तक आप आईटी सिखाना नहीं चाहते कि विजुअल स्टूडियो का उपयोग कैसे करें और यादा यादा को तैनात करें ... यह आपको त्वरित क्लिक के साथ ऐसा करने का एक तरीका देता है। निश्चित रूप से यह कैसे "बेकार" माना जाता है जैसा कि कुछ ने कहा है।
gcoleman0828

3

इन मशीनों का उपयोग कई कारणों से किया जाता है, सभी आपको एक बेहतर उत्पाद प्रदान करने में मदद करने की कोशिश कर रहे हैं।

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

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


2

लगातार गुणवत्ता के लिए और पर्यावरण की त्रुटियों को दूर करने के लिए बिल्ड 'योर मशीन' को प्राप्त करने के लिए और स्रोत नियंत्रण में जांच करने के लिए भूल जाने वाली किसी भी फाइल को भी बिल्ड एरर दिखाते हैं।

मैं इसे इंस्टालर बनाने के लिए भी उपयोग करता हूं क्योंकि ये डेस्कटॉप पर कोड साइनिंग आदि के लिए बहुत समय लेते हैं।


1

हम एक का उपयोग करते हैं ताकि हम जान सकें कि उत्पादन / परीक्षण बॉक्स में उन पुस्तकालयों के समान पुस्तकालय और संस्करण हैं जो बिल्ड सर्वर पर उपलब्ध हैं।


1

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


1

आप सही हैं कि डेवलपर्स अपनी मशीनों पर निर्माण कर सकते हैं।

लेकिन ये कुछ चीजें हैं जो हमारे बिल्ड सर्वर हमें खरीदता है, और हम शायद ही परिष्कृत बिल्ड निर्माता हैं:

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

1

शायद मैं ही हूँ ...

मुझे लगता है कि हर कोई इससे सहमत है

  • फ़ाइल रिपॉजिटरी का उपयोग करें
  • रिपॉजिटरी से बनता है (और स्वच्छ वातावरण में)
  • आपके "सुधार" के बाद कुछ टूट गया है या नहीं यह देखने के लिए एक निरंतर परीक्षण सर्वर (जैसे क्रूज़ कंट्रोल) का उपयोग करें

लेकिन कोई भी स्वचालित रूप से निर्मित संस्करणों की परवाह नहीं करता है। जब एक स्वचालित निर्माण में कुछ टूट गया था, लेकिन यह अब नहीं है - कौन परवाह करता है? यह प्रगति पर काम है। किसी ने इसे ठीक कर दिया।

जब आप रिलीज़ संस्करण करना चाहते हैं, तो आप रिपॉजिटरी से एक बिल्ड चलाते हैं। और मुझे पूरा यकीन है कि आप उस समय रिपॉजिटरी में संस्करण को टैग करना चाहते हैं और हर छह घंटे में नहीं जब सर्वर काम करता है।

तो, शायद "बिल्ड सर्वर" सिर्फ एक मिथ्या नाम है और यह वास्तव में "महाद्वीप परीक्षण सर्वर" है। अन्यथा यह बहुत बेकार लगता है।


0

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


0

इसके अतिरिक्त, याद रखें कि उच्च स्तर की भाषाओं की तुलना में निम्न स्तर की भाषाओं को संकलन में अधिक समय लगता है। यह सोचना आसान है "अच्छी तरह से देखो, मेरी .Net परियोजना कुछ सेकंड में संकलन करती है? क्या बड़ी बात है?" कुछ समय पहले मुझे कुछ सी कोड में गड़बड़ करनी पड़ी थी और मैं यह भूल गया था कि संकलन में कितना समय लगता है।


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

0

एक निर्माण सर्वर का उपयोग संकलन कार्यों (जैसे रात में निर्माण) को आमतौर पर बड़े भंडार में स्थित परियोजनाओं के लिए किया जाता है जो कभी-कभी कुछ घंटों से अधिक समय ले सकते हैं।


0

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

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