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