Validation في Click Deploy: النشر التجريبي وQuick Deploy

الخلاصة: الـ validation في click deploy هو نشر check-only: Salesforce بتشغّل الحزمة واختبارات Apex بتاعتها على الـ org المستهدفة من غير ما تحفظ أي حاجة. لو نجح والاختبارات اشتغلت، بتاخد job ID تقدر تعمل بيه Quick Deploy خلال 10 أيام، من غير ما الاختبارات تشتغل تاني وقت الإصدار. اعمل validation بدري، وبعدين انشر من غير ما تستنى الاختبارات مرتين.

يعني إيه validation في click deploy؟

عمل validation للنشر معناه إنك تشغّله في وضع check-only. وحدة Trailhead عن الإصدارات من Salesforce بتوصفه بإنه تشغيل للاختبارات عشان تتأكد من النشر من غير ما المكونات تتحفظ في الـ org المستهدفة. مفيش حاجة بتتغير في الـ org. بتعرف بس هل الحزمة هتتنشر وهل الاختبارات هتنجح. وفي أدوات الـ point-and-click غالبًا بيبقى زرار Validate جنب Deploy.

Trailhead كمان بتحدد معنى النجاح: كل اختبارات Apex نجحت، والاختبارات بتغطي 75% على الأقل من الكود اللي بيتنشر.

ليه تعمل validation قبل click deploy؟

• المشاكل بتظهر بدري. الاعتماديات الناقصة وأخطاء الـ compile والاختبارات الفاشلة بتظهر كنتيجة تصلحها، مش كإصدار بايظ.
• الجزء البطيء بيخرج برة وقت الإصدار. Quick Deploy بيعيد استخدام نتايج اختبارات الـ validation، فخطوة الإنتاج مش بتشغّل اختبارات Apex تاني.
• المعتمدين بياخدوا دليل. الـ validation الناجح حاجة المراجع يقدر يتأكد منها قبل الموافقة، ودي أول gate في قائمة فحص click deploy بتاعتنا.

إزاي تعمل validation وQuick Deploy؟

1. ابني الحزمة من مصدر تثق فيه. مقارنة الـ orgs بتنفع، بس الـ branch أسهل في المراجعة. شوف click deploy من Git للطريقة دي.
2. اختار مستوى اختبار بيشغّل اختبارات فعلًا. القسم الجاي بيوضح أنهي مستويات تنفع.
3. شغّل Validate. من الـ CLI ده sf project deploy validate. وGearset وSalto الاتنين بيقدموا validation جوه مسار النشر بتاعهم، وSalto بتسألك أنهي اختبارات تشغّلها كجزء منه.
4. اقرا النتيجة واعمل validation تاني بعد كل تصليح. الـ validation بيضمن بس الحزمة بالظبط اللي اتفحصت.
5. احتفظ بالـ job ID. Trailhead بتوضح إن الـ validation بيرجّع job ID بتستخدمه في الـ quick deploy.
6. اعمل Quick Deploy جوه المهلة. استخدم زرار Quick Deploy في صفحة Deployment Status في Setup (بيظهر بس للـ validations المؤهلة)، أو sf project deploy quick مع الـ job ID، أو نداء Metadata API deployRecentValidation().
7. خلّي عندك طريق للرجوع. الـ validation النضيف بيقلل المخاطرة بس مش بيلغيها، فخطط لـ التراجع عن click deploy قبل ما تنشر.

تعمل validation بأنهي مستوى اختبار؟

• RunLocalTests: بيشغّل الاختبارات المحلية في الـ org. ومثال الإصدار في Trailhead بيستخدمه في validation الـ staging والإنتاج الاتنين.
• RunSpecifiedTests: بيشغّل بس الكلاسات اللي بتحددها. أسرع، بس الاختبارات دي لازم تغطي اللي بتنشره، وده حسب Apex Anvil معناه 75% لكل class وtrigger بيتنشر.
• RunAllTestsInOrg: بيشغّل كل اختبار في الـ org، ومعاها اختبارات الـ managed packages. أبطأ اختيار.
• NoTestRun: مش متوافق مع Quick Deploy، لأن مفيش نتايج اختبارات يعيد استخدامها.
• RunRelevantTests: اتقدم كـ beta في Spring '26. Salesforce بتختار الاختبارات المرتبطة بكود Apex اللي في الحزمة، بس Bob Buzzard لاحظ إنه بيتابع الاعتماديات المباشرة بس، فجرّبه برة الإنتاج الأول.

إيه اللي بيبطّل الـ validation؟

• المدة. الـ job ID صالح 10 أيام. بعدها اعمل validation من جديد.
• نشر تاني. مهلة الـ 10 أيام في Trailhead بتفضل سارية بس لو محدش نشر على الـ org دي أو عمل فيها تغييرات كبيرة في النص.
• اختلاف ما خدتش بالك منه. توثيق Gearset بينبّه إن التغييرات اللي حصلت في الـ orgs بعد بناء الحزمة مش بتتحسب، وممكن تتكتب فوقها وقت النشر.
• مفيش اختبارات. الـ validation اللي اشتغل بـ NoTestRun مينفعش يتعمله Quick Deploy.

القاعدة العملية: اعمل الـ validation أقرب ما يكون للإصدار على قد ما وقت الاختبارات يسمح، ووقّف أي نشر تاني على الـ org دي لحد ما تنشر.

مين هي Tekunda، وإزاي Serpent بتتعامل مع الـ validation؟

Tekunda شركة استشارات ومنتجات على Salesforce، وهي الشركة اللي ورا Serpent، منصة Salesforce DevOps اللي أطلقتها في 2024. في Serpent الـ validation خطوة ثابتة مش زرار اختياري: مسار النشر بيمشي على الإعداد، واختيار الملفات، والـ validation، والنشر. خطوة الـ validation هي dry run على الـ org المستهدفة. النتيجة النضيفة بتكمّل لوحدها، والفشل بيوقف هناك. وSerpent كمان بتنشر بس المكونات اللي الـ work item غيّرها، وده بيخلي الـ validations صغيرة. لو بتقارنها بـ إزاي ClickDeploy بيشتغل وتكلفته، فخطة Scale بـ $699 للشركة في الشهر مع عدد مستخدمين غير محدود؛ شوف صفحة الأسعار. وهتلاقي أدلة خطوة بخطوة أكتر في SF Guides.

FAQ

هل الـ validation بيغيّر أي حاجة في الـ org المستهدفة؟

لأ. ده نشر check-only، فمفيش مكونات بتتحفظ.

أقدر أستنى قد إيه قبل ما أعمل Quick Deploy؟

لحد 10 أيام، بشرط إن مفيش نشر تاني أو تغيير كبير يحصل في الـ org دي في النص.

أقدر أعمل Quick Deploy لـ validation ما شغّلش اختبارات؟

لأ. Quick Deploy بيعيد استخدام نتايج الاختبارات، فالـ validation لازم يشغّل اختبارات وينجح بالتغطية المطلوبة.

هل Quick Deploy بيشغّل اختبارات Apex تاني؟

لأ. بيعتمد على اختبارات الـ validation، وعشان كده بيخلص أسرع من النشر العادي.