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