आप यह नहीं जान सकते कि सीआई क्या है जब तक आप नहीं जानते कि हम क्या करते थे। 3 भागों के साथ एक प्रणाली की कल्पना करें। एक यूआई है जो डेटा इकट्ठा करता है और इसे डेटाबेस में डालता है। एक रिपोर्टिंग प्रणाली है जो डेटाबेस से रिपोर्ट बनाती है। और कुछ प्रकार के सर्वर हैं जो डेटाबेस की निगरानी करते हैं और कुछ मानदंड पूरे होने पर ईमेल अलर्ट भेजते हैं।
बहुत पहले यह इस प्रकार लिखा जाएगा:
- डेटाबेस और आवश्यकताओं के लिए स्कीमा पर सहमति दें - इसमें कुछ सप्ताह लगेंगे क्योंकि यह एकदम सही होगा क्योंकि आप जल्द ही देखेंगे कि क्यों
- 3 टुकड़ों के लिए 3 देवों, या 3 स्वतंत्र टीमों की असाइन करें
- प्रत्येक देव अपने टुकड़े पर काम करता है और हफ्तों या महीनों के लिए अपने स्वयं के डेटाबेस कॉपी का उपयोग करके अपने टुकड़े का परीक्षण करता है।
इस समय के दौरान, देवता एक-दूसरे के कोड को नहीं चलाएंगे, और न ही उस डेटाबेस के संस्करण का उपयोग करने का प्रयास करेंगे जो किसी और के कोड द्वारा बनाया गया था। रिपोर्ट लेखक सिर्फ नमूना डेटा का एक गुच्छा जोड़ देगा। अलर्ट लेखक रिकॉर्ड जोड़ देगा जो रिपोर्ट घटनाओं का अनुकरण करता है। और GUI लेखक ने डेटाबेस में यह देखने के लिए देखा कि GUI ने क्या जोड़ा है। समय के साथ, देवों को यह एहसास होगा कि ऐनक किसी तरह से गलत थी, जैसे कि किसी इंडेक्स को निर्दिष्ट नहीं करना या बहुत कम फ़ील्ड लंबाई, और उनके संस्करण में "ठीक" करना। वे दूसरों को बता सकते हैं, जो उस पर कार्रवाई कर सकते हैं, लेकिन आमतौर पर ये चीजें बाद के लिए एक सूची में जाती हैं।
जब सभी तीन भागों को पूरी तरह से कोडित किया गया था, और उनके देवों द्वारा परीक्षण किया गया था, और कभी-कभी उपयोगकर्ताओं द्वारा भी परीक्षण किया गया (उन्हें एक रिपोर्ट, एक स्क्रीन या ईमेल अलर्ट दिखाते हुए) तो "एकीकरण" चरण आएगा। यह अक्सर कई महीनों के बजट में होता था, लेकिन फिर भी खत्म हो जाएगा। देव 1 से क्षेत्र की लंबाई में परिवर्तन की खोज यहां की जाएगी, और विशाल कोड परिवर्तन और संभवतः यूआई परिवर्तन भी करने के लिए देव 2 और 3 की आवश्यकता होगी। यह अतिरिक्त सूचकांक अपना कहर बरपाएगा। और इसी तरह। यदि किसी उपयोगकर्ता द्वारा किसी फ़ील्ड को जोड़ने के लिए देवों में से एक को बताया गया था, और अब ऐसा ही होगा, तो अन्य दो को भी इसमें जोड़ना होगा।
यह चरण क्रूर रूप से दर्दनाक था और भविष्यवाणी करना बहुत असंभव था। तो लोग कहने लगे "हमें अधिक बार एकीकृत करना होगा।" "हमें शुरुआत से एक साथ काम करना होगा।" "जब हम में से कोई एक परिवर्तन अनुरोध उठाता है [तो हमने कैसे बात की है] दूसरों को इसके बारे में जानना होगा।" कुछ टीमों ने अलग-अलग काम करना जारी रखते हुए पहले एकीकरण परीक्षण करना शुरू किया। और कुछ टीमों ने शुरुआत से ही एक-दूसरे के कोड और आउटपुट को हर समय इस्तेमाल करना शुरू कर दिया। और वह कंटीन्यूअस इंटीग्रेशन बन गया।
आप सोच सकते हैं कि मैं उस पहली कहानी को बढ़ा-चढ़ाकर बता रहा हूं। मैंने एक बार एक कंपनी के लिए कुछ काम किया था, जहाँ मेरे संपर्क ने मुझे कुछ खामियों की जाँच करने के लिए बाहर कर दिया, जो निम्न दोषों से पीड़ित थीं:
- एक स्क्रीन जो वह काम नहीं कर रही थी उसमें एक बटन था जो अभी तक कुछ भी नहीं किया था
- किसी भी उपयोगकर्ता ने स्क्रीन डिजाइन (सटीक रंग और फोंट; स्क्रीन के अस्तित्व, इसकी क्षमताओं और 300 पेज की युक्ति में इसके कौन से बटन थे) पर हस्ताक्षर नहीं किए थे।
यह उनकी राय थी कि जब तक यह किया जाता है तब तक आप स्रोत नियंत्रण में सामान नहीं रखते हैं। उन्होंने आम तौर पर एक या दो चेकों को YEAR किया। हमारे पास एक दर्शन अंतर था :-)
इसके अलावा, अगर आपको यह विश्वास करना मुश्किल है कि टीमों को डेटाबेस जैसे साझा संसाधन के आसपास काट दिया जाएगा, तो आप वास्तव में विश्वास नहीं करेंगे (लेकिन यह सच है) कि कोड के लिए समान दृष्टिकोण लिया गया था। आप एक फ़ंक्शन लिखने जा रहे हैं जिसे मैं कॉल कर सकता हूं? यह बहुत अच्छा है, आगे बढ़ें और ऐसा करें, मैं इस दौरान मुझे केवल हार्डकोड की आवश्यकता होगी। महीनों बाद मैं अपने कोड को "एकीकृत" करूंगा ताकि यह आपके एपीआई को कॉल करे और हमें पता चल जाएगा कि अगर मैं अशक्त हो जाता हूं, तो मैं उड़ा देता हूं अगर यह अशक्त हो जाता है (और यह बहुत कुछ करता है) यह उन चीजों को वापस करता है जो बहुत बड़े हैं मेरे लिए, यह लीप वर्ष और एक हजार अन्य चीजों को संभाल नहीं सकता है। स्वतंत्र रूप से काम करना और फिर एक एकीकरण चरण होना सामान्य था। अब यह पागलपन जैसा लगता है।
