أخطاء Click Deploy: ليه عمليات نشر Salesforce بتفشل وإزاي تصلحها

باختصار: الـ click deploy نادرًا ما بيفشل بسبب الزرار. هو بيفشل لأن Salesforce Metadata API بترفض الحزمة، وتقريبًا كل رفض بيقع في واحدة من خمس مجموعات: اعتمادية ناقصة، أو تغطية اختبارات قليلة، أو إصدار API مش معروف في الـ org الهدف، أو حد من حدود الحجم في المنصة، أو تغيير الـ API مش بتقدر تعمله. اقرا أول خطأ، صلّح السبب في المصدر، واعمل validation تاني قبل ما تنشر.

إيه اللي بيحصل لما تدوس deploy في Salesforce؟

أيًا كانت الأداة اللي بتدوس فيها، نفس الشيء بيحصل تحت. الأداة بتبني ملف package.xml وملف .zip للـ metadata اللي اخترتها، وتبعتهم للـ Metadata API، وSalesforce بتعمل compile، وتشغّل اختبارات Apex على مستوى الاختبار اللي اخترته، وتحفظ النتيجة. لو أدوات الـ point-and-click جديدة عليك، ابدأ بـ إزاي ClickDeploy بيشتغل وبكام.

قاعدتين في المنصة بيفسروا أغلب المفاجآت:

• الافتراضي هو الكل أو لا شيء. خطأ واحد بيرجّع النشر كله. مرجع Salesforce CLI فيه flag لتجاهل الأخطاء وتخطي الـ rollback، وبيقول صراحة ما تستخدموش أبدًا وانت بتنشر على الإنتاج.
• الـ sandbox والإنتاج بيختبروا بشكل مختلف. المستوى الافتراضي ما بيشغلش أي اختبارات في الـ sandbox، بينما النشر على الإنتاج اللي فيه Apex classes أو triggers بيشغّل كل الاختبارات المحلية. عشان كده النشر ممكن ينجح في UAT ويفشل في الإنتاج.

ليه عمليات الـ click deploy بتفشل؟

1. فيه اعتمادية ناقصة

الحزمة بتشير لحاجة مش موجودة في الـ org الهدف: field من غير الـ object بتاعه، أو Flow من غير الـ fields اللي بيقراها، أو child object من غير الـ parent. Copado Essentials، الأداة اللي كان اسمها ClickDeploy، بتوثّق حالة كلاسيكية: نشر detail object لوحده بيرجّع Cannot set sharingModel to ControlledByParent on a CustomObject without a MasterDetail relationship field. الحل إنك تضيف الـ parent object للنشر، حتى لو ما اتغيرش.

2. تغطية اختبارات Apex قليلة

Salesforce بتشترط إن 75% على الأقل من كود Apex يكون متغطي باختبارات وحدة عشان تنشر على الإنتاج، وكل trigger محتاج سطر واحد متغطي على الأقل. لو اخترت RunSpecifiedTests، المعيار بيتغير: الاختبارات اللي بتحددها لازم تغطي 75% من كل class وكل trigger في الحزمة لوحده. الحل اختبارات أحسن، مش مستوى اختبار مختلف.

3. إصدار الـ API أحدث من الـ org الهدف

خطأ زي Invalid api version غالبًا بيظهر حوالين مواعيد الإصدارات، لما يكون الـ sandbox بتاعك شغال على إصدار Salesforce الجاي والإنتاج لسه لأ. Winter '27 مثال حي: الـ sandboxes دخلت الـ preview في أواخر أغسطس 2026، بينما instances الإنتاج بتترقى على كذا ويك إند لحد أكتوبر، فراجع الـ instance بتاعك على Salesforce Trust. نصيحة Copado إنك ترجّع إصدار الـ API بتاع الـ component لإصدار الإنتاج بيدعمه، وتنشر تاني.

4. الحزمة كبيرة أوي

مكتبة النشر الخاصة بـ Salesforce نفسها، source-deploy-retrieve، بتحذّر لما النشر يقرّب من حدود الـ Metadata API: 10,000 ملف وحوالي 39 MB مضغوط. الاختيارات بالـ wildcard ونشر objects كاملة بيوصلوا للحدود دي الأول. قسّم الإصدار، أو انشر اللي اتغير بس باستخدام الـ delta deployments.

5. تغيير الـ API مش بتعمله

• الـ Flows النشطة. دليل الـ Flows من Copado بيقول إنك ما تقدرش تنشر نسخة Flow نشطة في الـ org الهدف. اعمل منها نسخة جديدة في المصدر، انشرها، وفعّلها في الهدف. وبيحذّر كمان إن نشر الـ component اللي اسمه FlowDefinition غالبًا بيرجّع invalid version number.
• تحويل الـ picklist. الـ picklist العادية ما ينفعش تتحول لـ global value set عن طريق النشر. الحل البديل من Copado إنك تعمل field جديد على الـ global value set وتوقف القديم.

إزاي تشخّص click deploy فاشل خطوة بخطوة؟

1. اقرا أول خطأ، مش آخر خطأ. field واحد ناقص ممكن يعمل عشرات الأخطاء اللي بعده.
2. حدد المجموعة. اعتمادية، تغطية، إصدار، حجم، أو تغيير مش مدعوم. كل واحدة ليها حل مختلف.
3. صلّح المصدر، مش الهدف. تعديل الإنتاج بإيدك بيخلي المقارنة الجاية تكدب.
4. اعمل validation تاني. شغّل نشر check-only بنفس مستوى الاختبار اللي الإنتاج هيستخدمه.
5. انشر الحزمة اللي اتعملها validation. قائمة مراجعة الـ click deploy بتاعتنا بتشرح مستويات الاختبار والـ quick deploy.

إيه اللي الـ click deploy الناجح ما بيقولهولكش؟

النشر الأخضر معناه بس إن Salesforce قبلت الحزمة. مش معناه إن الهدف بقى زي المصدر:

• صلاحيات البروفايل المقفولة. Copado بتوثّق إن الـ Metadata API بتسيب الـ user permissions المقفولة برا البروفايلات اللي بتسترجعها، فصلاحية مقفولة في المصدر ممكن تفضل مفتوحة في الهدف.
• الحذف. بيتنقل لوحده، كـ destructive changes قبل النشر أو بعده.
• شغل حد تاني. النشر من org لـ org ما بيحتفظش بتاريخ مشترك، فنشر تاني ممكن يكتب فوق الأول من غير ما حد ياخد باله. النشر من branch في Git بيحل المشكلة دي.

مين هي Tekunda، وإزاي Serpent بتقلل النشر الفاشل؟

Tekunda شركة استشارات ومنتجات Salesforce، وهي اللي ورا Serpent، منصة الـ DevOps اللي بتستخدمها في تسليم شغل عملائها. Serpent بتحافظ على تجربة الاختيار بالضغط، لكن كل تغيير بيعدي على Git وpull request وvalidation باختبارات Apex قبل ما يوصل للـ org اللي بعده، مع مراجعة كود بالذكاء الاصطناعي في كل الخطط، حتى المجانية. ومش بتثبّت أي حاجة في الـ org بتاعك. الفرق اللي شغالة على Copado Essentials أو Gearset أو Salto أو AutoRABIT أو Flosum أو Blue Canvas تقدر تمشي على مسار الانتقال بتاعنا، وأدلة أكتر موجودة في مكتبة SF Guides.

FAQ

ليه النشر بينجح في الـ sandbox ويفشل في الإنتاج؟

الـ sandboxes ما بتشغّلش اختبارات Apex افتراضيًا، بينما الإنتاج بيشغّل الاختبارات المحلية ويفرض تغطية 75%. اعمل validation على الإنتاج بنفس مستوى الاختبار الأول.

يعني إيه "invalid api version"؟

الـ component بتاعك بيستخدم إصدار API الـ org الهدف لسه ما بيدعموش، غالبًا وقت الإصدارات. نزّل إصدار الـ component وانشر تاني.

ينفع أتجاهل الأخطاء وأنشر برضه؟

Salesforce CLI فيها flag لتجاهل الأخطاء بيتخطى الـ rollback، لكن المرجع بتاعها بيقول ما تستخدموش أبدًا على الإنتاج.

قد إيه components ينفع يكونوا في نشر واحد؟

الـ Metadata API بتحدد النشر بـ 10,000 ملف وحوالي 39 MB مضغوط. قسّم الإصدارات الأكبر.