قائمة فحص Click Deploy في Salesforce

باختصار: الـ click deploy بينقل الـ metadata في Salesforce من مؤسسة لأخرى عن طريق اختيار المكونات من واجهة، بدل بناء change set أو كتابة أوامر CLI. علشان تعمله بأمان: قارن المؤسسات، أضف الاعتماديات، اعمل validation بمستوى اختبار Apex مختار بعناية، وبعدها نفّذ quick deploy للحزمة اللي اتعمل لها validation وتأكد منها. القائمة الكاملة تحت.

ما هو الـ click deploy في Salesforce؟

"Click deploy" اختصار للنشر بالنقر: أداة بتقارن مؤسسة المصدر بمؤسسة الهدف، وتعرض اللي اتغيّر، وتنشر المكونات اللي بتختارها. الاسم جاي من ClickDeploy، اللي استحوذت عليها Copado في 2020 وبتبيعها حاليًا باسم Copado Essentials؛ تاريخها وأسعارها موجودين في كيف يعمل ClickDeploy وكم يكلّف. Copado Essentials وGearset وغيرهما من الأدوات القائمة على النقر بتسلّم الحزمة النهائية لـ Salesforce Metadata API، يعني قواعد المنصة بتنطبق مهما كانت الأداة. علشان كده القائمة دي تنفع في كل مكان.

كيف تنفّذ click deploy آمن خطوة بخطوة؟

1. حدّث المقارنة. قارن المصدر والهدف قبل النشر مباشرة، مش من امبارح. ممكن حد يكون غيّر في الهدف.
2. اختر التغيير وبعدين الاعتماديات. الحقل الجديد محتاج الـ object بتاعه، والـ Flow ممكن يحتاج حقول أو Apex classes أو permission sets. أغلب الأدوات بتنبّه للاعتماديات الناقصة؛ صدّق التنبيه مش ذاكرتك.
3. خلّي الحزمة صغيرة. انشر اللي اتغيّر بس. Salesforce بتحدد ملف الـ .zip للنشر بـ 39 ميجابايت، زي ما بتوضح وثائق Gearset، والحزم الصغيرة أسهل في التتبع. الـ delta deployments بتخلي ده هو الوضع الافتراضي.
4. خطّط للحذف لوحده. الحذف بيتم عبر ملفات destructive changes، وSalesforce CLI بتطبقها قبل النشر أو بعده. اختار الترتيب حسب اللي لسه بيشير للمكوّن.
5. اعمل validation الأول. شغّل تحقق check-only. بيشغّل اختبارات Apex ويعرض الأخطاء من غير ما يحفظ أي حاجة في المؤسسة.
6. اختر مستوى الاختبار عن قصد. الافتراضي مش دايمًا صح؛ شوف القسم الجاي.
7. نفّذ quick deploy للحزمة المتحقق منها. في الإنتاج، ممكن تنشر validation ناجح لاحقًا من غير ما تعيد تشغيل اختبارات Apex. مرجع الـ CLI بيقول إن رقم الـ job بيفضل صالح 10 أيام من بداية الـ validation، فتقدر تتحقق الضهر وتنشر في وقت هادي.
8. تأكد وسجّل. افتح الصفحات اللي اتغيرت، اعمل smoke test سريع، وسجّل بالظبط إيه اللي اتنشر، علشان يبقى عند الـ rollback حاجة يرجع لها.

أي مستوى اختبار Apex تختار؟

توثّق Salesforce CLI خمسة مستويات للاختبار، وأغلب أدوات النقر بتعرض نفس القائمة بأسماء أبسط:

• NoTestRun: من غير اختبارات. مسموح بس لبيئات التطوير زي الـ sandboxes ومؤسسات Developer Edition والمؤسسات التجريبية.
• RunSpecifiedTests: الاختبارات اللي بتحددها بس. دليل Gearset بيوضح إن كل class أو trigger في الحزمة لازم يغطّي 75% لوحده في الحالة دي.
• RunLocalTests: كل الاختبارات ما عدا اختبارات الحزم المُدارة وunlocked المثبتة. وده الافتراضي لنشر الإنتاج اللي فيه Apex classes أو triggers.
• RunAllTestsInOrg: كل حاجة، بما فيها اختبارات الحزم المُدارة.
• RunRelevantTests (تجريبي): Salesforce بتختار الاختبارات بتحليل الحزمة واعتمادياتها. محتاج API version 66 أو أحدث.

خلّي بالك من RunRelevantTests في الإنتاج. اختبارات Bob Buzzard على Spring '26 لقت إنه بيختار الاختبارات المرتبطة مباشرة بالكود المتغيّر، لكنه بيفوّت السلاسل غير المباشرة والـ classes اللي بتتنشأ ديناميكيًا. علّم الاختبارات الضرورية بـ @IsTest(critical=true) قبل ما تعتمد عليه.

إمتى يكون الـ click deploy الأداة الغلط؟

• أكتر من شخص بينشر على نفس المؤسسة. النشر من مؤسسة لمؤسسة مفيهوش تاريخ مشترك، فالنشر التاني ممكن يمسح الأول.
• محتاج rollback تعتمد عليه. الرجوع أسهل لما كل إصدار يكون متعمل له commit قبل ما يتنشر.
• بتنشر managed package. شركات الـ ISV بتصدر نسخ حزم للمشتركين، مش فروقات بين مؤسسات؛ شوف الحزم المُدارة من الجيل الثاني.

إنك تسيب النشر من مؤسسة لمؤسسة مش معناه إنك تسيب النقر. الأدمنز يقدروا يفضلوا يختاروا التغييرات من واجهة والأداة تكتب الـ Git commits، زي ما وضحنا في DevOps للأدمنز من غير لمس Git.

كيف تتعامل Tekunda مع النشر بالنقر؟

Tekunda شركة استشارات ومنتجات Salesforce، وهي الشركة وراء Serpent، منصة DevOps بتستخدمها كمان في تسليم مشاريع عملائها. Serpent بيحافظ على تجربة الاختيار بالنقر: بتختار التغييرات، وتربطها بتذكرة، وترقّيها عبر الـ pipeline، بينما Git والـ pull requests والـ validation واختبارات Apex شغالة تحت، مع مراجعة كود بالذكاء الاصطناعي في كل خطة. مش بيثبّت أي حاجة في مؤسستك وبيبدأ مجانًا، بتسعير ثابت للفريق على صفحة الأسعار. أدلة أكتر موجودة في مكتبة SF Guides.

FAQ

هل الـ click deploy هو نفسه الـ change set؟

لا. الاتنين بينقلوا metadata بين المؤسسات، لكن أداة النقر بتبني الحزمة من مقارنة بين المؤسسات بدل ما تضيف المكونات للـ change set واحد واحد.

قد إيه أقدر أستنى بين الـ validation والـ quick deploy؟

لحد 10 أيام من بداية الـ validation، حسب مرجع Salesforce CLI.

هل النشر على الـ sandbox بيشغّل اختبارات Apex؟

مش افتراضيًا. المستوى الافتراضي في Salesforce مش بيشغّل اختبارات في الـ sandbox، بينما نشر الإنتاج اللي فيه Apex classes أو triggers بيشغّل الاختبارات المحلية.

هل أقدر أعمل click deploy مجانًا؟

أيوه. Copado Essentials فيها مستوى مجاني لحد 15 عملية نشر في الشهر لمستخدم واحد، وSerpent كمان عنده خطة مجانية.