عندما تحتاج تغييرات قاعدة البيانات إلى أكثر من مجرد مراجعة الكود
يفتح مطور طلب سحب. التغيير يبدو بسيطًا: إضافة عمود جديد لتتبع تفضيلات المستخدمين. يراجع زميل الكود، يوافق عليه، ويتم دمج التغيير. بعد عشرين دقيقة، تبدأ قاعدة بيانات الإنتاج في تراكم الأقفال. الاستعلامات التي كانت تستغرق ميلي ثانية أصبحت تستغرق ثوانٍ. يتم التراجع عن النشر، لكن الضرر قد وقع بالفعل.
هذا السيناريو يتكرر في الفرق التي تتعامل مع تغييرات قاعدة البيانات بنفس طريقة تعاملها مع تغييرات كود التطبيق. مراجعة الكود تلتقط أخطاء المنطق ومشاكل الأسلوب، لكنها نادرًا ما تلتقط ما يحدث عندما يتم تشغيل ترحيل (migration) على جدول يحتوي على عشرة ملايين صف. الفرق بين الترحيل الآمن والخطير ليس دائمًا واضحًا في الفرق (diff).
لماذا تختلف خطوط أنابيب قاعدة البيانات
تتحقق خطوط أنابيب التطبيقات من أن الكود يترجم، والاختبارات تمر، والقطعة الأثرية (artifact) قابلة للنشر. خطوط أنابيب قاعدة البيانات لها وظيفة مختلفة: فهي تتحقق من أن تغيير المخطط (schema) لن يفسد البيانات الموجودة، أو يقفل الجداول لفترة طويلة جدًا، أو يقلل من أداء الاستعلامات بعد النشر.
يمكن لترحيل واحد أن يتسبب في فقدان البيانات، أو إطلاق أقفال طويلة الأمد، أو جعل التطبيق غير قابل للاستخدام حتى اكتمال الترحيل. هذه المخاطر ليست نظرية. كل فريق يدير قاعدة بيانات إنتاج لديه قصة عن ترحيل حدث فيه خطأ ما.
خط أنابيب تغييرات قاعدة البيانات موجود لالتقاط هذه المشاكل قبل وصولها إلى الإنتاج. إنه لا يحل محل مراجعة الكود. بل يضيف طبقة من التحقق لا يمكن لمراجعة الكود وحدها توفيرها.
ماذا يحدث بعد الالتزام (Commit)
عندما يلتزم مطور بملف ترحيل في فرع ميزة، يبدأ خط أنابيب قاعدة البيانات في تشغيل الفحوصات تلقائيًا. تحدث هذه الفحوصات قبل أن ينظر أي مراجع بشري إلى التغيير.
الفحص الأول هو التحقق من الصياغة (Syntax validation). يقرأ خط الأنابيب ملف الترحيل ويؤكد أن كل عبارة SQL يمكن تحليلها بدون أخطاء. يبدو هذا بسيطًا، لكنه يمنع مضيعة شائعة للوقت: مراجع يقضي عشر دقائق في النظر إلى ترحيل يفشل في السطر الأول.
الفحص الثاني يكتشف الأنماط الخطيرة. حذف جدول، إزالة عمود، أو تغيير نوع عمود هي عمليات يمكن أن تدمر البيانات. يضع خط الأنابيب علامة على هذه التغييرات على أنها عالية المخاطر. لا يمنعها تلقائيًا، لكنه يتأكد من أن الجميع يعرف ما هو على المحك.
الفحص الثالث هو تشغيل تجريبي (Dry run). يقوم خط الأنابيب بتشغيل الترحيل ضد بيئة اختبار تعكس الإنتاج بأكبر قدر ممكن. يقيس التشغيل التجريبي المدة التي يستغرقها الترحيل، وما إذا كان يتسبب في أقفال الجدول، وما إذا كانت الفهارس بحاجة إلى إعادة بناء. كما يتحقق من أن بيانات الاختبار تظل متسقة بعد الترحيل.
يتم جمع كل هذه النتائج في تقرير واحد يتم إرفاقه بطلب السحب. يرى المراجع حالة الصياغة، وقائمة العمليات الخطيرة، ومدة التشغيل التجريبي، وأي تحذيرات حول المشاكل المحتملة. لا يحتاج إلى تشغيل الترحيل يدويًا أو تخمين ما قد يحدث.
يلخص المخطط الانسيابي التالي مراحل خط الأنابيب من الالتزام إلى الدمج:
الموافقة المبنية على المخاطر
ليس كل ترحيل يحتاج إلى نفس المستوى من التدقيق. إضافة عمود يمكن أن يكون فارغًا (nullable) بقيمة افتراضية هو منخفض المخاطر. حذف جدول قد لا يزال مرجعًا بواسطة كود التطبيق هو عالي المخاطر. يجب أن يعكس خط الأنابيب هذا الاختلاف.
الموافقة المبنية على المخاطر تعني أن خط الأنابيب يتطلب موافقين مختلفين اعتمادًا على مستوى مخاطر الترحيل. قد يحتاج الترحيل منخفض المخاطر إلى موافقة من مطور أول واحد. الترحيل عالي المخاطر الذي يحذف عمودًا أو يقوم بتعبئة خلفية (backfill) على جدول كبير يحتاج إلى موافقة من مسؤول قاعدة بيانات (DBA) أو مهندس رئيسي يفهم تأثير الإنتاج.
يقوم تكوين خط الأنابيب بتحديد ما يعتبر عالي المخاطر. تشمل الأنماط الشائعة:
- عبارات DROP TABLE أو DROP COLUMN
- ALTER COLUMN التي تغير أنواع البيانات
- الترحيلات التي تستغرق أكثر من دقيقة واحدة في التشغيل التجريبي
- العمليات التي تتطلب أقفالًا حصرية على الجداول الكبيرة
عندما يكتشف خط الأنابيب نمطًا عالي المخاطر، فإنه يمنع الدمج حتى يعطي الموافق المعين موافقته الصريحة. هذا ليس بيروقراطية. إنه للتأكد من أن الشخص الذي يفهم قاعدة بيانات الإنتاج لديه فرصة لمراجعة التغيير قبل تطبيقه.
التقرير الذي يبقى مع طلب السحب
تقرير خط الأنابيب ليس فقط للمراجع. إنه سجل لما تم فحصه وما تم العثور عليه. عندما ينظر شخص ما إلى طلب السحب بعد أسابيع، يمكنه رؤية ما إذا كان الترحيل قد تم التحقق منه، وما هي المخاطر التي تم تحديدها، ومن وافق عليه.
هذا مهم لتصحيح الأخطاء. إذا تسبب الترحيل في مشاكل بعد النشر، يمكن للفريق النظر إلى تقرير خط الأنابيب لمعرفة ما إذا كان التشغيل التجريبي قد أظهر علامات تحذيرية تم تجاهلها. كما أنه مهم لعمليات التدقيق. البيئة الخاضعة للتنظيم تحتاج إلى دليل على أن تغييرات قاعدة البيانات تمت مراجعتها والموافقة عليها وفقًا للسياسة.
ما لا يفعله خط الأنابيب
يتحقق خط الأنابيب من أن الترحيل آمن للتجربة. لا يضمن أن الترحيل سينجح في الإنتاج. بيئات الإنتاج لها توزيعات بيانات مختلفة، وأنماط تحميل مختلفة، وقيود زمنية مختلفة. التشغيل التجريبي الذي يستغرق ثلاثين ثانية في بيئة التدريج (staging) قد يستغرق خمس دقائق في الإنتاج لأن الجدول أكبر أو الخادم أكثر ازدحامًا.
خط الأنابيب أيضًا لا يتعامل مع توقيت الترحيل. تشغيل الترحيل خلال ذروة حركة المرور محفوف بالمخاطر بغض النظر عن مدى جودة اختباره. قرار متى يتم تطبيق الترحيل، وكيفية التعامل مع الأقفال، وماذا تفعل إذا حدث خطأ ما، ينتمي إلى عملية منفصلة.
قائمة تحقق عملية لإعداد خط أنابيب قاعدة البيانات
إذا كنت تقوم ببناء خط أنابيب قاعدة البيانات لفريقك، إليك الأشياء التي يجب أن تضبطها بشكل صحيح أولاً:
- التحقق من الصياغة على كل التزام. اكتشف SQL المعطوب قبل أن يصل إلى المراجع.
- كشف الأنماط الخطيرة. ضع علامة تلقائيًا على DROP و ALTER COLUMN وغيرها من العمليات عالية المخاطر.
- تشغيل تجريبي في بيئة تمثيلية. قياس المدة والأقفال واتساق البيانات.
- قواعد الموافقة المبنية على المخاطر. حدد ما يعتبر عالي المخاطر ومن يمكنه الموافقة عليه.
- تقرير مرفق بطلب السحب. اجعل نتائج التحقق مرئية للمراجعين والقراء المستقبليين.
ابدأ بهذه العناصر الخمسة. إنها تغطي نقاط الفشل الأكثر شيوعًا وتمنح فريقك طريقة متسقة لمراجعة تغييرات قاعدة البيانات.
الخلاصة
خط أنابيب قاعدة البيانات ليس أداة لتشغيل الترحيلات. إنه آلية للتأكد من أن كل تغيير في قاعدة البيانات يحصل على المستوى المناسب من التدقيق قبل أن يلمس الإنتاج. فحص الصياغة يلتقط الأخطاء المطبعية. التشغيل التجريبي يلتقط مشاكل الأداء. الموافقة المبنية على المخاطر تضمن أن الشخص المناسب يراجع التغيير المناسب.
عندما تعمل هذه القطع معًا، يمكن لفريقك التحرك بشكل أسرع لأنهم يثقون في أن خط الأنابيب سيلتقط المشاكل مبكرًا. وعندما يحدث خطأ في الترحيل، يكون لديك البيانات لفهم السبب.