استراتيجيات التراجع عن عمليات نشر سيلزفورس الفاشلة

الإجابة باختصار: سيلزفورس مفيهاش زرار تراجع. النشر اللي بيفشل على الإنتاج بيرجّع نفسه تلقائيًا، لأن rollbackOnError لازم تكون true في الإنتاج، لكن النشر اللي بينجح وبعدين يطلع غلط ده مسؤوليتك إنت تعكسه بنفسك. الخيارات الواقعية تلاتة: نشر عكسي من نسخة محفوظة قبل الإصدار، أو حذف مقصود للمكوّنات الجديدة، أو إصلاح للأمام. وأي خيار هيكون متاح قدامك بيتحدد قبل النشر مش بعده.

ليه مفيش زرار rollback في سيلزفورس؟

سيلزفورس بتكتب الميتاداتا مباشرة جوه الـ org. مفيش سجل معاملات ترجعه، ولا نسخة سابقة من الـ org تبدّل عليها. الـ Metadata API بتديك شبكة أمان واحدة بس، وهي بتغطي الفشل الصريح فقط: في النشر على الإنتاج لازم rollbackOnError تكون true، فلو أي مكوّن فشل تتلغي الحزمة كلها وتفضل الـ org زي ما هي (دليل مطوّري Metadata API من سيلزفورس).

الشبكة دي مش بتنفع في الحالة اللي الفرق بتخاف منها فعلًا. الإصدار اللي بينزل نضيف وينجح في كل الاختبارات وبعدين يكسر عملية شغل الساعة تسعة الصبح مش بيتحسب نشر فاشل عند سيلزفورس. عكسه معناه إنك تبني نشر جديد، والنشر ده مش هتقدر تبنيه غير من حاجة صوّرتها قبل كده.

إيه اللي ينفع يترجع وإيه اللي مينفعش؟

ده السؤال اللي المفروض أي خطة rollback تبدأ بيه، وده بالظبط اللي أغلب الخطط ساكتة عنه. قسّم الإصدار لتلات مجموعات قبل ما تكتب أول خطوة.

• قابل للعكس بإعادة نشر النسخة القديمة. كلاسات Apex والتريجرز، ومكوّنات Lightning، والـ flows، والتخطيطات، وقواعد التحقق، ومجموعات الأذونات، ومعظم الإعدادات التصريحية. لو معاك السورس السابق تقدر ترجّعه.
• قابل للاسترجاع خلال مهلة. الحقل المخصص المحذوف بيروح Deleted Fields في Object Manager وينفع ترجّعه ببياناته خلال 15 يوم، وبعدها بيروح نهائي. ورجوع الحقل مش بيرجّع تخطيطات الصفحات اللي اتشال منها (خلفية عن استرجاع الحقول المحذوفة).
• عمليًا غير قابل للرجوع. قيم قوائم الاختيار المحذوفة، وتحويلات نوع الحقل اللي بتقص البيانات، والسجلات اللي أعاد كتابتها flow أو trigger غلط، وحقول Roll-up Summary المحذوفة عن طريق الـ Metadata API لأنها بتتخطى سلة المحذوفات تمامًا (توثيق سيلزفورس عن حذف المكوّنات).

المجموعة التالتة دي هي اللي بتوقّع خطط الرجوع. رجوع الميتاداتا بيرجّع الإعدادات، مش البيانات أبدًا. لو الإصدار بتاعك شغّل أتمتة على 400,000 سجل، إعادة نشر Apex بتاع إمبارح مش هتغيّر حاجة في السجلات دي.

إيه استراتيجيات الرجوع الواقعية؟

1. نشر عكسي من نظام التحكم في الإصدارات

أضمن خيار. لو الـ branch اللي طلع منه الإصدار موجود في Git، فالـ commit السابق هو أداة الرجوع بتاعتك. بتبني حزمة من آخر commit سليم وتنشرها فوق القديم. ده بيغطي المكوّنات اللي الإصدار غيّرها أو ضافها بس، فلازم تجمعه مع الاستراتيجية التالتة.

2. الاسترجاع من نسخة ميتاداتا محفوظة

صوّر حالة الـ org المستهدفة قبل النشر مباشرة، واستخدم النسخة دي في توليد الحزمة العكسية لو احتجتها. ده بيغطي حالة إن الـ org بعدت عن Git، وهو الوضع الشائع في أغلب فرق سيلزفورس. الأدوات في المجال ده بتأتمت التصوير والمقارنة: Gearset وAutoRABIT وBlue Canvas كلهم موثّقين رجوعًا مبنيًا على snapshot أو restore، وSerpent بيقدّم رجوع بضغطة واحدة في كل الخطط، بما فيها الخطة المجانية.

3. حذف مقصود لأي حاجة إنت ضفتها

النشر العكسي بيحدّث المكوّنات اللي كانت موجودة قبل كده. هو مش بيشيل اللي الإصدار أنشأه، فأي كائن أو حقل جديد هيفضل مكانه غير لما تحذفه صراحة. ده بيتم بملف destructiveChanges.xml، وهو ملف منفصل لازم إنت تكتبه. استخدم destructiveChangesPre.xml علشان الحذف يحصل قبل الإضافات وdestructiveChangesPost.xml علشان يحصل بعدها، وبكده بتفك الاعتماديات زي كلاس Apex لسه بيشاور على الكائن اللي عايز تشيله.

4. إصلاح للأمام بدل الرجوع

غالبًا القرار الصح. لو العطل في قاعدة تحقق واحدة أو سطر Apex، الإصلاح السريع من خلال الـ pipeline العادي أسرع وأأمن من عكس حزمة فيها 200 مكوّن. ارجع لما يكون حجم الأثر مش واضح، واصلح للأمام لما يكون صغير ومفهوم.

إزاي ترجّع نشر سيلزفورس فاشل خطوة بخطوة؟

1. وقّف الـ pipeline علشان محدش ينشر فوق الإصدار المكسور.
2. حدد حجم الأثر: أنهي مكوّنات، وأنهي أتمتة، وأنهي سجلات.
3. قرر رجوع ولا إصلاح للأمام، وبلّغ أصحاب المصلحة بقرارك.
4. ابنِ الحزمة العكسية من النسخة المحفوظة أو آخر commit سليم.
5. ضيف ملف حذف لأي حاجة الإصدار أنشأها.
6. اعمل تحقق للحزمة العكسية على الإنتاج قبل ما تشغّلها، علشان محدش يحوّل حادثة لاتنين.
7. انشر، وبعدين اتأكد من عملية الشغل نفسها مش من حالة النشر.
8. أصلح البيانات بشكل منفصل من النسخة الاحتياطية، وبعد ما الميتاداتا تستقر.

إيه اللي لازم تقرره قبل النشر؟

الرجوع قرار تصميمي بتاخده وإنت بتبني، مش وقت الأزمة. جاوب على الخمس نقط دي قبل ما الإصدار يخرج.

• فين النسخة المحفوظة من الـ org المستهدفة قبل الإصدار، وهل اشتغلت فعلًا؟
• أنهي مكوّنات في الإصدار ده واقعة في خانة غير القابل للرجوع؟
• في حاجة محتاجة ملف حذف، وهل اتكتب واتراجع؟
• في نسخة احتياطية للبيانات قريبة من الإصدار كفاية علشان تنفع؟
• مين اللي بيقرر الرجوع، وإيه الإشارة اللي بتشغّل القرار؟

التحقق قبل النشر هو أرخص وقاية موجودة. التحقق مع الاختبارات بيفضل صالح للاستخدام 10 أيام ويسمحلك بـ quick deploy لنفس الحزمة من غير إعادة تشغيل اختبارات Apex، يعني مفيش عذر لاكتشاف أخطاء التجميع في الإنتاج. في أدلة إصدار تانية في مكتبة SF Guides بتاعتنا.

FAQ

هل سيلزفورس بترجّع النشر الفاشل تلقائيًا؟

أيوه، لكن للنشر اللي بيفشل بس. النشر على الإنتاج بيتطلب rollbackOnError تكون true، فأي مكوّن فاشل بيلغي الحزمة كلها. أما النشر الناجح فمحدش بيرجّعه بدالك.

هل ينفع ترجّع change set؟

مش بشكل أصلي. مفيش زرار عكس، فالفرق بتبني change set تاني ينشر النسخة السابقة، وده مش بيشتغل غير لو حد صوّر النسخة دي قبل كده.

هل رجوع الميتاداتا بيرجّع بياناتي؟

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

عندي قد إيه علشان أسترجع حقل مخصص محذوف؟

15 يوم. الحقل بيفضل في Deleted Fields في Object Manager وينفع يترجع ببياناته خلال المهلة دي، وساعات هتحتاج ترجّعه يدويًا لتخطيطات الصفحات.