لماذا تحتاج تغييرات مخطط قاعدة البيانات إلى نفس الانضباط المتبع مع الكود
تخيل هذا: فريقك نشر للتو ميزة جديدة. كود التطبيق يعمل بشكل جيد. ولكن بعد خمس دقائق، تبدأ الأخطاء في التدفق. عمود يتوقعه الكود الجديد غير موجود بعد. أو ما هو أسوأ، عمود تم حذفه لا يزال يُستعلم من قبل خدمة أقدم لم يتم تحديثها. قاعدة البيانات في حالة غير متناسقة، ولا يمكن لأحد أن يحدد بالضبط ما حدث أو كيفية إصلاحه بسرعة.
هذا السيناريو أكثر شيوعًا مما يعترف به معظم الفرق. السبب الجذري دائمًا هو نفسه تقريبًا: تم تغيير مخطط قاعدة البيانات يدويًا، بدون عملية قابلة للتكرار، وبدون تنسيق مع كود التطبيق الذي يعتمد عليه.
الفرق الأساسي بين الكود والمخطط
كود التطبيق عديم الحالة (Stateless). عندما تنشر إصدارًا جديدًا، يتم استبدال الملفات القديمة. إذا حدث خطأ ما، يمكنك التراجع إلى الإصدار السابق، ويعود الخادم إلى حالته المعروفة. لا توجد بيانات متبقية، ولا تبعيات مخفية.
قواعد البيانات هي العكس تمامًا. فهي ذات حالة (Stateful) بطبيعتها. كل جدول، عمود، فهرس، وقيد يحتوي على بيانات تراكمت بمرور الوقت. عندما تغير المخطط، فأنت لا تستبدل ملفًا فحسب. بل تقوم بتعديل الهيكل الذي يحمل البيانات الموجودة. قد يحتاج عمود جديد إلى قيمة افتراضية للصفوف الموجودة. قد يؤدي حذف عمود إلى إزالة بيانات لا يزال جزء آخر من النظام يعتمد عليها. قد يستغرق بناء فهرس جديد دقائق أو ساعات على جدول كبير.
هذه الطبيعة ذات الحالة تجعل تغييرات المخطط أكثر خطورة بطبيعتها من تغييرات الكود. يمكن التراجع عن نشر سيء في ثوانٍ. بينما يمكن للترحيل السيء أن يفسد البيانات، أو يكسر الاستعلامات، أو يعطل النظام بأكمله. ولأن قاعدة البيانات مشتركة عبر خدمات وبيئات متعددة، فإن نصف قطر الانفجار أكبر بكثير.
الطريقة القديمة: يدوية، هشة، غير قابلة للتكرار
لفترة طويلة، كانت تغييرات قاعدة البيانات تُعالج كسير عمل يدوي منفصل. كان مسؤول قاعدة البيانات (DBA) أو مطور أول يقوم بتسجيل الدخول إلى خادم قاعدة بيانات الإنتاج، وتشغيل بضعة أوامر SQL، والانتظار. إذا نجح الترحيل، فبها ونعمت. إذا فشل، كانوا يحاولون إصلاحه في الحال، غالبًا بدون سجل واضح لما تم فعله.
هذا النهج يعاني من عدة مشاكل:
- غير قابل للتكرار. تعتمد الخطوات الدقيقة على من يقوم بتشغيلها، وما يتذكرونه، وما يلاحظونه أثناء التنفيذ. قد يتم تنفيذ نفس الترحيل بطريقتين مختلفتين من قبل شخصين مختلفين.
- غير قابل للتدقيق. لا يوجد تاريخ لما تغير، ومتى، ومن قام به. إذا حدث كسر بعد أيام، فإن تتبع السبب يكاد يكون مستحيلاً.
- هش. خطوة واحدة منسية أو ترتيب تنفيذ خاطئ يمكن أن يترك قاعدة البيانات في حالة غير متناسقة. يصبح الاسترداد تمرينًا يدويًا تحت ضغط عالٍ.
- يعيق التعاون. فقط عدد قليل من الأشخاص لديهم صلاحية الوصول والمعرفة لتشغيل الترحيلات. باقي الفريق لا يمكنه مراجعة أو اختبار أو المساهمة في تغييرات المخطط.
مع نمو الفريق وزيادة تعقيد النظام، يصبح هذا النهج اليدوي عنق زجاجة ومخاطرة. كل نشر يتضمن تغييرًا في المخطط يصبح حدثًا عالي القلق.
تعامل مع تغييرات المخطط مثل الكود
الحل واضح ومباشر: قم بإدارة تغييرات مخطط قاعدة البيانات بنفس الانضباط الذي تستخدمه لكود التطبيق. هذه الممارسة تسمى ترحيل المخطط (Schema Migration)، وهي مبنية على بضعة مبادئ بسيطة.
اكتب كل تغيير كسكريبت ترحيل. سكريبت الترحيل هو ملف يحتوي على أوامر SQL اللازمة لتعديل مخطط قاعدة البيانات. قد يضيف عمودًا، أو ينشئ جدولاً، أو يضيف فهرسًا، أو يغير قيدًا. كل سكريبت يمثل تغييرًا منطقيًا واحدًا.
على سبيل المثال، بدلاً من تسجيل الدخول إلى الإنتاج وتشغيل:
ALTER TABLE users ADD COLUMN phone VARCHAR(20);
ستقوم بإنشاء ملف ترحيل مثل هذا:
-- V001__add_phone.sql
-- Forward migration
ALTER TABLE users ADD COLUMN phone VARCHAR(20);
وملف تراجع مقابل:
-- V001__add_phone_rollback.sql
-- Rollback migration
ALTER TABLE users DROP COLUMN phone;
هذه الملفات موجودة في مستودعك، وتتم مراجعتها في طلبات السحب (Pull Requests)، ويتم تنفيذها تلقائيًا بواسطة خط أنابيب النشر الخاص بك. لا خطوات يدوية، ولا أوامر منسية، ولا غموض.
قم بتخزين سكريبتات الترحيل في نفس المستودع مع كود التطبيق. يضمن هذا أن تغييرات المخطط مُرقمة (Versioned) جنبًا إلى جنب مع الكود الذي يعتمد عليها. عندما تسحب نسخة معينة من الكود، يكون لديك أيضًا سكريبتات الترحيل الدقيقة التي تم استخدامها لإنشاء المخطط لتلك النسخة.
لا تقم أبدًا بتعديل سكريبت ترحيل موجود. إذا كنت بحاجة إلى إجراء تغيير، قم بإنشاء سكريبت جديد. هذا يحافظ على سلامة التاريخ ويضمن أن ترتيب التنفيذ واضح. تستخدم أدوات الترحيل عادةً رقم إصدار أو طابع زمني لتحديد أي السكريبتات تم تشغيلها بالفعل وأيها معلقة.
قم بتشغيل الترحيلات كجزء من خط أنابيب النشر. تمامًا مثل تشغيل الاختبارات أو بناء القطع الأثرية (Artifacts)، يجب أن يكون تطبيق تغييرات المخطط خطوة آلية في خط أنابيب CI/CD الخاص بك. هذا يزيل الاعتماد على التنفيذ اليدوي ويضمن أن كل بيئة تحصل على نفس التغييرات بنفس الترتيب.
راجع سكريبتات الترحيل مثل الكود. قبل دمج سكريبت ترحيل، يجب أن يمر بمراجعة الكود. يمكن لأعضاء الفريق التحقق من المشكلات المحتملة: القيم الافتراضية المفقودة، العمليات طويلة الأمد، أو التغييرات التي قد تكسر الاستعلامات الموجودة. هذا يكتشف المشكلات قبل وصولها إلى الإنتاج.
لماذا هذا مهم عمليًا
عندما تتم إدارة تغييرات المخطط مثل الكود، تصبح عملية النشر قابلة للتنبؤ. يعرف الفريق بالضبط ما سيحدث عند تشغيل الترحيل. يمكنهم اختباره في بيئة اختبار (Staging) أولاً. يمكنهم التراجع إذا حدث خطأ ما، لأن كل سكريبت ترحيل لديه سكريبت تراجع مقابل. يمكنهم تتبع أي تغيير في المخطط وصولاً إلى الـ Commit الذي قدمه.
الأهم من ذلك، هذا النهج يقلل الخوف من النشر. تتوقف تغييرات المخطط عن كونها نشاطًا منفصلاً عالي المخاطرة. تصبح جزءًا طبيعيًا من سير عمل التطوير، تتم مراجعتها واختبارها مثل أي تغيير كود آخر. لم تعد قاعدة البيانات صندوقًا أسود لا يمكن إلا لعدد قليل من الأشخاص لمسه.
قائمة تحقق عملية لترحيلات المخطط
قبل دمج سكريبت ترحيل، راجع قائمة التحقق السريعة هذه:
- هل يحتوي الترحيل على سكريبت تراجع مقابل؟
- هل يمكن تشغيل الترحيل عدة مرات دون التسبب في أخطاء (Idempotent)؟
- هل سيقوم الترحيل بقفل الجداول لفترة طويلة؟ إذا كان الأمر كذلك، فكر في التجميع (Batching) أو استخدام أدوات تغيير المخطط عبر الإنترنت (Online Schema Change Tools).
- هل هناك أي استعلامات أو كود موجود قد ينكسر بعد هذا التغيير؟
- هل قمت باختبار الترحيل على نسخة من بيانات الإنتاج؟
- هل تمت مراجعة سكريبت الترحيل من قبل عضو فريق آخر على الأقل؟
الخلاصة
مخطط قاعدة البيانات الخاص بك ليس قطعة أثرية ثابتة. إنه يتطور جنبًا إلى جنب مع تطبيقك. معاملة تغييرات المخطط كعمليات يدوية لمرة واحدة هي وصفة لحوادث الإنتاج والاحتكاك داخل الفريق. من خلال إدارة ترحيلات المخطط بنفس الانضباط المتبع مع الكود، فإنك تجعل تغييرات قاعدة البيانات قابلة للتكرار، وقابلة للتدقيق، وآمنة. تتوقف قاعدة البيانات عن كونها مصدرًا للخوف وتصبح مجرد جزء آخر من النظام يمكن لفريقك تغييره بثقة.