إزاي تتعامل مع التغييرات المدمرة بأمان في نشر سيلزفورس

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

يعني إيه بيان destructiveChanges؟

بيان destructiveChanges بيستخدم نفس صيغة package.xml، مع فرق مهم: رموز البدل مش مدعومة. كل مكون ناوي تشيله لازم يتسمّى بالاسم.

أبسط مدخل شكله كده: <types><members>Account.Legacy_Score__c</members><name>CustomField</name></types>.

قاعدتين بيقعوا الناس من أول محاولة:

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

الحذف يشتغل قبل النشر ولا بعده؟

واجهة أوامر سيلزفورس بتديك الاتنين عن طريق بيانين منفصلين: --pre-destructive-changes بيحذف قبل النشر، و --post-destructive-changes بيحذف بعده.

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

استخدم الحذف قبل النشر لما القديم والجديد يتصادموا. أوضح الحالات:

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

عكس الترتيب بيطلّع الفشلين الكلاسيكيين: حذف بيفشل لأن فيه حاجة لسه بتشير للمكون، أو إضافة بتفشل لأن الاسم محجوز.

الحذف بياخد معاه إيه فعلاً؟

هنا لازم نتكلم بصراحة. حذف الحقل بيحذف بياناته. المكونات المحذوفة بتروح لسلة المحذوفات إلا لو النشر ضبط purgeOnDelete، وساعتها بتبقى مؤهلة للحذف فورًا. وحقول التلخيص التراكمي بتتخطى السلة بغض النظر عن الإعداد ده.

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

وفيه كمان نوع من الكسر عمره ما بيظهر في المستودع بتاعك: التقارير وعروض القوائم ولوحات المعلومات اللي بتشير للحقل. دي إعدادات بناها مستخدم أعمال، وغالبًا مش في Git، والنشر مش هينبهك ليها.

إيه الفحوصات المسبقة اللي بتمنع حذف حقل من إنه يغلط؟

1. شغّل فحص الاعتماديات في Setup. سيلزفورس هتقولك على حقول المعادلات وقواعد التحقق والتخطيطات والإشارات التعريفية التانية. ضروري لكنه مش كافي.
2. دوّر في البيانات الوصفية باسم الواجهة. شغّل بحث نصي في المستودع. التدفقات و Apex وقوالب البريد ومجموعات الأذونات بتشير للحقول كنصوص، والإشارات النصية مش بتظهر في كل عروض الاعتماديات.
3. افحص التقارير وعروض القوائم لوحدهم. مفيش حاجة في خط الإنتاج بتعرف عنهم. لازم حد يبص.
4. صدّر البيانات الأول. ملف CSV فيه العمود ومعرّفات السجلات. بياخد عشر دقايق وهو شبكة الأمان الحقيقية الوحيدة.
5. شغّل الاختبارات المحلية. لفئات ومحفزات Apex، توصية سيلزفورس نفسها إنك تشغّل كل الاختبارات المحلية، وبكده تلاقي الكود اللي لسه بيشير للحاجة اللي بتحذفها.
6. اتأكد من صفحة Lightning نشطة. مش هتقدر تحذف مكون مرتبط بصفحة Lightning نشطة. عطّل تجاوز الإجراء في Lightning App Builder الأول.
7. تحقق في مواجهة الإنتاج. نشر checkOnly، أو --dry-run من سطر الأوامر، بيتحقق ويشغّل الاختبارات من غير ما يحفظ حاجة.

إزاي توزّع الحذف على إصدارين؟

النمط الآمن مش بيان أحسن. النمط الآمن إنك تقسّم الحذف على إصدارين.

1. الإصدار الأول: الإهمال. شيل كل إشارة: التخطيطات والمعادلات والتدفقات و Apex ومجموعات الأذونات والتقارير. علّم الحقل كمهمَل في وصفه عشان اللي بعدك يعرف. بطّل تكتب فيه. وماتنشرش أي حاجة مدمرة.
2. سيبه ينقع. خلي دورة تقارير كاملة تعدي. هنا بيطلع التقرير اللي محدش اتكلم عنه، وبيطلع كسؤال مش كحادث.
3. الإصدار اللي بعده: الحذف. صدّر البيانات، وبعدين انشر بيان destructiveChanges لوحده، ومش معاه أي حاجة تانية.

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

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

FAQ

أقدر أستخدم رمز بدل في destructiveChanges.xml؟

لأ. رموز البدل مش مدعومة. كل مكون هيتحذف لازم يتسمّى صراحةً.

لسه محتاج package.xml وأنا بحذف بس؟

أيوه. لازم تكون في نفس المجلد، وتحمل إصدار الواجهة، ومش بتسرد أي مكونات.

أقدر أسترجع حقل اتحذف بنشر؟

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

ليه النشر المدمر نجح ومحذفش حاجة؟

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

إمتى الحذف يشتغل قبل النشر مش بعده؟

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