विकास और उत्पादन डेटाबेस?

Question

मैं PHP & mySQL के साथ काम कर रहा हूं। मुझे अंत में स्रोत नियंत्रण के आसपास अपना सिर मिला है और PHP भाग के लिए पूरे विकास (परीक्षण) v उत्पादन v भंडार चीज़ से काफी खुश हूं।

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

कोई विचार किस तरह से जाना है? और, यदि आप बाद वाले को सोचते हैं, तो दो डेटाबेस को समान रखने का सबसे अच्छा तरीका क्या है (डेटा के अलावा, निश्चित रूप से ...)?

Answer 1

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

Answer 2

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

यदि आपके पास डेटा है जिसे लोड करने की आवश्यकता है (कोड टेबल, लुकअप मान, आदि), स्क्रिप्ट जो डाटाबेस निर्माण प्रक्रिया के हिस्से के रूप में डेटा लोड करती है।

सब कुछ पटकथा और इसे स्रोत नियंत्रण में रखते हुए, किसी भी निर्माण स्तर के लिए किसी भी समय डेटाबेस संरचना को पुनर्निर्मित किया जा सकता है।

Answer 3

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

deploy.001.description.sql 
deploy.002.description.sql 
deploy.003.description.sql 
... etc.. 

तब मैं तैनात करते समय क्रम में से प्रत्येक स्क्रिप्ट चलाता हूं।

तब मैं उनकी तरह

\deploy.YYMMDD\ 

नाम वाली निर्देशिका के कुछ में संग्रह और सब कुछ खत्म हो शुरू करते हैं।

यदि मैं कोई गलती करता हूं, तो मैं पिछली तैनाती स्क्रिप्ट पर कभी वापस नहीं जाता, मैं एक नई स्क्रिप्ट तैयार करूंगा और वहां अपना फिक्स डालूंगा।

गुड लक

Answer 4

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

Answer 5

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

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

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

Answer 6

भी

How do you version your database schema?

देखें यह एक आम सवाल है और कहा गया है और कई बार जवाब दे दिया।

थॉमस ओवेन्स: प्रतिकृति संस्करण स्कीमा के लिए उपयोग करने योग्य नहीं है - यह डेटा डुप्लिकेट करने के लिए है। आप देव से उत्पादन या इसके विपरीत कभी भी दोहराना नहीं चाहते हैं।

Answer 7

मुझे एक ही दुविधाएं थीं। मैं सोच रहा था कि production db बनाम development db के बीच एक स्पष्ट डिचोटोमी थी। मैं वे एक सिक्का के दो पक्ष थे और कभी दो बार मिलेंगे।

समस्याओं का एक बहुत गायब हो गया जब मैं "या तोproduction dbयाdevelopment db" के संदर्भ में अपने आवेदन 'लगता है कि' बनाने बंद कर दिए। इसके बजाय मेरा एप्लिकेशन local db का उपयोग करता है।

जब यह मेरी वर्चुअल (देव) मशीन पर चल रहा है, तो स्थानीय डीबी dev db होता है। मेरा आवेदन वास्तव में 'पता' नहीं है कि हालांकि।

तो, मुख्य भाग के लिए, समस्या गायब हो जाती है।

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

यह तब हुआ जब मैंने live-read-only db connection की अवधारणा को जोड़ा। आवेदन अलग-अलग व्यवहार करता है। यह थोड़ा सा है कि आपका एप्लिकेशन Google Apps जैसी वेब सेवा का इलाज कैसे कर सकता है। इसका 'कुछ बाहरी संसाधन जो आपका ऐप उपयोग करता है'।

डिफ़ॉल्ट रूप से मेरा ऐप local db का उपयोग करता है और कुछ बहुत ही विशेष स्थितियों (परीक्षण सूट में) में यह live-readonly db का भी उपयोग करता है। (क्योंकि यह केवल पढ़ने के लिए कनेक्शन है, परीक्षण के दौरान लाइव डेटा की गड़बड़ी करने से मुझे डर नहीं है)।

तो बजाय सवाल "dev dbयाproduction db?", मेरे ऐप "local dbयाlive-read-only db" पूछता है पूछ।

स्पष्ट रूप से मेरी स्थिति आपके लिए अलग हो सकती है, लेकिन मुझे यह समझने में 'सफलता में सफलता' मिली है जो मेरे लिए सबसे उपयोगी है।