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