लिक्विबेस का उपयोग करके अपने पैरों पर कुल्हाड़ी कैसे न मारें

ऐसा कभी नहीं हुआ, और यहाँ यह फिर से है!

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

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

जावा दुनिया में संबंधपरक संरचनाओं के संस्करण नियंत्रण की समस्याओं को हल करने के लिए लिक्विबेस और फ्लाईवे मुख्य प्रतिस्पर्धी प्रौद्योगिकियां हैं। पहला पूरी तरह से मुफ़्त है, व्यवहार में इसे अक्सर उपयोग के लिए चुना जाता है, यही कारण है कि लिक्विबेस को प्रकाशन के नायक के रूप में चुना गया था। हालाँकि, वर्णित कुछ प्रथाएँ आपके एप्लिकेशन की वास्तुकला के आधार पर सामान्य हो सकती हैं।

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

मैं आपके प्रोजेक्ट में लाइब्रेरी जोड़ने की तकनीक और निर्देशों के विवरण में नहीं जाऊंगा, इस विषय पर पर्याप्त लेख लिखे जा चुके हैं:

• स्प्रिंग बूट एप्लिकेशन में डेटाबेस संरचना को प्रबंधित करने के लिए लिक्विबेस का उपयोग करना। भाग ---- पहला
• स्प्रिंग बूट एप्लिकेशन में डेटाबेस संरचना को प्रबंधित करने के लिए लिक्विबेस का उपयोग करना। भाग ---- पहला
• लिक्विबेस और मावेन
• संस्करण संस्करण डेटाबेस परिवर्तन के लिए दृष्टिकोण
• स्प्रिंग एमवीसी/सिक्योरिटी, रेस्ट, हाइबरनेट, लिक्विबेस दो लाइनों में चलते हैं

इसके अलावा, उपयोगी युक्तियों के विषय पर पहले से ही एक बढ़िया लेख था:

• सिरदर्द के बिना लिक्विबेस का उपयोग करना। वास्तविक विकास अनुभव से 10 युक्तियाँ

Советы

मैं अपनी सलाह और टिप्पणियाँ साझा करना चाहता हूं, जो प्रवासन की समस्याओं को सुलझाने के खून-पसीने और पीड़ा से पैदा हुई हैं।

1. शुरू करने से पहले, आपको सर्वोत्तम अभ्यास अनुभाग पढ़ना चाहिए ऑनलाइन लिक्विबेस

वहाँ सरल लेकिन बहुत महत्वपूर्ण बातें वर्णित हैं, जिनके बिना पुस्तकालय का उपयोग आपके जीवन को जटिल बना सकता है। उदाहरण के लिए, परिवर्तन प्रबंधन के लिए एक गैर-संरचनात्मक दृष्टिकोण देर-सबेर भ्रम और टूटे हुए प्रवासन को जन्म देगा। यदि आप एक ही समय में डेटाबेस की संरचना और सेवाओं के तर्क में परस्पर निर्भर परिवर्तन नहीं करते हैं, तो इस बात की बहुत अधिक संभावना है कि इससे लाल परीक्षण या टूटा हुआ वातावरण पैदा होगा। इसके अलावा, आधिकारिक वेबसाइट पर लिक्विबेस का उपयोग करने की सिफारिशों में मुख्य माइग्रेशन स्क्रिप्ट के साथ-साथ रोलबैक स्क्रिप्ट के विकास और सत्यापन के बारे में एक पैराग्राफ शामिल है। खैर, लेख में https://habr.com/ru/post/178665/ माइग्रेशन और रोलबैक तंत्र से संबंधित कोड के उदाहरण हैं।

2. यदि आपने माइग्रेशन टूल का उपयोग शुरू किया है, तो डेटाबेस संरचना में मैन्युअल सुधार की अनुमति न दें

जैसा कि कहा जाता है: "एक बार पर्सिल, हमेशा पर्सिल।" यदि आपके एप्लिकेशन का आधार लिक्विबेस टूल द्वारा प्रबंधित किया जाना शुरू हो गया है, तो कोई भी मैन्युअल परिवर्तन तुरंत असंगत स्थिति का कारण बनता है, और परिवर्तनसेट में विश्वास का स्तर शून्य हो जाता है। संभावित जोखिम - डेटाबेस को पुनर्स्थापित करने में कई घंटे खर्च हुए, सबसे खराब स्थिति में - एक मृत सर्वर। यदि आपकी टीम के पास "पुराने स्कूल" डीबीए आर्किटेक्ट है, तो धैर्यपूर्वक और विचारपूर्वक उसे समझाएं कि यदि वह सशर्त एसक्यूएल डेवलपर से डेटाबेस को अपने तरीके से संपादित करता है तो कितनी बुरी चीजें होंगी।

3. यदि परिवर्तनसेट को पहले ही रिपॉजिटरी में धकेल दिया गया है, तो संपादन से बचें

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

4. यदि संभव हो तो सत्यापित डेटाबेस बैकअप रखें

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

5. यदि संभव हो तो विकास में सत्यापित डेटाबेस बैकअप का उपयोग करें

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

6. टीम के अन्य डेवलपर्स के साथ चैट करें

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

7. सोचो तुम क्या कर रहे हो!

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

जाल

आइए अब उन विशिष्ट जालों पर नजर डालें जिनमें ऊपर दी गई सलाह का पालन नहीं करने पर आप फंस सकते हैं और वास्तव में क्या किया जाना चाहिए?

स्थिति 1. दो डेवलपर एक ही समय में नए परिवर्तनसेट जोड़ने का प्रयास कर रहे हैं

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

कैसे निर्णय करें

1. किसी तरह, सहकर्मियों को उस क्रम पर सहमत होना चाहिए जिसमें उनके परिवर्तन होने चाहिए, मान लें कि पेटिन को पहले लागू किया जाना चाहिए।
2. एक व्यक्ति को दूसरे को डालना चाहिए और वास्या के परिवर्तनसेट को संस्करण 5 के साथ चिह्नित करना चाहिए। यह चेरी पिक या नीट मर्ज के माध्यम से किया जा सकता है।
3. परिवर्तनों के बाद, की गई कार्रवाइयों की वैधता की जांच करना सुनिश्चित करें।
   वास्तव में, लिक्विबेस तंत्र आपको रिपॉजिटरी में दो संस्करण 4 परिवर्तन सेट करने की अनुमति देगा, ताकि आप सब कुछ वैसे ही छोड़ सकें। यानी, आपके पास अलग-अलग नामों से संस्करण 4 के दो संशोधन होंगे। इस दृष्टिकोण के साथ, डेटाबेस संस्करणों को बाद में नेविगेट करना बहुत कठिन हो जाता है।

इसके अलावा, लिक्विबेस, हॉबिट्स के घरों की तरह, बहुत सारे रहस्य रखता है। उनमें से एक वैलिडचेकसम कुंजी है, जो संस्करण 1.7 के बाद से दिखाई दी है और आपको किसी विशिष्ट परिवर्तन के लिए एक वैध हैश मान निर्दिष्ट करने की अनुमति देती है, चाहे डेटाबेस में कुछ भी संग्रहीत हो। प्रलेखन https://www.liquibase.org/documentation/changeset.html निम्नलिखित कहता है:

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

हाँ, यह अनुशंसित नहीं है. लेकिन कभी-कभी एक मजबूत प्रकाश जादूगर अंधेरे तकनीकों में भी महारत हासिल कर लेता है।

केस 2: डेटा-संचालित माइग्रेशन

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

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

कैसे निर्णय करें

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

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

स्थिति 3. लिक्विबेस का उपयोग उत्पादन में आने के बाद शुरू होता है

मान लीजिए कि टीम लीडर ने पेट्या को प्रोजेक्ट में लिक्विबेस को शामिल करने के लिए कहा, लेकिन प्रोजेक्ट पहले से ही उत्पादन में है और पहले से ही मौजूदा डेटाबेस संरचना है।

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

कैसे निर्णय करें

इसके भी कई तरीके हैं:

• पहली और सबसे स्पष्ट बात यह है कि एक अलग स्क्रिप्ट होनी चाहिए जिसे नए वातावरण को आरंभ करते समय मैन्युअल रूप से लागू किया जाना चाहिए।
• दूसरा, कम स्पष्ट, एक लिक्विबेस माइग्रेशन है जो एक अलग लिक्विबेस संदर्भ में है और इसे लागू करना है। आप यहां लिक्विबेस कॉन्टेक्स्ट के बारे में अधिक पढ़ सकते हैं: https://www.liquibase.org/documentation/contexts.html. सामान्य तौर पर, यह एक दिलचस्प तंत्र है जिसे सफलतापूर्वक लागू किया जा सकता है, उदाहरण के लिए, परीक्षण के लिए।
• तीसरे पथ में कई चरण होते हैं। सबसे पहले, मौजूदा तालिकाओं के लिए एक माइग्रेशन बनाया जाना चाहिए। फिर इसे किसी परिवेश पर लागू करना होगा और इस प्रकार इसकी हैश राशि प्राप्त होगी। अगला कदम हमारे गैर-रिक्त सर्वर पर खाली लिक्विबेस तालिकाओं को आरंभ करना है, और आप मैन्युअल रूप से डेटाबेस में पहले से ही परिवर्तनों के साथ "लागू किए गए" परिवर्तनसेट का रिकॉर्ड परिवर्तनसेट लागू करने के इतिहास के साथ तालिका में डाल सकते हैं। इस प्रकार, पहले से मौजूद सर्वर पर, इतिहास संस्करण 2 से शुरू होगा, और सभी नए वातावरण समान व्यवहार करेंगे।
  

परिदृश्य 4: प्रवासन बहुत अधिक हो जाता है और टिक नहीं पाता

सेवा विकास की शुरुआत में, एक नियम के रूप में, लिक्विबेस का उपयोग बाहरी निर्भरता के रूप में किया जाता है, और एप्लिकेशन शुरू होने पर सभी माइग्रेशन संसाधित होते हैं। हालाँकि, समय के साथ, आपके सामने निम्नलिखित मामले आ सकते हैं:

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

कैसे निर्णय करें

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

ऑफ़लाइन, आप माइग्रेशन के आवेदन को अपने सीआई/सीडी वातावरण में या अपने सिस्टम प्रशासकों/नियोक्ताओं के मजबूत कंधों पर छोड़ सकते हैं। ऐसा करने के लिए, आपको लिक्विबेस कमांड लाइन की आवश्यकता है https://www.liquibase.org/documentation/command_line.html. इस मोड में, सभी आवश्यक माइग्रेशन पूरे होने के बाद एप्लिकेशन लॉन्च करना संभव हो जाता है।

उत्पादन

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

स्रोत: www.habr.com