كيف تنشر Custom Metadata Types دون كسر المشتركين

الإجابة المختصرة: حدد مين يملك كل حقل قبل أول إصدار، لأن الاختيار ده صعب ترجع فيه. خلّي القيم اللي العملاء هيعدّلوها subscriber editable، وخلّي القيم اللي الكود بتاعك معتمد عليها upgradeable، واعتبر قيم قوائم الاختيار وأسماء السجلات المحمية دائمة، واختبر كل ترقية على مؤسسة فيها بالفعل تعديلات العملاء.

ماذا يعني "كسر المشتركين" في custom metadata؟

ترقية custom metadata بتكسر المشترك بواحدة من ثلاث طرق:

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

الثلاثة راجعين لقرارات التغليف اللي اتاخدت قبل أول إصدار، مش لأمر النشر نفسه. علشان كده الطريق الآمن بيبدأ من تعريف النوع.

أي إعداد لإدارة الحقول تختار؟

كل حقل في custom metadata type مُغلَّف بياخد واحد من ثلاث إعدادات، زي ما بتشرح وحدة Trailhead من Salesforce عن حماية custom metadata:

• Upgradeable (تحت تحكم المطوّر): تقدر تغيّر القيمة من خلال ترقيات الحزمة. المشتركين ما يقدروش يعدّلوها.
• Subscriber editable: المشترك يقدر يعدّل القيمة بعد التثبيت، وترقيات الحزمة ما بتكتبش فوق تعديلاته.
• Locked: لا إنت ولا المشترك تقدروا تعدّلوا الحقل بعد الإصدار.

القاعدة العملية: لو العميل ممكن في يوم يحب يظبط القيمة، خليها subscriber editable واقبل إنك مش هتقدر تصححها في مؤسسته تاني. لو القيمة بتحدد سلوك الكود بتاعك، خليها upgradeable. واستخدم locked بس للقيم اللي لازم ما تتغيرش أبدًا. خد بالك إن حقول subscriber editable على السجلات المحمية بتتقفل بعد الإصدار، فخطط للحماية والإدارة مع بعض.

ما الذي يصبح دائمًا بعد الإصدار؟

• قيم قوائم الاختيار بتقبل الإضافة بس. دليل تطبيق custom metadata من Salesforce بيقول إن المطورين يقدروا يضيفوا قيم لحقل قائمة اختيار مُغلَّف، لكن ما يقدروش يحذفوها أو يعطلوها، والمشتركين ما يقدروش يغيّروها خالص. كمان حقل قائمة اختيار فيه قيم غير نشطة بيمنع رفع الحزمة لحد ما تحذف القيم دي أو ترجّع تنشّطها.
• أسماء السجلات المحمية ثابتة. حسب مرجع Metadata API، الـ developer name لأي سجل محمي ما ينفعش يتغير بعد الإصدار. سمّي السجلات كأنها API عام.
• الحماية بتتخفف بس. النوع المحمي ممكن يبقى public، لكن النوع الـ public ما ينفعش يرجع protected. والأنواع المحمية ما بتتعملش غير في مؤسسات Developer Edition والـ scratch orgs.
• إنت بس اللي بتضيف حقول. المشتركين ما يقدروش يضيفوا حقول custom لـ custom metadata type مُدار، فخطط مجموعة الحقول قبل ما تطلق.

ماذا يحدث للسجلات التي تزيلها من الحزمة؟

في الحزم المُدارة من الجيل التاني، سجلات custom metadata اللي بتتشال بتتعلّم deprecated لو كانت ظاهرة لمؤسسة المشترك، وبتتحذف نهائيًا لو مش ظاهرة، حسب دليل Salesforce لإزالة مكونات البيانات الوصفية من حزم 2GP. المكونات الـ deprecated بتفضل موجودة لحد ما مسؤول المشترك يحذفها، والـ Setup Audit Trail بيسجّل اللي الترقية شالته. ونتيجتين لده:

• ما تفترضش إن السجل المشال اختفى. السجل الظاهر ممكن يفضل deprecated في مؤسسة المشترك، فالكود لازم يبطّل يشير له بدل ما يعتمد على غيابه.
• ما تعيدش استخدام اسم اتشال. Salesforce بتوثّق ترقية فشلت لأن مكوّن deprecated متبقي اتعارض مع مكوّن جديد اتضاف بنفس الاسم.

لو بتبني نموذج الحزم من الأول، دليلنا عن تغيير أدوات Salesforce DevOps من غير ما تكسر خط النشر بيوضح إزاي تحافظ على تاريخ الحزمة وإنت بتغيّر الأداة.

كيف تنشر ترقية custom metadata بأمان؟

1. راجع النوع، مش السجلات بس. تغييرات الإدارة والحماية وقوائم الاختيار هي اللي ما ينفعش ترجع فيها، فعلّم عليها في طلب الدمج.
2. غلّف القيم الافتراضية، مش إعدادات العميل. اطلق السجلات اللي إنت محتاج تملكها. وسيب القيم الخاصة بكل عميل لحقول subscriber editable أو لسجلات المشتركين بيعملوها بنفسهم.
3. ابنِ مؤسسة لاختبار الترقية. ثبّت آخر نسخة اتطلقت، عدّل قيم subscriber editable واعمل كام سجل عميل، وبعدين ثبّت النسخة الجديدة فوقها.
4. اتأكد من اللي فضل. تعديلات المشترك لازم تكون سليمة، والقيم الـ upgradeable اتحدثت، والسجلات المشالة deprecated ومحدش بيشير لها.
5. غيّر السجلات من Apex عن طريق Metadata API بس. Apex ما يقدرش يستخدم DML على سجلات custom metadata. بينشرها بشكل غير متزامن باستخدام Metadata.Operations.enqueueDeployment وكلاس Metadata.DeployCallback، وSalesforce بتحدد عدد عمليات النشر دي اللي ممكن تكون في الطابور في نفس الوقت.
6. خد الكاش في حسابك. سجلات custom metadata بتتخزن في الكاش بعد أول قراءة، والطلبات اللي شغالة وقت التحديث ما بتشوفش القيم الجديدة. فحوصات ما بعد التثبيت ما تتوقعش تغيير فوري.

لما فرعين يعدّلوا نفس سجل .md-meta.xml، اتبع دليلنا عن حل تعارضات دمج البيانات الوصفية في Salesforce من غير ما حد يخسر شغله.

هل يهمك هذا لو لا تطلق حزمة مُدارة؟

أيوه، بس بدرجة أقل. الفرق الداخلية كمان بتنشر سجلات custom metadata بين الـ sandboxes والإنتاج، ونشر سجل من المصدر بيكتب فوق النسخة اللي في المؤسسة الهدف. لو المسؤولين بيظبطوا السجلات مباشرة في الإنتاج، أول نشر جاي من Git هيرجّعها بهدوء. يا إما تخلي Git المكان الوحيد اللي السجلات دي بتتغير فيه، يا إما تشيل السجلات اللي يملكها المسؤولين من النشر. دليلنا عن إزاي المسؤولين ينشروا من غير ما يلمسوا Git بيوضح إزاي تديهم مسار متتبَّع بدل التعديل المباشر.

أين يأتي دور Serpent؟

Serpent هي منصة Salesforce DevOps من تطوير Tekunda. بتنشر custom metadata عبر نفس خط النشر المُراجَع زي باقي البيانات الوصفية، مع مراجعة كود بالذكاء الاصطناعي وموافقة بشرية قبل الإنتاج، علشان أي تغيير في الإدارة أو قوائم الاختيار ياخد عين تانية قبل ما يتطلق. قارن خطط Serpent، أو تصفح أدلة SF Guides عن التغليف وCI/CD.

FAQ

هل ترقية الحزمة تكتب فوق قيم custom metadata الخاصة بالمشتركين؟

في الحقول الـ upgradeable بس. ترقيات الحزمة عمرها ما بتكتب فوق قيم المشترك عدّلها في حقل subscriber editable.

هل أقدر أحذف قيمة من قائمة اختيار في custom metadata type مُغلَّف؟

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

هل يقدر Apex يحدّث سجلات custom metadata؟

أيوه، بس مش بـ DML. استخدم Metadata.Operations.enqueueDeployment، اللي بينشر بشكل غير متزامن وبيرجّع النتيجة من خلال كلاس callback.

مين بيطوّر Serpent؟

Tekunda هي اللي بتطوّر Serpent، منصة Salesforce DevOps فيها CI/CD ومراجعة كود بالذكاء الاصطناعي وعمليات نشر بموافقة بشرية.