कई डेवलपर्स में डेटाबेस परिवर्तनों को प्रबंधित और कैप्चर कैसे करें?

Question

हमारे पास तीन डेवलपर और एक परीक्षक हैं जो सभी एक ही डेटाबेस के खिलाफ काम करते हैं। हम अक्सर डेटाबेस की स्कीमा बदलते हैं, और हर बार जब हम करते हैं तो यह हर किसी के लिए सिरदर्द का लहर प्रभाव पड़ता है।

क्या एमएस एसक्यूएल सर्वर 2008 के खिलाफ .NET उन्मुख विकास के लिए यह अच्छा प्रथा है? मैं रेल माइग्रेशन के समान कुछ सोच रहा हूं और प्रत्येक देव और परीक्षक का अपना स्थानीय डेटाबेस है। या वह ओवरकिल है? यह कम से कम परीक्षण और देव डेटाबेस रखने के लिए अच्छा होगा, लेकिन वर्तमान में मैन्युअल रूप से दो डेटाबेस को सिंक में रखते हुए हमारे वर्तमान परिस्थिति से भी बदतर है।

LiquiBase आशाजनक प्रतीत होता है, क्या किसी ने सफलतापूर्वक इसी तरह के वातावरण में इसका उपयोग किया है? या क्या बेहतर दृष्टिकोण हैं?

हम SQL Server 2008, VS 2008 और .NET 3.5 का उपयोग कर रहे हैं, यदि यह बिल्कुल मायने रखता है।

Answer 1

हमारे पास स्क्रैच से डीबी उत्पन्न करने के लिए स्क्रिप्ट हैं और यह स्रोत नियंत्रण में बैठी है। प्रत्येक डेवलपर (उनमें से 20) अपने वर्कस्टेशन पर 2 डेटाबेस उत्पन्न करने के लिए स्क्रिप्ट का उपयोग कर रहा है। "काम" के लिए एक - नमूना डेटा के साथ मैन्युअल परीक्षण (नमूना डेटा को पॉप्युलेट करने के लिए स्क्रिप्ट है)। एक और डीबी खाली है और यूनिट परीक्षणों में उपयोग किया जाता है (खुले लेनदेन - यूनिट टेस्ट - रोल बैक)।

बहु डेवलपर वातावरण में यूनिट परीक्षण अनिवार्य है। इसके अलावा हम हमेशा "पुराना" डेटाबेस बनाते हैं और उस पर स्कीमा परिवर्तन लागू करते हैं। प्रत्येक डेवलपर अपग्रेड प्रक्रियाओं को बनाकर स्कीमा बदल रहा है (इस प्रकार हमने एक ही समय में पुनर्निर्माण और अपग्रेड किया है)।

प्रदर्शन परीक्षण के लिए हमारे पास "लोडर" - सी # कोड उपयोगकर्ताओं को अनुकरण करने और डेवलपर वर्कस्टेशन पर रात भर लाखों रिकॉर्ड पॉप्युलेट करने के लिए है।

Answer 2

हम एक उपकरण का उपयोग नहीं करते हैं, लेकिन हम अपने सभी स्कीमा को स्रोत नियंत्रण में रखते हैं और फिर एक ऐसी स्क्रिप्ट है जो स्रोत से डेटाबेस को अपडेट या पुनर्निर्माण करेगी। इस तरह जब परिवर्तन किए जाते हैं तो हम सभी अपडेट और सिंक में रह सकते हैं। यह सिर्फ दैनिक सुबह की दिनचर्या का हिस्सा बन जाता है, बस आपके कोड को सिंक करने की तरह लगभग 5 मिनट लगते हैं। यह सही नहीं है लेकिन यह हमारे लिए काम करता है।

ओह और मैं जोड़ना भूल गया कि क्या आप स्कीमा में बदलाव करते हैं, यदि कोई आवश्यकता हो तो माइग्रेशन स्क्रिप्ट लिखने के लिए आप भी ज़िम्मेदार हैं। जब भी कुछ उत्पादन हो जाता है तब भी इसकी आवश्यकता होती है।

उम्मीद है कि मदद करता है।

Answer 3

ऐसा लगता है कि जब आप अपना डेटाबेस स्टोर करना एक डेटाबेस diff उपकरण की आवश्यकता है ...

Red Gate SQL Compare

Visual Studio Team Database Edition

Answer 4

विजुअल स्टूडियो टीम सिस्टम Database Edition (उर्फ "डाटा Dude") के लायक है में देख। यह डेटाबेस diffs को ट्रैक कर सकता है और परिवर्तनों की स्क्रिप्ट उत्पन्न कर सकता है ताकि आप तैनाती आदि से पहले एक टेस्ट/प्रोड पर्यावरण तैयार कर सकें। मुझे लगता है कि इसकी विशेषताएं विकास संस्करण (पिछली लिंक देखें) में भी उपलब्ध हैं और वीएस 2010 में अधिक दिखाई देगी। इस ब्लॉग पोस्ट पर एक नज़र डालें: First Experience with Visual Studio 2008 Database Edition, I love it!!!

कि, टीएफएस के साथ, आपको संस्करण को SQL फ़ाइलों को नियंत्रित करने और डेटाबेस के विरुद्ध चलाने की क्षमता देता है।

Answer 5

मुझे व्यक्तिगत रूप से लगता है कि अलग-अलग डेटाबेस होना सर्वोत्तम है।एक डेटाबेस के खिलाफ काम करने से बहुत दर्द और अपशिष्ट का कारण बन सकता है।

उदाहरण के लिए, कहें कि मैं एक प्रदर्शन समस्या को देख रहा हूं और मैं डेटाबेस पर कुछ अनुकूलन का परीक्षण करने के लिए कुछ बेंचमार्क परीक्षण चला रहा हूं - एकमात्र तरीका यह है कि आप यह विश्वसनीय तरीके से कर सकते हैं यदि आप अपने परीक्षणों के अनुरूप हैं। अगर कोई और डीबी मिडवे के माध्यम से बदलाव करता है, तो वह आपके निष्कर्ष निकाल सकता है।

प्लस, अगर मैं कुछ के बीच में हूं और डीबी मेरे बिना त्रुटियों/अप्रत्याशित व्यवहार को जानने के बारे में बताता है, तो मैं किसी और को बदलने के कारण यह पता लगाने से पहले एक्स काम कर सकता हूं ने बनाया है।

इसके बजाय, मुझे लगता है कि अपनी खुद की देव/परीक्षण डेटाबेस जिसे आप प्रत्येक को अद्यतन करने के लिए जिम्मेदार हो सकता है ज्यादा बेहतर है। फिर एक निरंतर एकीकरण सर्वर है जो स्वचालित रूप से स्रोत नियंत्रण से नवीनतम कोड खींचता है और इसे हर एक्स घंटे बनाता है। कुछ अच्छे लिंक करने के लिए

Answer 6

एक अच्छा लिंक: http://www.codinghorror.com/blog/2008/02/get-your-database-under-version-control.html

Answer 7

मैं "एक विकास डेटाबेस" शिविर में हूँ।

पारंपरिक OO स्रोत कोड के विपरीत, डेटाबेस अक्सर कई उपयोगकर्ताओं की सुविधाओं का समर्थन तालिकाओं के लिए जा रहा है। जब कई डेवलपर समान परिवर्तन करने जा रहे हैं, तो आप उन्हें पहले से ही काम कर सकते हैं या दो बिल्ड स्क्रिप्ट को सिंक करने का प्रयास कर सकते हैं। निर्माण स्क्रिप्ट और माइग्रेशन के साथ समस्या यह है कि ज्यादातर स्थितियां गैर-तुच्छ होती हैं। डीबी में एनयूएलएल को अनुमति देना चाहते हैं? - आपको यह तय करने की आवश्यकता है कि डेटा को किस प्रकार डिफॉल्ट किया जाना चाहिए और यदि डेटा कहीं और से पॉप्युलेट किया जाना चाहिए। एक तालिका को दो में सामान्य करने के लिए रिफैक्टर की आवश्यकता है? - आपको चाबियाँ असाइन करने का निर्णय लेना होगा। और फिर दो उपयोगकर्ताओं को एक ही मेज पर एक परिवर्तन ...

कि यह नहीं कह रहा है कि यह स्रोत नियंत्रण में नहीं होना चाहिए बनाने क्योंकि यह होना चाहिए के साथ।

आखिरकार आपके पास अधिक डेवलपर्स और अधिक संचार चैनल हैं, तो आप अपने डेटाबेस परिवर्तन को विकास डीबीए के माध्यम से बदलना चाहते हैं - इससे बदलावों को समेकित किया जा सकता है और एक टीम में संचार चैनलों के साथ कई समस्याएं टालती हैं - यह संचार चैनलों को एक स्टार में बदल देता है।

इसके अलावा, यदि आप अपने आप को विचारों और procs संग्रहीत की तरह एक स्पष्ट डेटाबेस सेवाओं परत के खिलाफ प्रोग्रामिंग की सीमा है, आपके आवेदन डेवलपर्स अच्छी तरह से डेटाबेस में परिवर्तन और पुनर्रचना के खिलाफ अछूता जा करने के लिए जा रहे हैं।

विकास में एक निश्चित समय के बाद, डेटाबेस में परिवर्तन, सुंदर प्रबंधनीय बन के बाद से अंतर्निहित आधार तालिका स्कीमा में परिवर्तन कम हैं (हालांकि विचारों और संग्रहीत procs अस्थिर रह सकती है)।