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