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