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