इस पेज पर बताया गया है कि बिल्ड सिस्टम क्या होते हैं, वे क्या करते हैं, आपको बिल्ड सिस्टम का इस्तेमाल क्यों करना चाहिए, और कंपाइलर और बिल्ड स्क्रिप्ट सबसे सही विकल्प क्यों नहीं हैं. यह उन डेवलपर के लिए है जिन्हें बिल्ड सिस्टम का ज़्यादा अनुभव नहीं है.
बिल्ड सिस्टम क्या है?
बुनियादी तौर पर, सभी बिल्ड सिस्टम का सीधा मकसद होता है: वे इंजीनियर के लिखे गए सोर्स कोड को एक्ज़ीक्यूटेबल बाइनरी में बदल देते हैं जिन्हें मशीन से पढ़ा जा सकता है. बिल्ड सिस्टम सिर्फ़ मानव-रचित कोड के लिए नहीं हैं, बल्कि वे मशीन को अपने आप बिल्ड बनाने की सुविधा देते हैं, चाहे वे टेस्टिंग के लिए हों या प्रोडक्शन के लिए रिलीज़ के लिए. हज़ारों इंजीनियर वाले संगठन में, ज़्यादातर यह बात होती है कि ज़्यादातर बिल्ड सीधे इंजीनियर के बजाय, अपने-आप ट्रिगर हो जाते हैं.
क्या सिर्फ़ कंपाइलर का इस्तेमाल नहीं किया जा सकता?
ऐसा हो सकता है कि बिल्ड सिस्टम को इस्तेमाल करने की ज़रूरत तुरंत न पड़े. ज़्यादातर इंजीनियर, कोडिंग सीखने के दौरान बिल्ड सिस्टम का इस्तेमाल नहीं करते हैं. ज़्यादातर टूल, कमांड लाइन से सीधे तौर पर gcc या javac या किसी इंटिग्रेटेड डेवलपमेंट एनवायरमेंट (आईडीई) में, इससे मिलते-जुलते टूल का इस्तेमाल करते हैं. जब तक सभी सोर्स कोड एक ही डायरेक्ट्री में हों, तब तक इस तरह का कमांड ठीक से काम करता है:
javac *.java
यह Java कंपाइलर को मौजूदा डायरेक्ट्री में मौजूद हर Java सोर्स फ़ाइल को लेने और उसे एक बाइनरी क्लास फ़ाइल में बदलने का निर्देश देता है. सबसे आसान मामले में, आपको बस इतना ही की ज़रूरत है.
हालांकि, जैसे ही कोड बड़ा होता है, जटिलताएं शुरू हो जाती हैं. इंपोर्ट करने के लिए कोड ढूंढने के लिए, javacमौजूदा डायरेक्ट्री की सबडायरेक्ट्री देखने का स्मार्ट तरीका है. हालांकि, इसके पास फ़ाइल सिस्टम के अन्य हिस्सों में स्टोर कोड ढूंढने का कोई तरीका नहीं होता है. यह लाइब्रेरी को शायद कई प्रोजेक्ट में शेयर किया जाता है. यह सिर्फ़ Java कोड
बनाने का तरीका भी जानता है. आम तौर पर, बड़े सिस्टम में अलग-अलग प्रोग्रामिंग भाषाओं में लिखे गए अलग-अलग प्रोग्राम शामिल होते हैं. इनमें, डिपेंडेंसी के वेब के साथ डिपेंडेंसी अलग-अलग होती हैं. इसका मतलब है कि एक ही भाषा के लिए कोई भी कंपाइलर पूरा सिस्टम नहीं बना सकता.
एक से ज़्यादा भाषाओं या कई कंपाइलेशन यूनिट के कोड पर काम करने के बाद, बिल्डिंग कोड अब एक-चरण वाली प्रोसेस नहीं है. अब आपको यह आकलन करना होगा कि आपका कोड किस पर निर्भर करता है और उन चीज़ों को सही क्रम में लगाएं. इसके लिए, आप हर हिस्से के लिए अलग-अलग टूल का इस्तेमाल कर सकते हैं. अगर कोई डिपेंडेंसी बदलता है, तो पुरानी बाइनरी के आधार पर, इस प्रोसेस को दोहराना होगा. समान साइज़ के कोडबेस के लिए, यह प्रोसेस ज़्यादा जटिल और गड़बड़ी वाली हो सकती है.
कंपाइलर को बाहरी डिपेंडेंसी को मैनेज करने के तरीके के बारे में भी पता नहीं होता. उदाहरण के लिए, Java में तीसरे पक्ष की फ़ाइलें JAR. बिल्ड सिस्टम के बिना,
इसे मैनेज करने के लिए इंटरनेट से डिपेंडेंसी डाउनलोड की जा सकती है. इसके बाद, उसे हार्ड ड्राइव के lib फ़ोल्डर में चिपकाया जा सकता है और कंपाइलर को डायरेक्ट्री से पढ़ा जा सकता है. समय के साथ, इन बाहरी डिपेंडेंसी के
अपडेट, वर्शन, और सोर्स को बनाए रखना मुश्किल होता है.
शेल स्क्रिप्ट का क्या होगा?
मान लें कि आपका शौक प्रोजेक्ट इतना आसान हो गया है कि आप इसे सिर्फ़ कंपाइलर से इस्तेमाल करके बना सकते हैं. हालांकि, आपको पहले बताई गई कुछ समस्याओं में काम करना शुरू कर देता है. शायद आपको अब भी लगता है कि आपको बिल्ड सिस्टम की ज़रूरत नहीं है. आप कुछ आसान शेल स्क्रिप्ट का इस्तेमाल करके, धीरे-धीरे काम कर सकते हैं. ये स्क्रिप्ट, सही क्रम में चीज़ें बनाने का काम करती हैं. इससे कुछ समय के लिए मदद मिलती है, लेकिन बहुत बार आपको और समस्याएं आ जाती हैं:
यह एक मुश्किल काम हो जाता है. जैसे-जैसे आपका सिस्टम आगे बढ़ता जाता है, आप अपनी बिल्ड स्क्रिप्ट पर उतना ही समय खर्च करते हैं जितना कि असल कोड पर. शेल स्क्रिप्ट को डीबग करना कठिन होता है, जिसमें एक के ऊपर एक से ज़्यादा हैक किए जाते हैं.
यह धीमा है. यह पक्का करने के लिए कि आपने गलती से पुरानी लाइब्रेरी पर भरोसा न कर लिया हो, आपकी बिल्ड स्क्रिप्ट में हर बार डिपेंडेंसी के लिए, हर डिपेंडेंसी का इस्तेमाल किया जाता है. आपको कुछ ऐसे तर्क जोड़ने होंगे जिनसे पता चलता है कि किन हिस्सों को फिर से बनाने की ज़रूरत है. हालांकि, लगता है कि ये चीज़ें बहुत जटिल हैं और स्क्रिप्ट बनाने में गड़बड़ी हो सकती है. इसके अलावा, आप यह भी सोच सकते हैं कि हर बार किन हिस्सों को फिर से बनाने की ज़रूरत है, लेकिन इसके बाद, आप वापस स्क्वेयर स्क्वेयर पर वापस आ जाते हैं.
खुशखबरी: यह रिलीज़ का समय है! बेहतर तरीके से बस उन सभी तर्कों का पता लगाएं जो आपको फ़ाइनल बिल्ड को बनाने के लिए, जार निर्देश को पास करने हैं. साथ ही, इसे अपलोड करने और सेंट्रल रिपॉज़िटरी (डेटा स्टोर करने की जगह) में भेजने का तरीका याद रखें. और दस्तावेज़ अपडेट बनाएं और पुश करें और उपयोगकर्ताओं को एक सूचना भेजें. ओह, शायद यह किसी दूसरी स्क्रिप्ट के लिए है...
आपदा! आपकी हार्ड ड्राइव क्रैश हो जाती है और अब आपको अपना पूरा सिस्टम फिर से बनाना होगा. आपकी सभी फ़ाइलों को वर्शन कंट्रोल में रखने का तरीका काफ़ी स्मार्ट था, लेकिन डाउनलोड की गई लाइब्रेरी का क्या होगा? क्या उन सभी को फिर से खोजकर यह पक्का किया जा सकता है कि उनका वही वर्शन है जो पहली बार डाउनलोड करने पर आया था? आपकी स्क्रिप्ट शायद खास जगहों पर इंस्टॉल किए जा रहे खास टूल पर निर्भर थीं—क्या आप उसी परिवेश को बहाल कर सकते हैं जिससे स्क्रिप्ट फिर से काम करें? कंपाइलर के ठीक से काम करने और फिर उसके बारे में भूलने के लिए, उन सभी एनवायरमेंट वैरिएबल का क्या करें जो आपने बहुत समय पहले सेट किया था?
समस्याओं के बावजूद, आपका प्रोजेक्ट इतना कामयाब हो गया है कि ज़्यादा से ज़्यादा इंजीनियर नियुक्त किए जा सकते हैं. अब आप यह जान गए हैं कि पिछली समस्याओं के आने पर कोई आपदा नहीं होती है—आपको हर बार अपनी टीम में किसी नए डेवलपर के शामिल होने पर उसी मुश्किल प्रक्रिया का सामना करना पड़ता है. और आपके सभी कोशिशों के बाद भी, हर व्यक्ति के सिस्टम में थोड़ा बहुत अंतर होता है. अक्सर, एक व्यक्ति की मशीन पर जो चीज़ काम करती है वह दूसरे के मशीन पर काम नहीं करती और हर बार डिबगिंग टूल पाथ या लाइब्रेरी वर्शन को समझने में कुछ घंटे लगते हैं.
आपने तय किया है कि आपको अपने बिल्ड सिस्टम को ऑटोमेट करना होगा. सैद्धांतिक तौर पर, यह नया कंप्यूटर लेने और क्रॉन का इस्तेमाल करके हर रात अपनी बिल्ड स्क्रिप्ट चलाने के लिए इसे सेट अप करने जितना आसान है. आपको सेट अप करने की दर्द भरी प्रोसेस से गुज़रना होगा. हालांकि, अब आपको मामूली समस्याओं का पता लगाकर उन्हें ठीक करने का कोई फ़ायदा नहीं मिलता. अब, हर सुबह जब आप जाते हैं, तो आपको पता चलता है कि पिछली रात का बिल्ड विफल हो गया था. इसकी वजह यह है कि कल एक डेवलपर ने ऐसा बदलाव किया था जो उसके सिस्टम पर काम तो कर रहा था, लेकिन उसने ऑटोमेटेड बिल्ड सिस्टम पर काम नहीं किया. हर बार यह आसान तरीका है, लेकिन ऐसा अक्सर होता है कि आप इन आसान समाधानों को खोजने और लागू करने में हर दिन बहुत ज़्यादा समय बिताते हैं.
जैसे-जैसे प्रोजेक्ट आगे बढ़ता है, बिल्ड की गति धीमी होती जाती है. एक दिन बिल्ड के पूरा होने का इंतज़ार करने के दौरान, आप अपने साथी के खाली डेस्कटॉप को देखकर दुखी होते हैं और यह चाहते हैं कि वह कंप्यूटर, कंप्यूटर की ताकत का फ़ायदा उठा सके.
आपने क्लासिक लेवल की समस्या का सामना किया है. किसी एक डेवलपर के लिए, ज़्यादा से ज़्यादा एक या दो हफ़्तों तक कोड की कुछ सौ लाइन पर काम किया जा सकता है. ऐसा, हो सकता है कि अभी तक यूनिवर्सिटी में ग्रेजुएशन करने वाले जूनियर डेवलपर के पूरे काम के अनुभव की वजह से, आपको पूरी तरह कंपाइलर की ज़रूरत हो. स्क्रिप्ट आपको थोड़ा बड़ा कर सकती हैं. अगर आपको कई डेवलपर और उनकी मशीनों के साथ मिलकर काम करना है, तो सिर्फ़ एक सही बिल्ड स्क्रिप्ट ही काफ़ी नहीं होती, क्योंकि उन मशीनों में मामूली अंतर को ध्यान में रखना बहुत मुश्किल काम हो जाता है. इस समय, यह आसान तरीका अलग हो जाता है और अब सही बिल्ड सिस्टम में निवेश करने का समय है.