ما الذي تغيّر في إصدار Summer '26 لفرق DevOps على Salesforce

باختصار: إصدار Summer '26 يأتي بنسخة API رقم 67.0، وبالنسبة لفرق DevOps هناك ثلاثة بنود تزن أكثر من كل ما عداها مجتمعًا. عمليات قاعدة البيانات في Apex صارت تعمل افتراضيًا في وضع المستخدم، والفئات التي لا تحمل كلمة مشاركة صارت افتراضيًا with sharing، وWITH SECURITY_ENFORCED لم يعد يُترجَم أصلًا. وهذه الثلاثة كلها مرتبطة بنسخة API التي حُفظت عندها الفئة، ما يحوّل إعداد نسخة API في خط إصدارك إلى قرار سلوكي لا إلى عملية ترتيب.

عن أي إصدار نتحدث ومتى وصل؟

‏Summer '26 هو نسخة API رقم 67.0. فُتحت المعاينة في بيئات الاختبار يوم 8 مايو 2026، وجرى الطرح في الإنتاج أيام 15 مايو و5 يونيو و12 إلى 13 يونيو 2026، أي أنك على الأرجح تعمل عليه بالفعل. والقائمة الكاملة في ملاحظات الإصدار، وما يلي هو الجزء الذي يمس النشر والبيانات الوصفية وسلوك الواجهات البرمجية.

ما الذي يكسر خط الإصدار فعليًا في Summer '26؟

ثلاثة أمور، مرتبة بحسب سرعة أثرها.

1. WITH SECURITY_ENFORCED أُلغي ولم يعد يُترجَم. هذا صريح وفوري: أي نشر ما زال يحمل هذه العبارة يُفشل البناء. استبدلها بـ WITH USER_MODE كما ورد في دليل المطورين للإصدار.
2. عمليات قاعدة البيانات في Apex تعمل افتراضيًا في وضع المستخدم. فمن نسخة 67.0 فصاعدًا تعمل عمليات DML وSOQL بصلاحيات الكائنات وأمن مستوى الحقول وقواعد المشاركة الخاصة بالمستخدم الحالي، ما لم تحدد غير ذلك.
3. الفئات بلا كلمة مشاركة صارت افتراضيًا with sharing. والافتراضي القديم كان العكس. فالشيفرة التي كانت تعتمد بصمت على وصول وضع النظام صارت تُرجع بصمت بيانات أقل.

أما المشغّلات (triggers) فما زالت تعمل في وضع النظام عبر كل النسخ. مخرج مفيد للتذكر، وخطر للاتكاء عليه.

لماذا تغيير المشاركة مشكلة نشر لا مشكلة شيفرة؟

هذا هو الجزء الذي تغفله معظم ملخصات الإصدار. فالافتراضات الجديدة تنطبق على الفئات المحفوظة عند نسخة API 67.0 أو أحدث. أي أن سلوك بيئتك لا يتغير يوم وصول الإصدار، بل يوم ترفع فيه خطوط إصدارك نسخة API.

وهذا يرفع ثلاثة أسطر في مستودعك إلى مرتبة التغييرات الوظيفية:

• sourceApiVersion في sfdx-project.json
• عنصر النسخة في package.xml
• نسخة API لكل فئة في كل ملف .cls-meta.xml

وتتبعه ثلاث نتائج، ولا واحدة منها نظرية.

• اختباراتك لن تلتقطه. فاختبارات Apex تعمل في سياق تتحكم فيه عادة، فتنجح الفئة في كل التأكيدات وتظل تُرجع صفوفًا أقل لمستخدم حقيقي.
• رفع نسخة API جماعيًا إصدار لا مهمة روتينية. عامل "ارفع كل شيء إلى 67.0" كتغيير يحتاج اختبار قبول بملفات تعريف حقيقية، لا كتذكرة ترتيب.
• الرفع الجزئي يخلق سلوكًا منقسمًا. فئتان في سلسلة استدعاء واحدة على نسختي API مختلفتين ستتصرفان بشكل مختلف. فإن رفعت، ارفع مجالًا كاملًا في المرة الواحدة.

الترتيب الآمن أن تعلن المشاركة صراحة على كل فئة أولًا، ثم ترفع نسخة API. فالتصريح يتفوق على الافتراضي في الاتجاهين.

أي عمليات إيقاف تستحق مكانًا في قائمة الأعمال الآن؟

• نسخ واجهات المنصة من 31.0 إلى 40.0. مهملة، مع إيقاف كامل في Summer '28 تفشل بعده تلك الاستدعاءات. وكل شيء يجب أن يكون على 41.0 أو أحدث.
• دالة login() في واجهة SOAP للنسخ من 31.0 إلى 64.0، وتُوقَف في Summer '27.
• معرّفات الجلسات من الحزم المُدارة لمصادقة Apex المجهول، ويُفرض ذلك اعتبارًا من Summer '27.

لا شيء من هذا عاجل في هذه الدورة، لكنها جميعًا من النوع الذي يُكتشف بعد ثمانية عشر شهرًا في الثانية فجرًا عبر تكامل يسقط. أجرِ جرد نسخ API ما دام رخيصًا.

ما الجديد فعلًا لخطوط التكامل والنشر؟

• منطق Data 360 داخل خط الإصدار. تنقل حِزم بيانات DevOps امتدادات الشيفرة وتحويلات البيانات من بيئة الاختبار إلى الإنتاج مع امتدادات الشيفرة المرتبطة، فيرقّي خط الإصدار منطق Data 360 كما يرقّي Apex وLWC.
• تقييم الوكلاء كبيانات وصفية. تُنشَر مقاييس Custom Scorers عبر Metadata API باستخدام aiAgentScorerDefinitions، ما يضع بوابات جودة الوكلاء تحت إدارة الإصدارات.
• خيار في بيئة الـ scratch ستتعثر فيه. صارت اختبارات التكامل تتطلب ApexIntegrationTests ضمن مصفوفة features في تعريف بيئة الـ scratch. أضِفه قبل أن يفشل تشغيلك التالي بلا سبب ظاهر.
• ‏DevOps Center يصير أصليًا. ذكرت Salesforce Ben في يونيو 2026 أن الجيل التالي من DevOps Center يتخلى عن الحزمة المُدارة لصالح قدرة أصلية، مع خادم DX MCP لتشغيل خط الإصدار من محرر برمجي وكيلي. يستحق المتابعة، ولا يستحق تغيير المنصة بعد.

ماذا تفعل هذا الأسبوع؟

1. ابحث في المستودع عن WITH SECURITY_ENFORCED واستبدله. هذا كسر بناء لا تحذير.
2. اجرد كل فئة بلا كلمة مشاركة صريحة، واحسم أمر كل واحدة بوعي.
3. جمّد رفع نسخ API جماعيًا حتى تنتهي الخطوة الثانية.
4. اجرد عمليات التكامل التي ما زالت تستدعي النسخ من 31.0 إلى 40.0.
5. أضِف ApexIntegrationTests إلى تعريف بيئة الـ scratch لديك.

FAQ

هل يغيّر Summer '26 سلوك شيفرة Apex القائمة؟

ليس من تلقاء نفسه. فالافتراضات الجديدة لوضع المستخدم والمشاركة تنطبق على الفئات المحفوظة عند نسخة API 67.0 أو أحدث، فتحتفظ الفئات القائمة بسلوكها حتى ترفع نسخة API الخاصة بها.

ما البديل عن WITH SECURITY_ENFORCED؟

استخدم WITH USER_MODE. فالعبارة القديمة أُلغيت ولم تعد تُترجَم، وأي نشر ما زال يحملها سيفشل.

متى تتوقف نسخ API القديمة عن العمل فعلًا؟

النسخ من 31.0 إلى 40.0 مهملة مع إيقاف كامل في Summer '28، ودالة login() في SOAP للنسخ من 31.0 إلى 64.0 تُوقَف في Summer '27. انقل عمليات التكامل إلى 41.0 أو أحدث.

هل تؤثر هذه التغييرات على مشغّلات Apex؟

لا. المشغّلات تستمر في العمل بوضع النظام عبر كل نسخ API.

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