पृष्ठभूमि
मैं भविष्य में टीम को विकसित करने की स्पष्ट क्षमता के साथ, लगभग 4 प्रोग्रामर और 4 डिजाइनरों की एक छोटी वेब टीम के लिए एक नई विकास प्रक्रिया बनाने पर काम कर रहा हूं। हमारा उत्पाद एक केंद्रीय अनुप्रयोग है जो क्लाइंट वेबसाइटों को शक्ति देता है जिसे हम डिज़ाइन और होस्ट भी करते हैं।
पहले, हम सभी एक देव सर्वर पर FTP के माध्यम से काम करते थे, एक एकल देव डेटाबेस के साथ। यह कुछ समय के लिए "काम" * करता है , लेकिन हम एक नई दिशा में बढ़ रहे हैं, इसलिए यह हमारी प्रक्रिया को परिपक्व करने का समय है।
हम Percona सर्वर 5.5 का उपयोग करते हैं, लेकिन यह लागत कम रखने के विचार के साथ डेटाबेस अज्ञेयवादी होना चाहिए।
लक्ष्य :
मैं निम्नलिखित के साथ डेटाबेस विकास के लिए एक निरंतर एकीकरण (CI) प्रक्रिया बनाने की कोशिश कर रहा हूं:
- डेवलपर्स के पास विकास कोड चलाने के लिए डेटा की स्थानीय प्रति है
- पिछले बदलाव के लिए डेटाबेस संरचना को रोलबैक करने में सक्षम
- नई सुविधा स्कीमा परिवर्तन बनाम स्कीमा डिज़ाइन फ़िक्स परिवर्तनों को अलग करने में सक्षम
- परीक्षण के लिए स्थानीय स्तर पर डेटाबेस संरचना को संशोधित करने में सक्षम
प्रारंभिक अवधारणा
मैंने SVN और LiquiBase का उपयोग करके नीचे एक प्रक्रिया को छोड़ दिया है, हालांकि यह पूरी तरह से हटा देता है #4।
- ट्रंक से 'विकास' शाखा बनाएँ
- केंद्रीय 'विकास' डीबी सर्वर 'विकास' शाखा से चलता है
- स्थानीय डेवलपर्स को विकास शाखा के गुलाम के रूप में स्थापित किया जाता है (
#1ऊपर प्रदान करता है)- शराबीबेज परिवर्तन नियमित रूप से विकास शाखा के लिए प्रतिबद्ध हैं, जो केंद्रीय विकास डेटाबेस (जो इस विकास सर्वर के दास के रूप में चल रही स्थानीय मशीनों को नीचे गिरा देगा) को अद्यतन करने के लिए एक पोस्ट-कम हुक निष्पादित करता है (शराबी
#2ऊपर प्रदान करता है)- जब सुविधाएँ या स्कीमा फ़िक्सेस QA पर जाने के लिए तैयार हैं, तो DBA (me) विकास शाखा से उपयुक्त परिवर्तनों को ट्रंक में मिला देगा। यह अधिनियम एक स्टेजिंग डेटाबेस सर्वर पर लागू करने के लिए एक sql स्क्रिप्ट बनाएगा।
- स्टेजिंग सर्वर को TRUNK को प्रतिबिंबित करना चाहिए, जिसमें उत्पादन के समान संरचना होनी चाहिए, साथ ही QA में होने वाले परिवर्तन भी
- स्टेजिंग सर्वर पर sql स्क्रिप्ट निष्पादित करने के बाद, परिवर्तनों पर कुछ QA करें।
- यदि सभी अच्छे लगते हैं, तो संरचना को TAG करें। यह DBA द्वारा मैन्युअल रूप से उत्पादन में चलाने के लिए .sql स्क्रिप्ट उत्पन्न करेगा (यदि आवश्यक हो तो ऑफ-पीक घंटे के लिए)
इस प्रक्रिया के लिए आवश्यक है कि सभी डेवलपर्स एक ही 'विकास' शाखा को चलाएं, जिसका अर्थ है कि किसी भी समय डेटाबेस स्कीमा का केवल एक संस्करण है (यह सुनिश्चित नहीं है कि मुझे यह चाहिए)।
इसका यह भी अर्थ है कि स्कीमा में किसी भी बदलाव का स्थानीय स्तर पर परीक्षण नहीं किया जा सकता है और यदि सही नहीं किया जाता है तो अन्य डेवलपर्स को प्रभावित कर सकता है। हमारे वातावरण में, डेवलपर्स नए तालिकाओं को जोड़ सकते हैं लेकिन शायद ही कभी मौजूदा संरचना को संशोधित करते हैं। डीबीए के रूप में, डिज़ाइन फ़िक्स मेरे द्वारा किया जाता है। लेकिन स्थानीय स्तर पर फिक्स का परीक्षण करने में असमर्थता मेरी प्रक्रिया का सबसे बड़ा हैंगअप है।
स्थानीय विकास की अनुमति देने के लिए उपरोक्त प्रक्रिया को कैसे बदला जा सकता है, जबकि अभी भी डेटा की अपेक्षाकृत अद्यतित प्रतिलिपि बनाए रखता है (जैसा कि मेरी प्रस्तावित प्रक्रिया में प्रतिकृति द्वारा प्रदान किया गया है)? मुझे पिछले सप्ताह तक के आंकड़ों को चालू करने की आवश्यकता नहीं है।
* 'काम किया' से मेरा मतलब है कि यह पर्याप्त है लेकिन एक पीआईटीए था।