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