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