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