تخيل Oracle DBA. لقد تجاوز بالفعل الثلاثين ، وهو يعاني من زيادة الوزن قليلاً ، ويرتدي سترة ، ولديه رمز وصول سري لجميع القواعد المعلقة على رقبته ، وفي ملخص نصف صفحة من الشهادات التي اجتازها. السبت يوم الإفراج الكبير. ذروة. حان الوقت لبدء التغييرات في قاعدة البيانات. يكتب sqlplus ، يضغط ENTER ، وفي مكان ما أعلى الشاشة السوداء في الفراغ ، تندفع كيلومترات من أوامر SQL. مثلما هو الحال في حرب النجوم. بعد خمس دقائق ، كل شيء جاهز. بعد ساعة ، اكتمل الإصدار. تم العمل ، كان اليوم ناجحًا. الآن يمكنك الحصول على زوجين من البيرة.
شيء آخر هو الاثنين. اتضح أن بعض الأوامر لم يتم تنفيذها بسبب الأخطاء ، والتي ، مع ذلك ، لم توقف النص في سعيها الجامح إلى الفراغ الأسود. إن المهمة الصعبة بالفعل في معرفة ما تم كسره معقدة بسبب بعض الضغط من القيادة. بشكل عام ، لم ينجح يوم الاثنين.
بالطبع هذه قصة خيالية. لم يحدث هذا لأحد. على الأقل ، لم يكن ليحدث لو تم تنظيم العمل على تغيير مخطط قاعدة البيانات من خلال عمليات الترحيل.
ما هي أداة ترحيل قاعدة البيانات؟
إن فكرة إدارة تغييرات مخطط قاعدة البيانات من خلال عمليات الترحيل بسيطة للغاية:
- يتم إصدار كل تغيير كملف ترحيل منفصل.
- يتضمن ملف الترحيل تغييرات مباشرة وعكسية.
- يتم تطبيق عمليات الترحيل إلى قاعدة البيانات بواسطة أداة خاصة.
أبسط مثال للهجرة:
يوفر هذا النهج العديد من المزايا على تنظيم التغييرات في ملف SQL مشترك. إن مجرد غياب نزاعات الدمج يستحق ذلك.
والأمر الأكثر إثارة للدهشة هو أن النهج نفسه اكتسب شعبية في الآونة الأخيرة نسبياً. يبدو أن إطار Ruby on Rails ، الذي تم فيه إنشاء أداة الترحيل في الأصل ، كان الشهرة الرئيسية لهذا النهج ، فقد كان نهاية عام 2005. قبل ذلك بقليل ،
كتب مارتن فاولر 2003 عن هذا النهج ، وربما كانت النقطة الأساسية هي أن التطور بدأ في التكيف بنشاط مع استخدام نظام التحكم في الإصدار فقط في بداية هذا القرن. في عام 2000 ، كانت الفقرة الأولى من
اختبار جويل سبولسكي هي
"هل تستخدم التحكم بالمصادر؟" - هذا يشير إلى أنه لم يستخدم الجميع أنظمة التحكم في الإصدار في ذلك الوقت. لكننا كنا مشتتين.
ثماني سنوات مع MyBatis Migrations
بدأنا في
Wrike باستخدام نهج تغيير قاعدة البيانات من خلال عمليات الترحيل في عام 2010 ، 29 مارس ، في النصف الثاني عشر. منذ ذلك الحين ، قمنا بتنفيذ 1،440 عملية ترحيل ، تحتوي على 6،436 تغيير مباشر و 5،015 عملية عكسية. بشكل عام ، لقد اكتسبنا بعض الخبرة في استخدام أداة
MyBatis Migrations بالاشتراك مع
PostgreSQL .
باختصار ، لم نأسف قط. إذا حدث أنك لا تستخدم عمليات الترحيل أو شيء مشابه ، فقد حان الوقت للبدء. نعم ،
Pentium 4 قديم أيضًا.
لكن من الممل أن نتحدث عن مزايا أي شيء ، فلننتقل فورًا إلى الصعوبات.
تفاصيل PostgreSQL
لا توجد صعوبات في كتابة عمليات الترحيل لـ Postgres ، ربما باستثناء اثنين:
- لا يمكنك إنشاء فهارس ،
- لا يمكنك إضافة أعمدة NOT NULL.
لا ، في الواقع هذا ممكن ، ليس فقط بطريقة واضحة تمامًا. عند إنشاء فهرس ، يجب عليك دائمًا تحديد
CREATE INDEX CONCURRENTLY ، وإلا فإنك
ستوقف الإنتاج ، لأن Postgres سيغلق الجدول طوال مدة إنشاء الفهرس ، ويمكن أن يكون هذا وقتًا طويلاً. بالطبع ، ينسى المطورون الأمر مرة واحدة ، عليك دائمًا أن تضع هذا في الاعتبار. هنا يمكن للمرء كتابة اختبار. لكن هذا ليس سوى إزعاج طفيف.
إنشاء أعمدة NOT NULL أمر أكثر صعوبة ، هنا تحتاج إلى إجراء تغيير في أربع خطوات:
- قم بإنشاء عمود NULL (في Postgres إنه مجاني).
- قم بتعيين العمود الافتراضي إلى قيمة.
- في حلقة ، قم بتحديث القيم الفارغة بشكل تدريجي في DEFAULT.
- تعيين SET NOT NULL.
أكبر صيد هنا في الفقرة الثالثة. يلزم تحديث قيم NULL في أجزاء ، لأن
UPDATE some_table SET some_column='' WHERE some_column IS NULL ؛ سيحجب الجدول ، كما هو الحال مع الفهرس ، بنفس النتائج. ولا يمكن لعمليات الترحيل تنفيذ أوامر SQL إلا ، لذا يجب إدخال هذه البرامج النصية في الإنتاج يدويًا. المتعة أقل من المتوسط. الآن ، إذا كان من الممكن كتابة دورة في الهجرة ، فلن تكون هناك مشكلة. ربما يتم تنفيذ ذلك من خلال
الخطافات .
يتطلب أيضًا إنشاء فهرس
UNIQUE وتغيير
PRIMARY KEY بعض المهارة ، ولكن هذه العمليات نادرة نسبيًا للتركيز عليها.
تفاصيل الكتلة
أداة إدارة ترحيل قاعدة البيانات جيدة طالما لديك قاعدة بيانات واحدة. كل شيء أكثر متعة إذا كان لديك عدة قواعد. خاصة إذا كان لديك عدة أنواع من قواعد البيانات ، لكل منها عدة حالات.
ونتيجة لذلك ، بعد
git pull يجب على المطور أن يطرح التغييرات على المثيل الأول لقاعدة البيانات الأولى ، ثم على المثيل الثاني ، ثم على المثيل الأول لقاعدة البيانات الثانية وهكذا - مثل هذا المبدأ. من المناسب هنا كتابة أداة مساعدة لإدارة أداة إدارة ترحيل قاعدة البيانات. أتمتة كاملة.
شعوذة الدور
ليس سرا أن الأدوار ككيانات لا تعيش على مستوى قاعدة بيانات منفصلة ، ولكن على مستوى خادم قاعدة البيانات بأكمله ، على الأقل في Postgres. في هذه الحالة ، قد تحتاج إلى تحديد
REVOKE INSERT ON some_table FROM some_role ؛ لا يزال من الممكن توقع تكوين الأدوار مسبقًا في الإنتاج ، ولكن من الصعب بالفعل تطوير الأدوار أو تنظيمها. في الوقت نفسه ، أثناء التطوير ، بالطبع ، توجد جميع قواعد البيانات على نفس الخادم المحلي ، لذلك لا يمكنك ببساطة كتابة
CREATE ROLE في الترحيل ،
IF NOT EXISTS يكن هناك وجود مدعوم. يتم حل كل شيء ببساطة:
DO $$ BEGIN IF NOT EXISTS (SELECT * FROM pg_roles WHERE rolname = 'some_role') THEN CREATE ROLE "some_role" NOLOGIN; END IF; END; $$;
شاهده! أمسك بهم وأقذفهم ، أمسكهم وأقذفهم ، الأمر بسيط للغاية.
القليل من واقع التنمية
يطور المطورون أخطاء ، وحتى في عمليات ترحيل SQL ، يحدث هذا. يمكن ملاحظة الأخطاء عادةً في المراجعة ، ولكن يمكن أن تكون غير عادية أيضًا. إذا تحدثنا عن تغييرات مباشرة ، فعندئذ لا تصل الدعامات هناك إلى الإنتاج - فهناك العديد من مراحل التحقق. ولكن مع التغييرات العكسية ، قد تنشأ حوادث. لتجنب الأخطاء في ترحيل UNDO ، عند اختبار الترحيل ، تحتاج إلى إجراء ليس فقط
./migrate up ، ولكن
./migrate up ، ثم
./migrate down ، ثم مرة أخرى
./migrate up . هذا ليس معقدًا ، ما عليك سوى التأكد من أن أربعين مطورًا يفعلون ذلك دائمًا. بطريقة جيدة ، يمكن للأداة المساعدة تنفيذ مثل هذا التحرير والسرد لبيئة المطور تلقائيًا.
بيئات الاختبار
إذا كانت بيئة الاختبار قصيرة الأجل: لنفترض أنك أنشأت حاوية ، وقم بتهيئة قاعدة البيانات وتشغيل اختبارات التكامل ، فلا يجب أن تكون هناك أي مشاكل. نحن
./migrate bootstrap ، ثم
./migrate up ، وقد انتهيت. هذا فقط عندما يتجاوز عدد عمليات الترحيل ألف عملية ترحيل ، يمكن تأجيل هذه العملية. من العار أن تتم تهيئة قاعدة البيانات لفترة أطول من تشغيل الاختبارات. علينا المراوغة.
مع البيئات طويلة العمر ، لا يزال الأمر أكثر صعوبة. سؤال وجواب ، كما تعلمون ، لا يرغبون في رؤية قاعدة بيانات نظيفة للغاية عندما يأتون للعمل. لا أعرف لماذا هذا الأمر ، لكن الحقيقة هي الحقيقة. لذلك يجب الحفاظ على حالة القواعد المستخدمة في الاختبار اليدوي في نزاهة. وهذا ليس دائما سهلا.
الدقيقة هي أنه إذا تم تطبيق الترحيل على قاعدة البيانات ، فسيتم كتابة معرف الترحيل إليها. وإذا تم تغيير رمز الترحيل لاحقًا ، فلن تتأثر قاعدة البيانات. إذا كانت التغييرات غير حرجة ، يمكن أن تصل التعليمات البرمجية بنجاح إلى الإنتاج. Rssynchron. بالطبع ، هذا عار. المبدأ الأول للعمل مع عمليات الترحيل هو عدم تغيير عمليات الترحيل المكتوبة مطلقًا ، ولكن دائمًا إنشاء عمليات ترحيل جديدة. لكن في بعض الأحيان أشعر بالتحسس - سأغير قليلاً هنا ، لن ينكسر شيء ، لأن الحقيقة هي. بالطبع! هيا!
إذا تم التوقيع على عمليات الترحيل بعد المراجعة ، فقد يكون من الممكن حظر تطبيق المسودات للتدريج. وسيكون من الممكن حفظ ليس فقط معرف الترحيل في
changelog ، ولكن أيضًا
checksum - مفيد أيضًا.
العودة كما كانت
يحدث منعطف خبيث بشكل خاص عندما يتم إلغاء المهمة: لقد فعلوا ، فعلوا ، وغيروا رأيهم. إنه وضع طبيعي. بمجرد عدم الحاجة إلى الرمز ، يجب حذف الفرع. وكانت هناك هجرة ... وهي بالفعل في مرحلة ... آه ، عفوا. سبب وجيه للتحقق مما إذا كان يمكنك استعادة النسخ الاحتياطي للمستودع. على الرغم من التذكير بأنه ربما كان هناك أسهل.
في نفس الوقت ، الهجرة هي نص. وسيكون من الممكن حفظ هذا النص هناك ، في
changelog . بعد ذلك ، إذا اختفى الترحيل من الرمز ، فلا يهم أسباب ذلك ، فقد يتم التراجع عنه دائمًا. وحتى تلقائيًا.
قم بالتراجع مرة أخرى
هناك حاجة بالتأكيد إلى قسم UNDO. لكن لماذا تكتبها؟ بالطبع ، هناك حالات ملفتة للانتباه ، ولكن معظم التغييرات هي
CREATE TABLE أو
ADD COLUMN أو
CREATE INDEX . بالنسبة لهم ، يمكن للأداة المساعدة إنشاء عمليات عكسية تلقائيًا ، مباشرة باستخدام كود SQL. بالطبع ، هناك خصوصية.
CREATE TABLE ${name} - هذا فريق خاص ، فجأة غير قياسي. نعم ،
DROP TABLE ${name} ، يجب أن تكون قادرًا على تحليل التعبير حتى الكلمة الثالثة مباشرةً. على الرغم ، بشكل عام ، هذه مهمة فنية مجدية بالكامل. يمكن أن يكون خارج الصندوق.
الخلاصة
بالطبع ، أجد خطأ. تم تصميم MyBatis Migrations كأداة بسيطة وشاملة مرتبطة بشكل ضئيل بخصائص قواعد البيانات. وهي أكثر من مجرد تبرير نفسها. ولكن يبدو أن بعض التحسينات الصغيرة ستجعلها أفضل بكثير ، خاصة عند استخدامها لمسافات طويلة.
-
دميتري مامونوف / فريكي