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