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