لماذا يجب عليك دائمًا تشغيل اختبار جاف للمهاجرات قبل لمس البيانات الحقيقية

لقد كتبت سكريبت مهاجرة. يبدو صحيحًا. المنطق سليم. قمت بتشغيله على بيئة الاختبار (staging)، وكل شيء نجح. ولكن عندما تشغله على الإنتاج، يحدث خطأ ما. ربما يفشل قيد عمود. ربما يظهر انتهاك لمفتاح خارجي. ربما تستغرق المهاجرة 45 دقيقة بدلاً من 5 دقائق المتوقعة، مما يؤدي إلى قفل جدول حيوي وتسبب سلسلة من حالات انتهاء المهلة (timeouts) عبر تطبيقك.

هذا السيناريو شائع. ويمكن منعه. التقنية بسيطة: قم بتشغيل اختبار جاف (dry-run) لمهاجرتك قبل أن تلمس البيانات الحقيقية أبدًا.

ما الذي يفعله اختبار الجاف بالضبط

الاختبار الجاف هو بالضبط ما يبدو عليه. تقوم بتنفيذ سكريبت المهاجرة، ولكنك لا تلتزم (commit) بالتغييرات أبدًا. لا يتم تغيير أي جداول. لا يتم نقل أي صفوف. لا يتم حذف أي أعمدة. أنت فقط تتحقق مما إذا كان السكريبت يعمل بدون أخطاء، وإذا كانت هناك مشاكل، فستكتشفها قبل أن تتأثر أي بيانات.

الطريقة الأكثر شيوعًا للقيام بذلك هي عن طريق تغليف المهاجرة داخل معاملة قاعدة بيانات (transaction) وإنهائها بـ ROLLBACK بدلاً من COMMIT. إذا كان لديك سكريبت يضيف عمودًا جديدًا ويملؤه من جدول آخر، فقم بتغليف كل شيء في BEGIN TRANSACTION ... ROLLBACK. إذا حدث خطأ في منتصف الطريق، فإن المعاملة تلغي نفسها تلقائيًا وتعود قاعدة البيانات إلى حالتها الأصلية. إذا لم يحدث خطأ، فستظل تقوم بالتراجع يدويًا. أنت لا تبحث عن تطبيق التغيير. أنت تبحث عن تأكيد أن السكريبت صالح.

إليك مثال ملموس لما يبدو عليه ذلك في SQL:

BEGIN TRANSACTION;

-- مثال مهاجرة: إضافة عمود جديد وملؤه
ALTER TABLE users ADD COLUMN last_login_at TIMESTAMP;

UPDATE users
SET last_login_at = NOW()
WHERE last_login_at IS NULL;

-- تحقق من أن البيانات تبدو صحيحة قبل التراجع
SELECT id, email, last_login_at FROM users LIMIT 10;

-- التراجع عن المعاملة، مع ترك قاعدة البيانات دون تغيير
ROLLBACK;

ما يخبرك به اختبار الجاف أبعد من أخطاء الصياغة

التحقق من أخطاء الصياغة (syntax errors) أو انتهاكات القيود (constraint violations) هو الفائدة الواضحة. لكن الاختبار الجاف يعطيك معلومات أكثر فائدة بكثير.

يمكنك رؤية المدة التي ستستغرقها المهاجرة. يمكنك رؤية عدد الصفوف التي ستتأثر. يمكنك رؤية ما إذا كانت المهاجرة ستقفل الجداول (lock tables) ولمدة كم. هذه معلومات حاسمة، خاصة إذا كانت مهاجرتك تستهدف قاعدة بيانات إنتاج تتعامل مع آلاف الطلبات في الثانية. إذا أظهر اختبارك الجاف أن المهاجرة ستستغرق 30 دقيقة وخلال ذلك الوقت سيتم قفل الجدول الرئيسي، فأنت تعلم أنك بحاجة إلى استراتيجية مختلفة. ربما تقوم بتشغيل المهاجرة خلال ساعات خارج أوقات الذروة. ربما تستخدم تقنية مهاجرة عبر الإنترنت (online migration) تتجنب الأقفال الطويلة. ربما تقسم المهاجرة إلى دفعات أصغر.

بدون اختبار جاف، أنت تخمن. مع اختبار جاف، لديك بيانات لاتخاذ قرار مستنير.

أين تقوم بتشغيل اختبارك الجاف

المكان المثالي هو بيئة اختبار (staging) تحتوي على بيانات تشبه الإنتاج إلى حد كبير. ولكن ليس كل فريق لديه قاعدة بيانات اختبار بحجم بيانات واقعي. إذا كان هذا هو وضعك، فخذ لقطة (snapshot) من بيانات الإنتاج في نقطة زمنية واحدة وقم بتحميلها في قاعدة بيانات منفصلة. لا ينبغي أبدًا استخدام هذه اللقطة للمعاملات الحقيقية، لكنها جيدة بما يكفي لاختبار مهاجرتك.

تذهب بعض الفرق إلى أبعد من ذلك وتقوم بأتمتة الاختبارات الجافة. في كل مرة يتغير فيها سكريبت مهاجرة في طلب سحب (pull request)، تقوم وظيفة CI بتشغيل الاختبار الجاف تلقائيًا. هذا يكتشف المشاكل قبل دمج الكود حتى. إنه استثمار صغير يوفر وقتًا كبيرًا في التصحيح لاحقًا.

كيفية قراءة نتائج الاختبار الجاف

المخرجات النظيفة بدون أخطاء وبدون تحذيرات مطمئنة. لكن لا تتوقف عند هذا الحد. اذهب من خلال السجلات (logs) بعناية.

ابحث عن الصفوف التي فشلت في الملء لأن البيانات لم تطابق نوع العمود الجديد. ابحث عن تعارضات الفهارس (index conflicts). ابحث عن انتهاكات المفاتيح الخارجية (foreign key violations). في بعض الأحيان، ينجح الاختبار الجاف تقنيًا ولكنه يفشل منطقيًا. على سبيل المثال، البيانات التي نقلتها قد تكون فارغة لأن جملة WHERE الخاصة بك كانت خاطئة. السكريبت عمل بشكل جيد. لا أخطاء. لكن النتيجة غير مجدية.

لالتقاط هذا، بعد اكتمال الاختبار الجاف، قم بتشغيل استعلام SELECT للتحقق من محتويات الجدول المعدل كما لو أن المهاجرة قد حدثت بالفعل. يمكنك القيام بذلك داخل نفس المعاملة قبل التراجع. افتح جلسة منفصلة، وقم بتشغيل المهاجرة داخل معاملة، وقبل التراجع، استعلم عن الجداول المعدلة لتأكيد صحة البيانات. هذه الخطوة الإضافية تحول الاختبار الجاف من فحص صياغة إلى فحص منطق.

ما لا يمكن أن يضمنه الاختبار الجاف

الاختبار الجاف ليس ضمانًا بأن المهاجرة ستعمل بسلاسة في الإنتاج. لا يمكن تكرار بعض العوامل بشكل كامل. سيكون حمل الاستعلامات المتزامن (concurrent query load) مختلفًا. قد يكون حجم البيانات أكبر بكثير. قد يتغير توقيت الأقفال. لكن الاختبار الجاف يقلل من المفاجآت. إذا قمت باختبار المهاجرة في بيئة قريبة من الإنتاج وكانت النتائج تطابق توقعاتك، يمكنك تشغيل المهاجرة الحقيقية بثقة أعلى بكثير.

قائمة تحقق عملية قبل تشغيل مهاجرة

قبل تشغيل أي مهاجرة تلمس بيانات الإنتاج، اذهب من خلال هذه القائمة القصيرة:

  • قم بتغليف المهاجرة في معاملة وتشغيلها مع ROLLBACK
  • تحقق من وقت التنفيذ ومدة القفل
  • تحقق من أن عدد الصفوف المتأثرة يطابق التوقعات
  • استعلم عن الجداول المعدلة داخل المعاملة لتأكيد صحة البيانات
  • راجع السجلات بحثًا عن انتهاكات القيود أو تعارضات الفهارس أو عدم تطابق الأنواع
  • إذا كانت المهاجرة تستغرق وقتًا طويلاً أو تقفل بشكل كبير، خطط لاستراتيجية بديلة

الخلاصة الملموسة

الاختبار الجاف ليس خطوة إضافية. إنها الخطوة التي تفصل بين نشر واثق وآخر مرهق. قم بتشغيل مهاجرتك في معاملة. تراجع عنها. تحقق من النتائج. ثم قرر ما إذا كنت مستعدًا للالتزام (commit). بيانات الإنتاج الخاصة بك ستشكرك.