لم يحدث أبدا ، وها هو مرة أخرى!
في المشروع التالي ، قررنا استخدام Liquibase منذ البداية لتجنب المشاكل في المستقبل. كما اتضح ، لا يعرف جميع أعضاء الفريق الشباب كيفية استخدامه بشكل صحيح. أقمت ورشة عمل داخلية قررت بعدها تحويلها إلى مقال.
تتضمن هذه المقالة نصائح مفيدة وأوصافًا لثلاثة من أكثر المخاطر وضوحًا التي يمكن أن تقع فيها عند العمل باستخدام أدوات ترحيل قاعدة البيانات العلائقية ، Liquibase على وجه الخصوص. مصمم لمطوري Java من المستويين الصغير والمتوسط ، بالنسبة للمطورين الأكثر خبرة ، قد يكون من المثير للاهتمام هيكلة وتكرار ما هو معروف بالفعل على الأرجح.
Liquibase و Flyway هما التقنيات المتنافسة الرئيسية لحل مشاكل التحكم في إصدار الهياكل العلائقية في عالم Java. الأول مجاني تمامًا ، ومن الناحية العملية يتم اختياره في كثير من الأحيان للاستخدام ، ولهذا السبب تم اختيار Liquibase كبطل للنشر. ومع ذلك ، قد تكون بعض الممارسات الموضحة عامة ، اعتمادًا على بنية التطبيق الخاص بك.
تعتبر عمليات الترحيل العلائقية طريقة إجبارية للتعامل مع المرونة الضعيفة لمخازن البيانات العلائقية. في عصر الموضة لـ OOP ، كان أسلوب العمل مع قاعدة البيانات يعني أننا سنصف المخطط مرة واحدة ولن نلمسها مرة أخرى. لكن الحقيقة هي أن الأشياء تتغير دائمًا ، وأن التغييرات في هيكل الجداول مطلوبة كثيرًا. بطبيعة الحال ، فإن العملية نفسها مؤلمة وغير سارة.
لن أخوض في وصف التكنولوجيا والتعليمات الخاصة بإضافة المكتبة إلى مشروعك ، فقد تمت كتابة مقالات كافية حول هذا الموضوع:
بالإضافة إلى ذلك ، كان هناك بالفعل مقال رائع حول موضوع النصائح المفيدة:
Советы
أريد أن أشارككم نصيحتي وتعليقاتي ، التي ولدت من العرق والدم والألم لحل مشاكل الهجرة.
1. قبل البدء ، يجب قراءة قسم أفضل الممارسات حول ليكويباس
يتم وصف أشياء بسيطة ولكنها مهمة للغاية ، والتي بدونها يمكن أن يؤدي استخدام المكتبة إلى تعقيد حياتك. على سبيل المثال ، سيؤدي اتباع نهج غير هيكلي لإدارة مجموعة التغييرات عاجلاً أم آجلاً إلى حدوث ارتباك وعمليات ترحيل معطلة. إذا لم تقم بإجراء تغييرات تعتمد على بعضها البعض في بنية قاعدة البيانات ومنطق الخدمات في نفس الوقت ، فهناك احتمال كبير أن يؤدي ذلك إلى اختبارات حمراء أو بيئة معطلة. بالإضافة إلى ذلك ، تحتوي التوصيات الخاصة باستخدام Liquibase على الموقع الرسمي على فقرة حول تطوير البرامج النصية للتراجع والتحقق منها جنبًا إلى جنب مع البرامج النصية الرئيسية للترحيل. حسنًا ، في المقال هناك أمثلة على التعليمات البرمجية المتعلقة بعمليات الترحيل وآلية التراجع.
2. إذا بدأت في استخدام أدوات الترحيل ، فلا تسمح بالتصحيحات اليدوية في بنية قاعدة البيانات
كما يقول المثل: "برسيل مرة واحدة ، برسيل دائمًا". إذا بدأت أدوات Liquibase في إدارة قاعدة تطبيقك ، فإن أي تغييرات يدوية تؤدي على الفور إلى حالة غير متسقة ، ويصبح مستوى الثقة في مجموعات التغييرات صفرًا. المخاطر المحتملة - قضاء عدة ساعات في استعادة قاعدة البيانات ، في أسوأ السيناريوهات - خادم ميت. إذا كان لدى فريقك مهندس DBA "مدرسة قديمة" ، فشرح له بصبر ومدروس مدى سوء الأمور إذا قام للتو بتحرير قاعدة البيانات بطريقته الخاصة من مطور SQL الشرطي.
3. إذا تم دفع مجموعة التغييرات بالفعل إلى المستودع ، فتجنب التحرير
إذا قام مطور آخر بسحب وتطبيق مجموعة تغييرات سيتم تحريرها لاحقًا ، فسوف يتذكرك بالتأكيد بكلمة لطيفة عندما يتلقى خطأ عند بدء التطبيق. إذا تسرب تعديل مجموعة التغييرات بطريقة ما إلى التطوير ، فسيتعين عليك النزول في المنحدر الزلق للإصلاحات العاجلة. يعتمد جوهر المشكلة على التحقق من صحة التغييرات عن طريق مجموع التجزئة - الآلية الرئيسية لـ Liquibase. عند تحرير كود مجموعة التغييرات ، يتغير مجموع التجزئة. تحرير مجموعات التغييرات ممكن فقط عندما يكون من الممكن نشر قاعدة البيانات بأكملها من البداية دون فقدان البيانات. في هذه الحالة ، يمكن لإعادة هيكلة شفرة SQL أو XML ، على العكس من ذلك ، أن تجعل الحياة أسهل ، وتجعل عمليات الترحيل أكثر قابلية للقراءة. ومن الأمثلة على ذلك الموقف الذي يتم فيه تنسيق مخطط قاعدة البيانات المصدر داخل الفريق في بداية التطبيق.
4. التحقق من النسخ الاحتياطية لقاعدة البيانات إن أمكن
هنا ، على ما أعتقد ، كل شيء واضح. إذا لم تنجح عملية الترحيل فجأة ، فيمكن إعادة كل شيء. يحتوي Liquibase على أداة التراجع ، ولكن يتم أيضًا كتابة البرامج النصية للتراجع بواسطة المطور نفسه ، ويمكن أن تواجه مشكلات مع نفس الاحتمالية كما في البرامج النصية لمجموعة التغييرات الرئيسية. هذا يعني أن تشغيلها بأمان مع النسخ الاحتياطية مفيد على أي حال.
5. استخدام النسخ الاحتياطية لقاعدة البيانات التي تم التحقق منها في التطوير إن أمكن
إذا كان هذا لا يتعارض مع العقود والخصوصية ، فلا توجد بيانات شخصية في قاعدة البيانات ، ولا تزن مثل شمسين - قبل تطبيقها على خوادم الترحيل المباشر ، يمكنك التحقق من كيفية عملها على جهاز المطور وحساب ما يقرب من 100٪ من المشاكل المحتملة أثناء الهجرة.
6. الدردشة مع المطورين الآخرين في الفريق
في عملية تطوير جيدة التنظيم ، يعرف كل فرد في الفريق من يفعل ماذا. في الواقع ، هذا ليس هو الحال في كثير من الأحيان ، لذلك ، إذا كنت تقوم بإعداد تغييرات في هيكل قاعدة البيانات كجزء من مهمتك ، فمن المستحسن إخطار الفريق بأكمله بالإضافة إلى ذلك. إذا كان هناك شخص ما يجري تغييرات بالتوازي ، يجب أن تنظم بعناية. يجدر التواصل مع الزملاء حتى في نهاية العمل ، وليس فقط في البداية. يمكن حل العديد من المشكلات المحتملة المتعلقة بمجموعات التغييرات في مرحلة مراجعة الكود.
7. فكر فيما تفعله!
نصيحة بديهية على ما يبدو تنطبق على أي موقف. ومع ذلك ، كان من الممكن تجنب العديد من المشكلات إذا قام المطور مرة أخرى بتحليل ما كان يفعله وما قد يؤثر عليه. يتطلب العمل مع عمليات الترحيل دائمًا مزيدًا من الاهتمام والدقة.
الفخاخ
دعنا الآن نلقي نظرة على الفخاخ النموذجية التي يمكنك الوقوع فيها إذا لم تتبع النصيحة أعلاه ، وما الذي يجب فعله في الواقع؟
الموقف 1. يحاول مطوران إضافة مجموعات تغييرات جديدة في نفس الوقت
يريد Vasya و Petya إنشاء مجموعة تغييرات الإصدار 4 دون معرفة بعضهما البعض. قاموا بإجراء تغييرات على بنية قاعدة البيانات ، وطرحوا طلب سحب ، مع ملفات مجموعة تغييرات مختلفة. الآلية التالية مقترحة أدناه:
كيف تقرر
- بطريقة ما ، يجب أن يتفق الزملاء على الترتيب الذي يجب أن تسير عليه تغييراتهم ، دعنا نقول أنه يجب تطبيق Petin أولاً.
- يجب على شخص واحد أن يسكب الآخر ويضع علامة على تغييرات Vasya بالإصدار 5. ويمكن القيام بذلك عن طريق Cherry Pick أو دمج أنيق.
- بعد التغييرات ، تأكد من التحقق من صحة الإجراءات المتخذة.
في الواقع ، ستسمح لك آليات Liquibase بالحصول على مجموعتين من التغييرات في الإصدار 4 في المستودع ، بحيث يمكنك ترك كل شيء كما هو. وهذا يعني أنه سيكون لديك ببساطة نسختان من الإصدار 4 بأسماء مختلفة. باستخدام هذا النهج ، تصبح إصدارات قاعدة البيانات صعبة للغاية للتنقل لاحقًا.
بالإضافة إلى ذلك ، فإن Liquibase ، مثل منازل الهوبيت ، تحتفظ بالكثير من الأسرار. أحدها هو مفتاح validCheckSum ، الذي ظهر منذ الإصدار 1.7 ويسمح لك بتحديد قيمة تجزئة صالحة لمجموعة تغييرات معينة ، بغض النظر عن ما يتم تخزينه في قاعدة البيانات. توثيق يقول ما يلي:
أضف مجموعًا اختباريًا يعتبر صالحًا لمجموعة التغيير هذه ، بغض النظر عما يتم تخزينه في قاعدة البيانات. تُستخدم بشكل أساسي عندما تحتاج إلى تغيير مجموعة تغيير ولا تريد ظهور أخطاء في قواعد البيانات التي تم تشغيلها عليها بالفعل (ليس إجراءً مستحسنًا)
نعم ، هذا غير مستحسن. لكن في بعض الأحيان ، يتقن ساحر الضوء القوي أيضًا تقنيات الظلام.
الحالة 2: الهجرة المدفوعة بالبيانات
لنفترض أنه لا يمكنك استخدام النسخ الاحتياطية لقاعدة البيانات من الخوادم الحية. أنشأ Petya مجموعة تغييرات واختبرها محليًا ، وبكل ثقة تامة أنه كان على حق ، قدم طلب سحب إلى المطور. فقط في حالة حدوث ذلك ، أوضح قائد المشروع ما إذا كانت بيتيا قد فحصته ، ثم سكبه. لكن النشر على خادم التطوير قد انخفض.
في الواقع ، هذا ممكن ، ولا أحد محصن منه. يحدث هذا إذا كانت التعديلات على بنية الجدول مرتبطة بطريقة ما ببيانات محددة من قاعدة البيانات. من الواضح أنه إذا كانت قاعدة بيانات Petya مليئة ببيانات الاختبار فقط ، فقد لا تغطي جميع حالات المشكلات. على سبيل المثال ، عند حذف جدول ، اتضح أن هناك سجلات في جداول أخرى بواسطة المفتاح الخارجي مقترنة بالسجلات الموجودة في الجدول الذي يتم حذفه. أو عند تغيير نوع العمود ، اتضح أنه لا يمكن تحويل 100٪ من البيانات إلى النوع الجديد.
كيف تقرر
- اكتب نصوصًا خاصة سيتم تطبيقها مرة واحدة جنبًا إلى جنب مع الترحيل وإحضار البيانات بالشكل المناسب. هذه طريقة عامة لحل مشكلة نقل البيانات إلى هياكل جديدة بعد تطبيق عمليات الترحيل ، ولكن يمكن تطبيق شيء مشابه من قبل ، في حالات خاصة. هذا المسار ، بالطبع ، ليس متاحًا دائمًا ، لأن تحرير البيانات على الخوادم الحية يمكن أن يكون خطيرًا بل وقاتلًا.
- هناك طريقة أخرى صعبة وهي تعديل مجموعة تغييرات موجودة. تكمن الصعوبة في أن جميع قواعد البيانات التي تم تطبيقها بالفعل في شكلها الحالي يجب استعادتها. من المحتمل جدًا أن يضطر فريق الخلفية بالكامل إلى طي قاعدة البيانات محليًا من البداية.
- والطريقة الأكثر شمولية هي نقل مشكلة البيانات إلى بيئة المطور ، وإعادة إنشاء نفس الموقف وإضافة مجموعة تغييرات جديدة ، إلى مجموعة معطلة ، والتي ستتجاوز المشكلة.
بشكل عام ، كلما كانت قاعدة البيانات أكثر تشابهًا في تكوينها مع قاعدة بيانات خادم الإنتاج ، قل احتمال انتشار مشاكل الترحيل بعيدًا. وبالطبع ، قبل إرسال مجموعة التغييرات إلى المستودع ، يجب أن تفكر عدة مرات في ما إذا كانت ستؤدي إلى كسر شيء ما.
الموقف 3. يبدأ استخدام Liquibase بعد أن يدخل حيز الإنتاج
لنفترض أن قائد الفريق طلب من Petya تضمين Liquibase في المشروع ، لكن المشروع قيد الإنتاج بالفعل وهناك هيكل قاعدة بيانات موجود بالفعل.
وفقًا لذلك ، تكمن المشكلة في أنه في أي خوادم أو أجهزة مطور جديدة ، يجب إعادة إنشاء بيانات الجدول من البداية ، ويجب أن تظل البيئة الموجودة بالفعل في حالة متسقة ، لتكون جاهزة لقبول التغييرات الجديدة.
كيف تقرر
هناك أيضًا عدة طرق:
- الأول والأكثر وضوحًا هو أن يكون لديك برنامج نصي منفصل يجب تطبيقه يدويًا عند تهيئة بيئة جديدة.
- الثاني ، الأقل وضوحًا ، هو أن يكون لديك ترحيل Liquibase في سياق Liquibase مختلف وتطبيقه. يمكنك قراءة المزيد عن سياق Liquibase هنا: . بشكل عام ، هذه آلية مثيرة للاهتمام يمكن تطبيقها بنجاح ، على سبيل المثال ، للاختبار.
- المسار الثالث يتكون من عدة خطوات. أولاً ، يجب إنشاء ترحيل للجداول الموجودة. ثم يجب تطبيقه على بعض البيئات وبالتالي سيتم الحصول على مجموع التجزئة الخاص به. الخطوة التالية هي تهيئة جداول Liquibase الفارغة على خادمنا غير الفارغ ، ويمكنك يدويًا وضع سجل لمجموعة التغييرات "كما لو تم تطبيقها" مع التغييرات الموجودة بالفعل في قاعدة البيانات في الجدول مع تاريخ تطبيق التغييرات. وبالتالي ، على خادم موجود بالفعل ، سيبدأ السجل من الإصدار 2 ، وستتصرف جميع البيئات الجديدة بشكل متماثل.
السيناريو 4: الهجرات تضخم ولا تستطيع مواكبتها
في بداية تطوير الخدمة ، كقاعدة عامة ، يتم استخدام Liquibase كعنصر تابع خارجي ، وتتم معالجة جميع عمليات الترحيل عند بدء التطبيق. ومع ذلك ، بمرور الوقت ، قد تتعثر في الحالات التالية:
- تصبح الهجرات ضخمة وتستغرق وقتًا طويلاً حتى تكتمل.
- هناك حاجة للترحيل في البيئات الموزعة ، على سبيل المثال ، في العديد من طبعات خوادم قاعدة البيانات في نفس الوقت.
في هذه الحالة ، سيؤدي تطبيق عمليات الترحيل لفترة طويلة جدًا إلى انتهاء المهلة عند بدء التطبيق. أيضًا ، يمكن أن يؤدي تطبيق عمليات الترحيل على أساس طبعة كل تطبيق إلى أن تكون الخوادم المختلفة في حالة عدم التزامن.
كيف تقرر
في مثل هذه الحالات ، يكون مشروعك كبيرًا بالفعل ، وربما حتى شخص بالغ ، ويبدأ Liquibase في العمل كأداة خارجية منفصلة. الحقيقة هي أن Liquibase ، كمكتبة ، يتم تجميعها في ملف جرة ، ويمكن أن تعمل كتبعية داخل المشروع ، وكذلك قائمة بذاتها.
في وضع عدم الاتصال ، يمكنك ترك تطبيق الترحيل إلى بيئة CI / CD أو على أكتاف قوية من مسؤولي النظام / النشر. للقيام بذلك ، تحتاج إلى سطر أوامر Liquibase . في هذا الوضع ، يصبح من الممكن تشغيل التطبيق بعد اكتمال جميع عمليات الترحيل الضرورية.
إنتاج
في الواقع ، هناك العديد من المزالق عند العمل مع عمليات ترحيل قاعدة البيانات ، ويتطلب الكثير منها نهجًا إبداعيًا. من المهم أن تفهم أنه إذا كنت تستخدم الأداة بشكل صحيح ، فيمكن تجنب معظم هذه المصائد. على وجه التحديد ، كان علي أن أواجه كل المشاكل المدرجة بأشكال مختلفة ، وبعضها كان نتيجة عضلاتي. في الأساس ، يحدث هذا ، بالطبع ، بسبب عدم الانتباه ، ولكن في بعض الأحيان - بسبب عدم القدرة الجنائية على استخدام الأداة.
المصدر: www.habr.com