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

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

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

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

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

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

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

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


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


Thanks for the reference to Tarantino. I'm not in a .NET environment, but I found their DataBaseChangeMangement wiki page to be very helpful. Especially this Powerpoint Presentation (.ppt)

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


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

0
ro fr bn
प्रासंगिक: MySQL डेटाबेस को सिंक्रनाइज़ करने के लिए stackoverflow.com/questions/52583/ & hellip;
जोड़ा लेखक Ashwin A, स्रोत

14 उत्तर

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

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

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

0
जोड़ा

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

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

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

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

0
जोड़ा

मैंने एक टूल लिखा है ( ओपन डीबीडीफ में शामिल करके) डेटाबेस स्कीमा की तुलना करता है, और माइग्रेशन का सुझाव देगा आपको स्क्रिप्ट यदि आप कोई परिवर्तन करते हैं जो डेटा को हटा देता है या संशोधित करता है, तो यह एक त्रुटि फेंक देगा, लेकिन स्क्रिप्ट के लिए एक सुझाव प्रदान करेगा (उदाहरण के लिए जब नई स्कीमा में गायब होने वाला कॉलम, यह जांच करेगा कि कॉलम का नाम बदल दिया गया है या xx - जेनरेट किया गया है script.sql.suggestion में एक नामकरण कथन शामिल है)।

http://code.google.com/p/migrationscriptgenerator/ SQL Server only I'm afraid :( It's also pretty alpha, but it is VERY low friction (particularly if you combine it with Tarantino or http://code.google.com/p/simplescriptrunner/)

जिस तरह से मैं इसका उपयोग करता हूं वह आपके एसएसएल में एक एसक्यूएल स्क्रिप्ट प्रोजेक्ट है। आपके पास स्थानीय रूप से एक db_next डेटाबेस भी है जो आप अपने परिवर्तन करते हैं (प्रबंधन स्टूडियो या NHibernate का उपयोग करके स्कीमा निर्यात या LinqToSql CreateDatabase या कुछ)। फिर आप _dev और _next डीबी के साथ migrationscriptgenerator निष्पादित करते हैं, जो बनाता है। भर में माइग्रेट करने के लिए एसक्यूएल अद्यतन स्क्रिप्ट।

0
जोड़ा

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

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

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

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

0
जोड़ा

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

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

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

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

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

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

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

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

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

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

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

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

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

0
जोड़ा

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

0
जोड़ा
मृत लिंक प्रोजेक्ट अब या तो यहां प्रतीत होता है: bitbucket.org/headspringlabs/tarantino/wiki/Home या यहां: github.com/HeadspringLabs/Tarantino
जोड़ा लेखक Lee Richardson, स्रोत

The book Refactoring Databases: Evolutionary Database Design might give you some ideas on how to manage the database. A short version is readable also at http://martinfowler.com/articles/evodb.html

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

0
जोड़ा

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

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

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

0
जोड़ा

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

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

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

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

0
जोड़ा

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

0
जोड़ा

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

  • 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 देखा। आह!

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

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

0
जोड़ा

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

0
जोड़ा