ابدأ مجانا
EN
شروحات تقنية 14 دقيقة قراءة

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

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

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

التحديث هو ما يكسر معظم نسخ ERPNext المثبتة يدوياً. على مانجلي، يُجرَّب التحديث أولاً على نسخة من بياناتك، وعند أي مشكلة يتراجع النظام تلقائياً.

لا لـ bench update مرة أخرى
لا نقاش: افعل هذا قبل أي تحديث

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

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 مهجورة قد يستخدمها كودك المخصص، وقد تكسر قوالب الطباعة والحقول المخصصة. الاختبار على بيئة staging بنسخة من بياناتك الحقيقية ليس اختيارياً؛ فهو ما يكشف لك ما سينكسر قبل أن ينكسر عند عملائك.

الخطوة 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) تصدر في اليوم نفسه الذي تُعلن فيه الجهات متطلبات جديدة.

لديك ERPNext مثبت؟ أرسل لنا النسخة الاحتياطية ونرفعها لك على مانجلي مجاناً. وإذا لم تجد فرقاً، خذ نسختك الاحتياطية وامضِ.

انقل نسختك مجاناً

دع غيرك يتحمل ليلة التحديث ومخاطرها.

تطبيقات المتجر على نفس بياناتك، حسب باقتك.

انقل نسختك مجانًا ارفع تطبيقك من Git

سيب تعليقك

التعليقات