مقال

البروفة أولاً: كيف أنفّذ التغييرات الحساسة على قواعد بيانات Odoo في بيئة الإنتاج

2026-11-03 · أحمد محمد

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

خلال العام الماضي استقررت على دليل عمل (Runbook) واحد لهذا النوع من المهام. وهو ممل عن قصد.

1. تحليل دون أي تعديل أولاً

قبل كتابة أي سكربت ترحيل، أستعلم عن قاعدة البيانات بصلاحية القراءة فقط. أريد أن أعرف:

كم سجلاً ستمسّه كل خطوة
أي تسلسلات الترقيم وتقييمات المخزون والأرصدة المحاسبية تعتمد عليها
أي مهام مجدولة أو تكاملات صادرة قد تعمل أثناء التنفيذ

والناتج خطة مكتوبة قصيرة بمراحل مرقّمة.

2. نسخة احتياطية استعدتها فعلاً

النسخة الاحتياطية ثلاثة أشياء، ولكل منها بصمة تحقق:

pg_dump -Fc "$DB" -f "${DB}_${LABEL}_${TS}.dump"
tar czf "${DB}_${LABEL}_${TS}_filestore.tgz" -C "$FILESTORE" .
sha256sum *"${TS}"* > "${DB}_${TS}.sha256"

لا أثق بالنسخة الاحتياطية حتى أستعيدها: أتحقق من البصمة، وأشغّل pg_restore -j4 في قاعدة بيانات جديدة، وأقارن عدد السجلات جدولاً جدولاً مع القاعدة الحية.

3. البروفة على نسخة معزولة

تصبح النسخة المستعادة بيئة البروفة. وقبل لمسها:

أضبطها كـ IS_TEMPLATE حتى لا يعرضها التطبيق أو يفتحها بالخطأ
أعطّل المهام المجدولة والبريد الصادر
أعطّل أي مزوّد فوترة إلكترونية أو دفع
أعيد توليد معرّفات قاعدة البيانات، حتى لا تتواصل النسخة أبداً مع خدمات خارجية وكأنها بيئة الإنتاج

ثم أنفّذ التغيير تماماً كما سيُنفَّذ في بيئة الإنتاج، وأقارن البصمات التشغيلية قبل وبعد: تقييم المخزون، والأرصدة المحاسبية، وعدد السجلات لكل شركة.

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

4. بوابة موافقة يفرضها السكربت

يرفض سكربت الإنتاج العمل ما لم:

يكن موجّهاً إلى قاعدة البيانات المتوقعة (يتحقق من current_database())
يُمرَّر له المعامل --approved صراحة
تكن جميع عمليات التطبيق وجلسات قاعدة البيانات الأخرى متوقفة

وبذلك يفشل أي خطأ في الطرفية بأمان بدلاً من إفساد البيانات.

5. التنفيذ والتحقق وإبقاء خطة التراجع جاهزة

تُنفَّذ المرحلة الرئيسية داخل معاملة (Transaction) واحدة. بعدها أشغّل فحوص SQL للقراءة فقط وسكربت تحقق على مستوى الـ ORM، وأقارن النتائج بالبروفة، وأحفظ الأدلة (السجلات والبصمات وتصدير التقييم) بجوار النسخة الاحتياطية.

تُكتب خطة التراجع قبل التنفيذ لا بعده، ولها ثلاثة مستويات:

التراجع عن المرحلة.
استعادة قاعدة البيانات من النسخة.
استعادة قاعدة البيانات وملفات المرفقات معاً.

ماذا تكسب من ذلك

في المشاريع التي استخدمت فيها هذا الدليل، كان التنفيذ على بيئة الإنتاج أقل أجزاء اليوم إثارة: فعل بالضبط ما فعلته البروفة. وهذا هو الهدف.

إذا كنت تعمل مع قواعد بيانات ERP، يسعدني أن أعرف كيف تتعامل مع هذا. تواصل معي على LinkedIn.

→ كل المقالات