डेटाबेस परिवर्तनों को सत्यापित करें (संस्करण-नियंत्रण)

Question

मैंने डेटाबेस संस्करण नियंत्रण के महत्व के बारे में बहुत सी पोस्ट पढ़ी हैं। हालांकि, मुझे यह पता लगाने के लिए एक सरल समाधान नहीं मिला कि डाटाबेस राज्य में है या नहीं।

उदाहरण के लिए, मेरे पास "संस्करण" नामक एक तालिका वाला डेटाबेस है (संस्करण संख्या वहां संग्रहित की जा रही है)। लेकिन डेटाबेस को संस्करण संख्या को बदले बिना डेवलपर्स द्वारा एक्सेस और संपादित किया जा सकता है। यदि उदाहरण के लिए डेवलपर संग्रहित प्रक्रिया अद्यतन करता है और अद्यतन नहीं करता है तो संस्करण डेटाबेस स्थिति संस्करण मान के साथ समन्वयित नहीं है।

उन परिवर्तनों को कैसे ट्रैक करें? मुझे यह बदलने की ज़रूरत नहीं है कि क्या बदला गया है, लेकिन केवल यह जांचने की आवश्यकता है कि डेटाबेस टेबल, विचार, प्रक्रियाएं इत्यादि डेटाबेस संस्करण में सहेजे गए डेटाबेस संस्करण के साथ समन्वयित हैं या नहीं।

मुझे इसकी आवश्यकता क्यों है? तैनाती करते समय मुझे यह जांचना होगा कि डेटाबेस "सही" है। साथ ही, सभी टेबल या अन्य डेटाबेस ऑब्जेक्ट्स को ट्रैक नहीं किया जाना चाहिए। क्या ट्रिगर्स का उपयोग किए बिना जांचना संभव है? क्या यह तीसरे पक्ष के उपकरण के बिना किया जा सकता है? क्या डेटाबेस में चेकसम हैं? - हम आधार बनाने के लिए आवश्यक सभी स्क्रिप्ट के साथ एक "आधारभूत" है

मुझे लगता है कि मैं हमारे वर्तमान पर्यावरण के बारे में कुछ और जानकारी प्रदान करना चाहिए:

का कहना है कि हम एसक्यूएल सर्वर का उपयोग 2005

संपादित करने देता है संस्करण (हमारे ऐप के लिए डेटा ऑब्जेक्ट्स और "मेटाडेटा" शामिल है)। हालांकि, कुछ अतिरिक्त डेटाबेस ऑब्जेक्ट्स (अतिरिक्त तालिकाओं, विचारों, प्रक्रियाओं, आदि) के साथ इस "बेस" संस्करण की कई स्थापनाएं हैं। जब हम "बेस" संस्करण में कुछ बदलाव करते हैं तो हमें कुछ इंस्टॉलेशन (सभी नहीं) को अपडेट करना होगा - उस समय हमें यह जांचना होगा कि "आधार" सही स्थिति में है।

धन्यवाद

Answer 1

मैं/ड्रॉप उत्पन्न सभी डेटाबेस ऑब्जेक्ट्स के लिए स्क्रिप्ट बनाने के लिए this codeproject article के आधार पर एक सरल VBScript फ़ाइल का उपयोग कर रहा हूँ। मैं फिर इन स्क्रिप्ट को संस्करण नियंत्रण में डालता हूं।

• /ड्रॉप का नवीनतम संस्करण प्राप्त संस्करण से स्क्रिप्ट बनाने के लिए:

  तो है कि क्या एक डेटाबेस अप करने की तारीख है या परिवर्तन जो अभी तक संस्करण नियंत्रण में डाल नहीं कर रहे थे है, मैं यह कर जांच करने के लिए नियंत्रण (हमारे मामले में तोड़फोड़)

• SqlExtract स्क्रिप्ट को निष्पादित करने के लिए डेटाबेस जांच की जानी, संस्करण नियंत्रण से स्क्रिप्ट
• अधिलेखन अब मैं अपने तोड़फोड़ ग्राहक (TortoiseSVN) जो फ़ाइलों संस्करण के साथ मेल नहीं खाते से सलाह ले सकते संस्करण नियंत्रण के तहत
• n ow या तो डेटाबेस को अद्यतन करें या संशोधित स्क्रिप्ट को संस्करण नियंत्रण

Answer 2

हम डेटाबेस नियंत्रण संस्करण के लिए DBGhost का उपयोग करते हैं। वर्तमान डेटाबेस बनाने के लिए स्क्रिप्ट TFS (स्रोत कोड के साथ) में संग्रहीत हैं और फिर डीबीजीहोस्ट का उपयोग मौजूदा संस्करण में वातावरण को अपग्रेड करने के लिए डेल्टा स्क्रिप्ट उत्पन्न करने के लिए किया जाता है। डीबीगोस्ट किसी भी स्थिर/संदर्भ/कोड डेटा के लिए डेल्टा स्क्रिप्ट भी बना सकता है।

इसे पारंपरिक विधि से दिमागी बदलाव की आवश्यकता है लेकिन यह एक शानदार समाधान है जिसे मैं पर्याप्त अनुशंसा नहीं कर सकता। हालांकि यह एक तृतीय पक्ष उत्पाद है, यह हमारे स्वचालित निर्माण और तैनाती प्रक्रिया में सहजता से फिट बैठता है।

Answer 3

पहला बिंदु: "नियम" के बिना चीजों को क्रम में रखना मुश्किल है। या आपके उदाहरण के लिए - डेवलपर्स बिना किसी सूचना के कुछ भी बदल रहे हैं, आपको गंभीर समस्याएं लाएंगे।

किसी भी तरह - आप "ट्रिगर का उपयोग किए बिना" कहते हैं। इसके लिए कोई विशिष्ट कारण?

यदि नहीं - डीडीएल ट्रिगर देखें। ऐसा कुछ ट्रिगर यह जांचने का सबसे आसान तरीका है कि कुछ हुआ या नहीं।

और आप यह भी लॉग कर सकते हैं कि क्या चल रहा था।

Answer 4

उम्मीद है कि किसी को इस से एक बेहतर समाधान है, लेकिन मैं इस एक जोड़े तरीकों का उपयोग कर कार्य करें:

• एक "ट्रंक" डेटाबेस, वर्तमान विकास संस्करण है जो लो। सभी काम यहां किए गए हैं क्योंकि इसे रिलीज में शामिल करने के लिए तैयार किया जा रहा है।
• हर बार एक रिलीज किया जाता है:
  • अंतिम रिलीज के "साफ" डेटाबेस, नया एक कॉपी किया जाता है जैसे, "DB_1.0.4_clean"
  • SQL-Compare के ट्रंक से परिवर्तनों को कॉपी करने के लिए प्रयोग किया जाता है 1.0.4_clean - यह भी जांचने की अनुमति देता है कि क्या शामिल हो जाता है।
  • एसक्यूएल तुलना का उपयोग पिछले और नए रिलीज (डीबी_1.0.4_clean से डीबी_1.0.3_clean में परिवर्तन) के बीच अंतर खोजने के लिए फिर से किया जाता है, जो एक परिवर्तन स्क्रिप्ट "1.0.3 से 1.0.4.sql" बनाता है।

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

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

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

एसक्यूएल तुलना के बारे में अच्छी बात यह है कि यह उत्पन्न होने वाली स्क्रिप्ट एक लेनदेन में है - और अगर यह विफल हो जाती है, तो यह पूरी चीज को वापस ले जाती है। तो अगर उत्पादन डीबी को किसी तरह से संशोधित किया गया है, तो अपग्रेड विफल हो जाएगा, और फिर तैनाती टीम वास्तव में _clean डीबी के खिलाफ उत्पादन डीबी पर SQL तुलना का उपयोग कर सकती है, और मैन्युअल रूप से परिवर्तनों को ठीक कर सकती है। हमें केवल इसे एक या दो बार करना है (लानत ग्राहक)।

एसक्यूएल परिवर्तन स्क्रिप्ट (एसक्यूएल तुलना द्वारा उत्पन्न) हमारे संस्करण नियंत्रण प्रणाली (उपवर्तन) में संग्रहीत हो जाते हैं।

Answer 5

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

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

यदि आप एक एसवीएन/नेंट शैली उपयोगकर्ता (या समान) हैं आपके भंडार में एकल शाखा अवधारणा तब आप इस विषय पर डॉटनेट स्लैकर्स पर अपने लेख पढ़ सकते हैं: http://dotnetslackers.com/articles/aspnet/Building-a-StackOverflow-inspired-Knowledge-Exchange-Build-automation-with-NAnt.aspx और http://dotnetslackers.com/articles/aspnet/Building-a-StackOverflow-inspired-Knowledge-Exchange-Continuous-integration-with-CruiseControl-NET.aspx।

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

अद्यतन

@Sazug: "हाँ, हम जब हम पूरा लेख के बिना आधार स्क्रिप्ट + अतिरिक्त स्क्रिप्ट का उपयोग :) स्वचालन की इस प्रकार की किसी भी के लिए बुनियादी युक्तियाँ बनाता बहु शाखा के कुछ प्रकार का उपयोग करें"

• आप एक नया गैर-उत्पादन प्रकार के माहौल में डीबी (केवल सक्रिय देव)
• उत्पादन परिवेश के रूप में आप

विकसित जहां लाइव डेटा जमा है पर नियंत्रण: वहाँ सबसे अधिक डेटाबेस के दो प्रकार हैं

पहला सेट अप बहुत आसान है और इसे देव से प्रोड से पूरी तरह से स्वचालित किया जा सकता है और यदि आवश्यकता हो तो रोलिंग बैक प्रोड को शामिल किया जा सकता है। इसके लिए आपको बस एक स्क्रिप्ट फ़ोल्डर की आवश्यकता है जहां आपके डेटाबेस में प्रत्येक संशोधन को .sql फ़ाइल में बनाए रखा जा सकता है। मैं सुझाव नहीं देता कि आप एक tablename.sql फ़ाइल रखें और उसके बाद संस्करण की तरह आप एक .cs फ़ाइल करेंगे जहां उस एसक्यूएल आर्टिफैक्ट के अपडेट वास्तव में समय के साथ उसी फ़ाइल में संशोधित किए जाते हैं। यह देखते हुए कि एसक्यूएल वस्तुएं एक दूसरे पर इतनी भारी निर्भर हैं। जब आप स्क्रैच से अपना डेटाबेस बनाते हैं तो आपकी स्क्रिप्ट में ब्रेकिंग बदलाव हो सकता है। इस कारण से मैं सुझाव देता हूं कि आप फ़ाइल नाम के सामने अनुक्रम संख्या के साथ प्रत्येक संशोधन के लिए एक अलग और नई फ़ाइल रखें। उदाहरण के लिए 000024-ModifiedAccountsTable.sql जैसे कुछ। फिर आप 000001-fileName.sql से अंतिम फ़ाइल तक रिक्त डेटाबेस के विरुद्ध अपनी सभी स्क्रिप्ट चलाने के लिए NANTContrib से बाहर एक कस्टम कार्य या कुछ का उपयोग कर सकते हैं? SQL.exe कमांड लाइन टूल्स का प्रत्यक्ष निष्पादन UpdateScripts फ़ोल्डर में। इन सभी स्क्रिप्ट को तब आपके संस्करण नियंत्रण में चेक किया जाता है। और चूंकि आप हमेशा एक स्वच्छ डीबी से शुरू करते हैं, तो अगर आप किसी नए एसक्यूएल बिल्ड को तोड़ते हैं तो आप हमेशा वापस रोल कर सकते हैं।

दूसरे पर्यावरण में स्वचालन हमेशा सबसे अच्छा मार्ग नहीं है क्योंकि आप उत्पादन को प्रभावित कर सकते हैं। यदि आप उत्पादन वातावरण के लिए सक्रिय रूप से विकास कर रहे हैं तो आपको वास्तव में एक बहु-शाखा/पर्यावरण की आवश्यकता है ताकि आप वास्तव में प्रोड पर्यावरण के खिलाफ धक्का देने से पहले अपने स्वचालन तरीके का परीक्षण कर सकें। जैसा कि ऊपर बताया गया है आप उसी अवधारणाओं का उपयोग कर सकते हैं। हालांकि, आप वास्तव में प्रोड डीबी पर स्क्रैच से शुरू नहीं कर सकते हैं और पीछे रोलिंग करना अधिक कठिन है। इस कारण से मैं आपके निर्माण प्रक्रिया में समान की तुलना में RedGate SQL तुलना का उपयोग करने का सुझाव देता हूं। अद्यतनों को अद्यतन करने के लिए .sql स्क्रिप्ट की जांच की जाती है लेकिन अपडेट चलाने से पहले आपको अपने स्टेजिंग डीबी और प्रोड डीबी के बीच एक अंतर स्वचालित करने की आवश्यकता होती है। फिर आप समस्याएं सिंक करने का प्रयास कर सकते हैं और यदि समस्याएं होती हैं तो वापस रोल करें। इसके अलावा, एसक्यूएल परिवर्तनों के स्वचालित धक्का से पहले बैक अप का कुछ रूप लिया जाना चाहिए। उत्पादन में सतर्क मानव आंख के बिना कुछ भी करने पर सावधान रहें! यदि आप अपने सभी देव/योग्य/स्टेजिंग/प्रदर्शन वातावरण में निरंतर एकीकरण करते हैं और फिर उत्पादन को दबाते समय कुछ मैन्युअल कदम उठाते हैं ... वास्तव में वह बुरा नहीं है!

Answer 6

यदि आपके पास विजुअल स्टूडियो (विशेष रूप से डेटाबेस संस्करण) है, तो Database Project है जिसे आप इसे SQL सर्वर डेटाबेस में बना और इंगित कर सकते हैं। परियोजना स्कीमा लोड करेगी और मूल रूप से आपको कई अन्य सुविधाएं प्रदान करेगी। यह एक कोड प्रोजेक्ट की तरह व्यवहार करता है। यह आपको पूरी तालिका और सामग्रियों को स्क्रिप्ट करने का लाभ भी प्रदान करता है ताकि आप इसे सबवर्जन के तहत रख सकें। जब आप प्रोजेक्ट बनाते हैं, तो यह मान्य करता है कि डेटाबेस में अखंडता है। यह काफी स्मार्ट है।

Answer 7

हमारी परियोजनाओं में से एक पर हमने डाटाबेस के अंदर डेटाबेस संस्करण संग्रहीत किया था।

डेटाबेस संरचना में प्रत्येक परिवर्तन को अलग-अलग एसक्यूएल फ़ाइल में लिखा गया था जो अन्य सभी परिवर्तनों के अलावा डेटाबेस संस्करण में वृद्धि हुई थी। यह डेवलपर द्वारा किया गया था जिसने डीबी संरचना बदल दी।

वर्तमान डीबी संस्करण और नवीनतम परिवर्तन स्क्रिप्ट के खिलाफ तैनाती स्क्रिप्ट की जांच की गई और यदि आवश्यक हो तो इन एसक्यूएल स्क्रिप्ट को लागू किया गया।

Answer 8

आप "Three rules for database work" के पहले और दूसरे नियम को तोड़ने लगते हैं। प्रति डेवलपर एक डेटाबेस का उपयोग करना और आपकी स्कीमा के लिए एक आधिकारिक स्रोत पहले से ही बहुत मदद करेगा। फिर, मुझे यकीन नहीं है कि आपके डेटाबेस के लिए Baseline है और यह भी महत्वपूर्ण है कि आप change scripts का उपयोग कर रहे हैं। अंत में, आपको Views, Stored Procedures and the Like और Branching and Merging में कुछ अन्य उत्तर मिल सकते हैं।

दरअसल, ये सभी लिंक जेफ एटवुड से इस महान लेख में उल्लिखित हैं: Get Your Database Under Version Control। एक आईएमएचओ पढ़ना चाहिए।

Answer 9

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

किसी भी प्रणाली में परिवर्तन-नियंत्रण महत्वपूर्ण है जिसे आप काम करने की उम्मीद करते हैं (जहां पूरे सिस्टम में 1 इंजीनियर शामिल है)।

प्रत्येक डेवलपर के पास अपनी स्वयं की टेस्ट सिस्टम होनी चाहिए; अगर वे उसमें बदलाव करना चाहते हैं, तो वे कर सकते हैं, लेकिन सिस्टम टेसिंग को अधिक नियंत्रित, सिस्टम टेस्ट सिस्टम पर किया जाना चाहिए जिसमें उत्पादन के रूप में समान परिवर्तन लागू होते हैं - यदि आप ऐसा नहीं करते हैं, तो आप रिलीज़ पर भरोसा नहीं कर सकते काम कर रहे हैं क्योंकि उन्हें एक असंगत वातावरण में परीक्षण किया जा रहा है।

जब एक परिवर्तन किया है, उचित स्क्रिप्ट बनाई जानी चाहिए और सुनिश्चित करें कि वे वर्तमान संस्करण के शीर्ष पर सफाई से लागू परीक्षण किया है, और रोलबैक * काम करता है कि

* यदि आप रोलबैक स्क्रिप्ट, सही लिख रहे हैं?

Answer 10

मैं अन्य पदों से सहमत हूं कि डेवलपर्स को उत्पादन डेटाबेस को बदलने की अनुमति नहीं होनी चाहिए। या तो डेवलपर्स को एक सामान्य विकास डेटाबेस साझा करना चाहिए (और एक दूसरे के पैर की अंगुली पर चलने का जोखिम) या उनके पास अपने व्यक्तिगत डेटाबेस होना चाहिए। पूर्व मामले में आप एसक्यूएल जैसे टूल का उपयोग उत्पादन में तैनात करने के लिए तुलना कर सकते हैं। बाद के मामले में, आपको उत्पादन को बढ़ावा देने से पहले विकास जीवन चक्र के दौरान समय-समय पर डेवलपर डेटाबेस को सिंक करना होगा।

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

http://www.red-gate.com/Products/SQL_Source_Control/index.htm

Answer 11

मैं पोस्ट के बाकी के साथ सहमत होना होगा। डाटाबेस एक्सेस प्रतिबंध उत्पादन पर मुद्दे को हल करेंगे। फिर डीबीगोस्ट या DVC जैसे वर्जनिंग टूल का उपयोग करने से आपको और बाकी टीम डेटाबेस डेटाबेस