ابدأ مجاناً EN
شروحات تقنية 2026-04-05 14 دقيقة قراءة

تحديث ERPNext v15: ماذا تفعل كل أمر وأين يمكن أن تحدث الكارثة

تحديثات ERPNext تقع في ثلاث فئات، كل منها لها مستوى مخاطرة مختلف تماماً. الفئة 1: تحديثات صغيرة (v15.22 → v15.26) — مخاطرة منخفضة، تنتهي في 15 دقيقة. الفئة 2: ترقية إصدار كبرى (v14 → v15) — مخاطرة عالية، تحتاج بيئة اختبار، خطط لـ 4-8 ساعات. الفئة 3: تحديث إطار العمل (تغييرات Frappe الأساسية) — مخاطرة متوسطة، اتبع نفس عملية التحديثات الصغيرة لكن اقرأ ملاحظات الإصدار أولاً. أغلى خطأ يرتكبه المطورون هو معاملة ترقية إصدار كبرى كتحديث صغير.

القاعدة الذهبية: النسخة الاحتياطية قبل التحديث هي بوليصة التأمين

غير قابل للتفاوض: افعل هذا قبل كل تحديث

كل تحديث يجب أن يبدأ بنسخة احتياطية موثقة. ليس نسخة تفترض أنها موجودة — نسخة أخذتها للتو وتأكدت من وجود الملف على القرص. تحديث واحد فاسد بدون نسخة احتياطية = فقدان دائم للبيانات. لا يوجد زر 'تراجع' في قاعدة البيانات.

bash 
# خذ نسخة احتياطية كاملة قبل كل تحديث (شغّل كمستخدم frappe)
cd ~/frappe-bench
bench --site mycompany.com backup --with-files

# تأكد أن ملف النسخة موجود فعلاً وله محتوى
ls -lh sites/mycompany.com/private/backups/
# يجب أن ترى ملف .sql.gz أُنشئ في آخر دقيقتين
# يجب أن يكون أكبر من 1 كيلوبايت — الملف بحجم 0 = النسخ فشل

# احتفظ باسم الملف الدقيق للاستخدام في التراجع إذا لزم
ls -t sites/mycompany.com/private/backups/*.sql.gz | head -1

انسخ النسخة الاحتياطية لمكان خارجي قبل البدء في التحديث:

bash 
# نسخ لسيرفر آخر عبر SCP
scp sites/mycompany.com/private/backups/*.sql.gz user@backup-server:/backups/

# أو رفع إلى S3 (إذا كان AWS CLI مهيأً)
aws s3 cp sites/mycompany.com/private/backups/*.sql.gz s3://your-backup-bucket/erpnext/

السيناريو أ: تحديث صغير (v15.x → v15.y) — مخاطرة منخفضة، 15 دقيقة

التحديثات الصغيرة تُصلح أخطاء ومشاكل أمنية ضمن نفس الإصدار الرئيسي. نادراً ما تكسر الوظائف الموجودة. هذا هو التحديث الذي تشغّله أكثر — مثالياً أسبوعياً أو كل أسبوعين.

ما الذي يحدث عند تشغيل 'bench update': (1) Git يسحب أحدث commits لكل التطبيقات المثبتة، (2) تُحدَّث تبعيات Python إذا تغير requirements.txt، (3) سكربتات ترحيل قاعدة البيانات تعمل إذا وُجدت تغييرات في المخطط، (4) أصول JavaScript/CSS تُعاد بناؤها.

bash 
# الخطوة 1: خذ نسخة احتياطية (مغطاة أعلاه)

# الخطوة 2: تحقق من الإصدار الحالي
bench version
# سجّل هذا — ستحتاجه للتراجع إذا فشل شيء

# الخطوة 3: شغّل التحديث
bench update --pull

# إذا أردت تشغيل الترحيل بشكل منفصل (أأمن لقواعد البيانات الكبيرة):
bench update --pull --skip-migrate
bench --site mycompany.com migrate  # شغّل الترحيل أثناء مراقبته

# الخطوة 4: أعد تشغيل كل الخدمات لتحميل الكود الجديد
bench restart

# الخطوة 5: تحقق من نجاح التحديث
bench version  # يجب أن يظهر أرقام الإصدار الجديدة
bench --site mycompany.com doctor  # يتحقق من أي تناقضات
كيف تعرف أن التحديث نجح

بعد إعادة التشغيل: سجّل دخولاً لـ ERPNext، افتح فاتورة مبيعات وأمر شراء، تحقق من تحميل لوحة التحكم. إذا بدا أي شيء مكسوراً أو رمى خطأ، انتقل لخطوات التراجع فوراً.

السيناريو ب: ترقية إصدار كبرى (v14 → v15) — مخاطرة عالية، استخدم بيئة اختبار

لا تفعل هذا على الإنتاج بدون اختبار على نسخة مطابقة أولاً

ترقية v14 إلى v15 تغير هياكل جداول قاعدة البيانات (ترحيلات المخطط)، تزيل APIs مهجورة قد يستخدمها كودك المخصص، وقد تكسر قوالب الطباعة المخصصة والحقول المخصصة. الاختبار على بيئة اختبار بنسخة من بياناتك الحقيقية ليس اختيارياً — إنه الطريقة الوحيدة لمعرفة ما سيتكسر قبل أن يتكسر في الإنتاج.

الخطوة 1: أنشئ بيئة اختبار. هذا سيرفر منفصل تماماً (أو سيرفر يمكنك تحمّل كسره) مع نسخة من قاعدة بيانات الإنتاج.

bash 
# على سيرفر الاختبار (وليس الإنتاج!)
# كرر التثبيت الكامل من دليل التثبيت أولاً
# ثم استعد نسخة الإنتاج على موقع الاختبار:

bench new-site staging.mycompany.com \
  --mariadb-root-password DB_PASSWORD \
  --admin-password ADMIN_PASSWORD

# استعد نسخة قاعدة بيانات الإنتاج على الاختبار
bench --site staging.mycompany.com restore \
  /path/to/your-production-backup.sql.gz

الخطوة 2: حوّل بيئة الاختبار إلى v15 واختبر الترقية:

bash 
# حوّل كل التطبيقات لفرع v15
bench switch-to-branch version-15 frappe erpnext hrms

# حدّث وشغّل الترحيلات
bench update --pull

# إذا ظهرت أخطاء أثناء الترحيل، ستظهر هنا على الاختبار
# هذا بالضبط سبب الاختبار هنا أولاً

الخطوة 3: اختبر هذه الوظائف الحرجة على بيئة الاختبار قبل لمس الإنتاج: (1) سجّل دخولاً وتحقق من تحميل لوحة التحكم بدون أخطاء JavaScript — افتح وحدة تحكم المتصفح (F12) وابحث عن أخطاء حمراء. (2) افتح فاتورة مبيعات موجودة من قبل الترقية وتحقق من ظهور كل الحقول وصحتها. (3) أنشئ فاتورة مبيعات اختبارية جديدة وأرسلها وتحقق من ترحيلها بشكل صحيح. (4) شغّل تقرير ميزان المراجعة للشهر الماضي وتحقق من مطابقة الأرقام لما كان قبل الترقية. (5) افتح أي قالب طباعة مخصص لديك وتحقق من عرضه بشكل صحيح. (6) اختبر تقديم الفواتير الإلكترونية (ETA/ZATCA) بفاتورة اختبارية إذا كان مطبقاً. (7) اختبر نقطة البيع (POS) إذا كان عملك يستخدمها.

الخطوة 4: إذا نجحت كل الاختبارات على بيئة الاختبار، طبّق على الإنتاج خلال نافذة صيانة (ساعات قليلة الحركة):

bash 
# على سيرفر الإنتاج
# جدوّل نافذة صيانة (مثلاً: 2 ص الجمعة)

# 1. خذ نسخة احتياطية نهائية مباشرة قبل الترقية
bench --site mycompany.com backup --with-files

# 2. ضع الموقع في وضع الصيانة
bench --site mycompany.com set-maintenance-mode on

# 3. حوّل لفروع v15
bench switch-to-branch version-15 frappe erpnext hrms

# 4. اسحب الكود وشغّل الترحيلات
bench update --pull

# 5. أعد بناء الأصول للإصدار الجديد
bench build --production

# 6. أعد تشغيل الخدمات
bench restart

# 7. عطّل وضع الصيانة
bench --site mycompany.com set-maintenance-mode off

# 8. تحقق أن كل شيء يعمل
bench version
bench --site mycompany.com doctor

السيناريو ج: التراجع بعد تحديث فاشل — كيف تتراجع في حالة طوارئ

إذا فشل التحديث وموقعك مكسور، إليك كيفية العودة للحالة الصالحة. السرعة مهمة هنا — كل دقيقة يكون نظامك فيها متوقفاً تكلّف أعمالاً. احتفظ بهذا القسم في المفضلة.

bash 
# الخطوة 1: أوقف كل الخدمات فوراً
sudo supervisorctl stop all

# الخطوة 2: حوّل كل التطبيقات للفرع السابق
# إذا كنت على v15 وتترقّى لـ v16:
bench switch-to-branch version-15 frappe erpnext hrms

# إذا كنت على v14 وتترقّى لـ v15:
bench switch-to-branch version-14 frappe erpnext hrms

# الخطوة 3: استعد قاعدة البيانات من النسخة الاحتياطية
# استبدل اسم الملف بالملف الفعلي الذي رأيته في 'ls' سابقاً
bench --site mycompany.com restore \
  sites/mycompany.com/private/backups/20260405_020000-mycompany_com-database.sql.gz

# الخطوة 4: أعد بناء الأصول للإصدار القديم
bench build

# الخطوة 5: ابدأ الخدمات
sudo supervisorctl start all

# الخطوة 6: اختبر الموقع يعمل
bench --site mycompany.com doctor
تحذير فقدان البيانات عند التراجع

أي معاملات أُنشئت بعد أخذ النسخة الاحتياطية ستُفقد أثناء التراجع. هذا أمر لا مفر منه. لهذا يجب أخذ النسخة الاحتياطية مباشرة قبل التحديث — وليس الليلة السابقة. كل ساعة بين النسخة الاحتياطية والتحديث = فقدان محتمل للبيانات أثناء التراجع.

كيف تتحقق مما تغير قبل التحديث (اقرأ ملاحظات الإصدار كمهندس DevOps)

قبل أي تحديث، اقضِ 5 دقايق في قراءة ملاحظات الإصدار. هذا يخبرك إذا كان التحديث يغير أي شيء تعتمد عليه.

bash 
# اعرض ما هي الـ commits القادمة قبل سحبها
git -C apps/erpnext log --oneline HEAD..origin/version-15 | head -20
git -C apps/frappe log --oneline HEAD..origin/version-15 | head -20

# تحقق إذا كانت ملفات ترحيل موجودة (تغييرات المخطط = مخاطرة أكبر)
ls apps/erpnext/erpnext/patches/
# ملفات patch جديدة منذ آخر تحديث = سيُعدَّل قاعدة البيانات

لماذا الـ SaaS المُدار يتعامل مع هذا بشكل أفضل

كل ما سبق هو عمل تشغيلي حقيقي يجب على مهندس DevOps تنفيذه بشكل صحيح في كل مرة. على مانجلي كلاود، كل تحديث ERPNext يُختبر في بيئة sandbox مقابل لقطة من بياناتك الفعلية قبل تطبيقه. عندما يكون آمناً، يُنشر خلال ساعات قليلة الحركة. تستلم إشعاراً بأن نظامك محدَّث. لم تفعل شيئاً. لم تكن أبداً في خطر فقدان البيانات.

تحديثات بصفر مخاطرة

مانجلي تختبر كل تحديث مقابل أنماط البيانات الحقيقية قبل النشر. ترقيات الإصدارات الكبرى تُرحَّل وتُتحقق منها وتُطبَّق بدون أي إجراء مطلوب منك. تحديثات الامتثال الضريبي (ETA، ZATCA، FTA) تُنشر تلقائياً في نفس اليوم الذي تصدر فيه الحكومات متطلبات جديدة.

اترك تعليقاً

التعليقات

تخلّص من قلق نوافذ الصيانة والتراجع. احصل على تحديثات تلقائية بصفر مخاطرة على مانجلي كلاود.