आप मध्यम आकार के प्रोजेक्ट पर शाखाओं के साथ डेटाबेस संशोधन कैसे प्रबंधित करते हैं?

Question

काम पर हमारे पास कुछ अलग-अलग परियोजनाओं पर एक साथ काम करने वाले 4 लोग हैं। प्रत्येक परियोजना के लिए हम प्रत्येक के पास एक स्थानीय प्रतिलिपि होती है जिसे हम काम करते हैं और फिर हमारे पास किसी भी शाखा के साथ विकास, स्टेजिंग और लाइव परिनियोजन होता है (हम सबवर्सन का उपयोग करते हैं)। हमारा डेटाबेस MySQL है।

तो मेरा सवाल यह है कि प्रत्येक तैनाती (और डेवलपर्स के लिए उनकी स्थानीय प्रतियों) के लिए डेटाबेस में कौन से संशोधन किए गए हैं, यह प्रबंधित करने का एक अच्छा तरीका क्या है। अभी प्रत्येक परिवर्तन एक टेक्स्ट फ़ाइल में जाता है जो नाम में टाइमस्टैम्प किया जाता है और प्रोजेक्ट के तहत एक फ़ोल्डर में डाल दिया जाता है। यह ईमानदार होने के लिए बहुत अच्छा काम नहीं कर रहा है .. मुझे एक समाधान की आवश्यकता है जो कि जहां लागू किया गया है उसका ट्रैक रखने में मदद मिलेगी।

Answer 1

यदि आपका डेटाबेस डेटा एक्सेस ऑब्जेक्ट्स के सेट पर अच्छी तरह से मानचित्र करता है, तो 'माइग्रेशन' का उपयोग करने पर विचार करें। विचार है कि प्रत्येक डेटा संस्करण के माध्यम से आगे और पीछे जाने के लिए चरणों के साथ अपने डेटा मॉडल को एप्लिकेशन कोड के रूप में स्टोर करना है।

मुझे विश्वास है कि Rails did it first।

जावा में at least one project है।

और यहां एक .NET migration library है।

संस्करणों को बदलने के लिए, आप एक साधारण स्क्रिप्ट चलाते हैं जो आपको इच्छित संस्करण में लाने के लिए सभी ऊपर या नीचे संस्करणों के माध्यम से कदम उठाता है। इसकी सुंदरता यह है कि, आप अपने माइग्रेशन को उसी स्रोत भंडार में अपने ऐप कोड के रूप में देखते हैं - यह सब एक ही स्थान पर है।

शायद अन्य अन्य माइग्रेशन पुस्तकालयों का सुझाव दे सकते हैं।

चीयर्स।

संपादित करें: https://stackoverflow.com/questions/313/net-migrations-engine और .NET database migration tool roundup (उपरोक्त पोस्ट से) भी देखें।

Answer 2

http://odetocode.com/Blogs/scott/archive/2008/01/30/11702.aspx

ऊपर ब्लॉग हमारे वर्तमान डेटाबेस संस्करण नियंत्रण प्रणाली के लिए हमें ले आया। सीधे शब्दों में कहें, अद्यतन डीक्रिप्ट के बिना कोई डीबी परिवर्तन नहीं किए जाते हैं और सभी अद्यतन स्क्रिप्ट हमारे स्रोत नियंत्रण भंडार में हैं।

हम केवल स्कीमा परिवर्तनों का प्रबंधन करते हैं लेकिन आप संस्करण नियंत्रण में उपलब्ध डेटा के डंप को रखने में भी सक्षम/सक्षम हो सकते हैं; ऐसी फाइलें बनाना mysqldump का उपयोग करके एक बहुत ही छोटा अभ्यास है।

हमारा समाधान ब्लॉग में प्रस्तुत किए गए समाधान से अलग है: यह स्वचालित नहीं है। हमें डेटाबेस अपडेट आदि को लागू करना होगा, हालांकि यह थोड़ा समय लेने वाला हो सकता है, लेकिन कुछ प्रयासों को स्थगित कर दिया गया है, जो पूरी तरह से स्वचालित सिस्टम की आवश्यकता होगी। एक चीज जिसे हमने स्वचालित किया था, सॉफ्टवेयर में डीबी संस्करण ट्रैकिंग था: यह बहुत आसान था और यह सुनिश्चित करता है कि हमारे सॉफ़्टवेयर को उस डेटाबेस के बारे में पता है जो यह चल रहा है और केवल तभी चलाएगा जब यह स्कीमा के साथ काम कर रहा हो।

हमारे समाधान का सबसे कठिन हिस्सा यह था कि हमारी शाखाओं से हमारे ट्रंक में अपडेट कैसे मर्ज करें। हमने एक ही समय में डीबी अपडेट के साथ शाखाओं को मर्ज करने की कोशिश करने और इसे संभालने के लिए दो डेवलपर्स की संभावना को हल करने के लिए वर्कफ़्लो विकसित करने के लिए कुछ समय बिताया। हम अंततः संस्करण नियंत्रण में एक फ़ाइल लॉक करने के लिए बस गए (हमारे लिए प्रश्न में फ़ाइल वास्तव में एक डीबी संस्करण के लिए एक टेबल मैपिंग सॉफ्टवेयर संस्करण है जो हमारी मैन्युअल प्रबंधन रणनीति में सहायता करता है), जैसा कि आप धागे के महत्वपूर्ण खंड में होंगे, और डेवलपर जो प्राप्त करता है ताला ट्रंक के अपने अपडेट के बारे में चला जाता है। पूरा होने पर, दूसरा डेवलपर लॉक करने में सक्षम होगा और यह सुनिश्चित करने के लिए कि उनकी अपेक्षित संस्करण टकराव और अन्य बुरे जुजू से बचा जा सके, उनकी स्क्रिप्ट में आवश्यक परिवर्तन करना उनकी ज़िम्मेदारी है।

Answer 3

हम संस्करण नियंत्रण में हमारी सभी डेटाबेस स्क्रिप्ट (डेटा और स्कीमा/डीडीएल) रखते हैं। हम परिवर्तनों की केंद्रीय सूची भी रखते हैं। जब कोई डेवलपर स्कीमा/डीडीएल फ़ाइल में परिवर्तन करता है या किसी स्क्रिप्ट को जोड़ता है जो किसी भी तरीके से डेटा को बदलता है, तो उन फ़ाइलों को एसवीएन प्रतिबद्ध संख्या के साथ सूची में जोड़ा जाता है।

हमने एक छोटी सी उपयोगिता घर में रखी है जो कैटलॉग में परिवर्तन पढ़ता है और सूची में प्रत्येक संशोधन से सामग्री को पकड़कर और उन्हें लागू करके सूची की सामग्री के आधार पर एक बड़ी अद्यतन स्क्रिप्ट बनाता है। अवधारणा DBDeploy उपकरण के समान ही है, जो मेरा मानना ​​है कि मूल रूप से Thoughtworks से आया है, इसलिए आप इसका उपयोग कर सकते हैं। यह आपको कम से कम शुरू करने के लिए एक अच्छी जगह देगा, जिस बिंदु से आप अपनी आवश्यकताओं के लिए अधिक उपयुक्त समाधान को अनुकूलित कर सकते हैं।

शुभकामनाएँ!