mysql - आप विकास, परीक्षण और उत्पादन में डेटाबेस कैसे प्रबंधित करते हैं?




svn (13)

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

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

मुझे डेटाबेस स्कीमा और विकास, परीक्षण और उत्पादन सर्वर के बीच डेटा को प्रबंधित करने के अच्छे उदाहरण खोजने का प्रयास करने में कठिनाई हुई है।

यहां हमारा सेटअप है। प्रत्येक डेवलपर में एक वर्चुअल मशीन है जो हमारे ऐप और MySQL डेटाबेस चला रही है। जो कुछ भी वे चाहते हैं वह करने के लिए यह उनका व्यक्तिगत सैंडबॉक्स है। वर्तमान में, डेवलपर SQL स्कीमा में बदलाव करेंगे और डेटाबेस की डंप को एक टेक्स्ट फ़ाइल में करेंगे जो वे एसवीएन में करते हैं।

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

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

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

यदि समस्या सिर्फ स्कीमा थी, तो यह एक आसान समस्या होगी, लेकिन डेटाबेस में "आधार" डेटा है जो विकास के दौरान अद्यतन किया गया है, जैसे सुरक्षा और अनुमति तालिकाओं में मेटा-डेटा।

निरंतर एकीकरण और एक-चरण-निर्माण की ओर बढ़ने में यह सबसे बड़ा बाधा है। आप इसे कैसे हल करते हैं?

एक फॉलो-अप प्रश्न: आप डेटाबेस संस्करणों को कैसे ट्रैक करते हैं ताकि आपको पता चल सके कि किसी दिए गए डेटाबेस इंस्टेंस को अपग्रेड करने के लिए कौन सी स्क्रिप्ट चलाना है? क्या लांस जैसी संस्करण तालिका मानक प्रक्रिया के नीचे उल्लेख करती है?

टारनटिनो के संदर्भ के लिए धन्यवाद। मैं .NET पर्यावरण में नहीं हूं, लेकिन मुझे उनके डेटाबेस चेंज मैनेजमेंट विकी पेज को बहुत उपयोगी पाया गया है। विशेष रूप से यह पावरपॉइंट प्रेजेंटेशन (.ppt)

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

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


हम कमांड लाइन mysql-diff का उपयोग कर रहे हैं: यह दो डेटाबेस स्कीमा (लाइव डीबी या स्क्रिप्ट से) के रूप में ALTER स्क्रिप्ट के रूप में एक अंतर उत्पन्न करता है। mysql-diff को एप्लिकेशन प्रारंभ पर निष्पादित किया जाता है, और यदि स्कीमा बदल जाती है, तो यह डेवलपर को रिपोर्ट करती है। इसलिए डेवलपर्स को मैन्युअल रूप से ALTER लिखने की आवश्यकता नहीं है, स्कीमा अपडेट अर्द्ध स्वचालित रूप से होते हैं।


dbdeploy , जावा और .NET उपकरण पहले से उपलब्ध हैं, आप SQL फ़ाइल लेआउट और स्कीमा संस्करण तालिका के लिए अपने मानकों का पालन कर सकते हैं और अपना पायथन संस्करण लिख सकते हैं।


कुछ अच्छे विकल्प हैं। मैं "बैकअप पुनर्स्थापित" रणनीति का उपयोग नहीं करता।

  1. अपने सभी स्कीमा परिवर्तनों को स्क्रिप्ट करें, और अपने सीआई सर्वर डेटाबेस पर उन स्क्रिप्ट को चलाएं। वर्तमान डेटाबेस संस्करण का ट्रैक रखने के लिए एक संस्करण तालिका है, और केवल स्क्रिप्ट निष्पादित करें यदि वे एक नए संस्करण के लिए हैं।

  2. माइग्रेशन समाधान का प्रयोग करें। ये समाधान भाषा से भिन्न होते हैं, लेकिन .NET के लिए मैं Migrator.NET का उपयोग करता हूं। यह आपको अपने डेटाबेस को संस्करणित करने और संस्करणों के बीच ऊपर और नीचे जाने की अनुमति देता है। आपकी स्कीमा सी # कोड में निर्दिष्ट है।


मुझे डर है कि मैं अन्य पोस्टरों के साथ समझौता कर रहा हूं। डेवलपर्स को अपने बदलावों को स्क्रिप्ट करने की आवश्यकता है।

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

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

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


ऑरैकल डेटाबेस के लिए हम oracle-ddl2svn उपकरण का उपयोग करते हैं

यह टूल अगली प्रक्रिया स्वचालित है

  1. प्रत्येक डीबी योजना के लिए योजना डीडीएल प्राप्त करें
  2. इसे संस्करण contol के तहत डाल दिया

मैन्युअल रूप से हल किए गए उदाहरणों के बीच परिवर्तन


यदि आप .NET पर्यावरण में हैं तो समाधान Tarantino । यह एनएएनटी निर्माण में यह सब (जिसमें एसक्यूएल स्क्रिप्ट स्थापित करने के लिए) शामिल हैं।


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

  • dbChanges_1.sql
  • dbChanges_2.sql
  • ...
  • dbChanges_n.sql

यह तब तक काफी अच्छा काम करता है जब तक हम विकास की दो पंक्तियों को बनाए रखना शुरू नहीं करते: नए विकास के लिए ट्रंक / मेनलाइन, और बग फिक्स, शॉर्ट टर्म एन्हांसमेंट इत्यादि के लिए रखरखाव शाखा अनिवार्य रूप से, शाखा में स्कीमा में बदलाव करने की आवश्यकता उत्पन्न हुई। इस बिंदु पर, हमारे पास ट्रंक में पहले से ही dbChanges_n + 1.sql था, इसलिए हम निम्नलिखित योजनाओं के साथ आगे बढ़ गए:

  • dbChanges_n.1.sql
  • dbChanges_n.2.sql
  • ...
  • dbChanges_n.3.sql

दोबारा, यह काफी अच्छा काम करता था, जब तक हम एक दिन तक नहीं देखते थे और मुख्य लाइन में 42 डेल्टा स्क्रिप्ट और शाखा में 10 देखे थे। आह!

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

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


पुस्तक रिफैक्टरिंग डेटाबेस: इवोल्यूशनरी डाटाबेस डिज़ाइन आपको डेटाबेस को प्रबंधित करने के तरीके पर कुछ विचार दे सकता है। http://martinfowler.com/articles/evodb.html पर एक छोटा संस्करण भी पठनीय है

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


हमारे पास ओपी के लिए एक बहुत ही समान सेटअप है।

डेवलपर्स निजी डीबी के साथ वीएम में विकसित होते हैं।

[डेवलपर्स जल्द ही निजी शाखाओं में काम करेंगे]

परीक्षण विभिन्न मशीनों पर चलाया जाता है (वास्तव में सर्वर पर होस्ट किए गए वीएम में) [जल्द ही हडसन सीआई सर्वर द्वारा चलाया जाएगा]

संदर्भ डंप को डीबी में लोड करके परीक्षण करें। डेवलपर्स स्कीमा पैच लागू करें, फिर डेवलपर्स डेटा पैच लागू करें

फिर यूनिट और सिस्टम परीक्षण चलाएं।

ग्राहकों को इंस्टॉलर के रूप में उत्पादन तैनात किया जाता है।

हम क्या करते हैं:

हम अपने सैंडबॉक्स डीबी का एक स्कीमा डंप लेते हैं। फिर एक एसक्यूएल डेटा डंप। हम पिछले आधार रेखा से भिन्न हैं। डेल्टा की जोड़ी एन -1 से एन को अपग्रेड करना है।

हम डंप और डेल्टा को कॉन्फ़िगर करते हैं।

तो संस्करण एन क्लीन स्थापित करने के लिए हम एक खाली डीबी में डंप चलाते हैं। पैच करने के लिए, हस्तक्षेप पैच लागू करें।

(जुहा ने वर्तमान डीबी संस्करण को रिकॉर्ड करने वाली टेबल रखने के रेल के विचार का उल्लेख किया है और इसे अद्यतनों को कम से कम अद्यतन करना चाहिए।)

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


रेलवे पर रूबी यह कैसे करता है इस पर एक नज़र डालें।

सबसे पहले माइग्रेशन फाइलें हैं, जो मूल रूप से डेटाबेस स्कीमा और संस्करण एन से संस्करण एन + 1 में डेटा बदलती हैं (या संस्करण एन + 1 से एन तक डाउनग्रेड करने के मामले में)। डेटाबेस में टेबल है जो वर्तमान संस्करण बताता है।

परीक्षण डेटाबेस हमेशा यूनिट-परीक्षण से पहले साफ हो जाते हैं और फ़ाइलों से निश्चित डेटा के साथ आते हैं।


  • निम्नानुसार अपने डेटाबेस नाम दें - db_dev, db_test, db_qa, db_prod (जाहिर है आपको हार्डकोड डीबी नाम कभी नहीं चाहिए
  • इस प्रकार आप एक ही भौतिक सर्वर पर विभिन्न प्रकार के डीबी को तैनात करने में सक्षम होंगे (मैं इसका पुनर्मूल्यांकन नहीं करता हूं, लेकिन आपको संसाधनों को तंग कर सकते हैं)
  • सुनिश्चित करें कि आप स्वचालित रूप से उन लोगों के बीच डेटा स्थानांतरित करने में सक्षम होंगे
  • जनसंख्या से डीबी निर्माण स्क्रिप्ट को अलग करें = डीबी को स्क्रैच से फिर से बनाना और इसे पॉप्युलेट करना हमेशा संभव होना चाहिए (पुराने डीबी संस्करण या बाहरी डेटा स्रोत से
  • कोड में हार्डकोड कनेक्शन स्ट्रिंग का उपयोग न करें (कॉन्फ़िगरेशन फाइलों में भी नहीं) - कॉन्फ़िगरेशन फाइल कनेक्शन स्ट्रिंग टेम्पलेट्स में उपयोग करें, जो आप गतिशील रूप से पॉप्युलेट करते हैं, एप्लिकेशन_लेयर की प्रत्येक पुनर्गठन जिसे पुनः संयोजित करने की आवश्यकता होती है वह है
  • डाटाबेस वर्जनिंग और डीबी ऑब्जेक्ट्स वर्जनिंग का उपयोग करें - यदि आप अपने आप को कुछ विकसित नहीं करते हैं, तो आप इसे तैयार उत्पादों का उपयोग कर सकते हैं
  • प्रत्येक डीडीएल परिवर्तन को ट्रैक करें और इसे कुछ इतिहास तालिका में सहेजें ( उदाहरण यहां )
  • दैनिक बैकअप! परीक्षण करें कि आप कितनी तेजी से बैकअप से खोए गए कुछ को पुनर्स्थापित करने में सक्षम होंगे (automathic पुनर्स्थापित स्क्रिप्ट का उपयोग करें
  • यहां तक ​​कि आपके DEV डेटाबेस और PROD में बिल्कुल वही सृजन स्क्रिप्ट है जिसमें आपको डेटा के साथ समस्याएं होंगी, इसलिए डेवलपर्स को प्रोड की सटीक प्रतिलिपि बनाने और इसके साथ खेलने की अनुमति दें (मुझे पता है कि मुझे इसके लिए माइनस मिलेगा, लेकिन इसमें परिवर्तन मानसिकता और व्यवसाय प्रक्रिया आपको प्रशंसकों को हिट करते समय बहुत कम खर्च करेगी - इसलिए कोडर को कानूनी रूप से जो कुछ भी बनाता है उसे सब्सक्राइब करने के लिए मजबूर करें, लेकिन यह सुनिश्चित करें कि यह एक

मैं Navicat नामक सॉफ़्टवेयर का एक टुकड़ा उपयोग करता हूं:

  • मेरे डेटाबेस डेटाबेस में लाइव डेटाबेस सिंक करें।
  • दो डेटाबेस के बीच अंतर दिखाएं।

यह पैसा खर्च करता है, यह केवल विंडोज़ और मैक है, और यह एक बेकार यूआई मिला है, लेकिन मुझे यह पसंद है।





mysql svn