إزاي تحل تعارضات ميتاداتا Salesforce من غير ما تضيّع شغل حد

الإجابة باختصار: معظم تعارضات الدمج في Salesforce مش خلافات حقيقية. غالبًا اتنين بيضيفوا حاجات مالهاش علاقة ببعض في نفس ملف الـ XML الضخم، أو نفس العناصر راجعة بترتيب مختلف. مع الميتاداتا الإضافية زي البروفايلات والـ permission sets والـ layouts والـ labels، خُد الطرفين مع بعض. ومتدمجش يدويًا الـ XML المولَّد زي الـ Flows: اختار نسخة واحدة وأعِد تطبيق التغيير التاني من Flow Builder.

ليه تعارضات Salesforce مختلفة عن تعارضات الكود العادية؟

أربع خصائص في المنصة بتفسر تقريبًا كل الحالات.

• ترتيب العناصر مش مضمون. الـ Metadata API ممكن ترجّع نفس الملف بترتيب عناصر مختلف، فيبلّغ Git عن تعارض من غير ما يكون في تغيير فعلي. دي تعارضات وهمية.
• بعض الأنواع ملف واحد ضخم. البروفايل بيحمل صلاحيات الأوبچكتس والحقول وكلاسات Apex والصفحات في مستند واحد. فاتنين شغالين على فيتشرز مختلفة تمامًا بيكتبوا في نفس السطور.
• جزء من الـ XML مولَّد آليًا. تعريف الـ Flow فيه إحداثيات الكانفس وأسماء عناصر مولَّدة. مش مصمم للتعديل اليدوي، ومش آمن تدمجه بإيدك.
• Git بيحل نصوص، وSalesforce بتتحقق من المعنى. دمج نظيف نصيًا ممكن ينتج ملف يرفضه النشر، أو ملف صالح لكنه شال صلاحية حد من غير ما حد ياخد باله.

أنهي أنواع الميتاداتا بتتعارض أكتر، وتعمل إيه في كل نوع؟

البروفايلات والـ permission sets

أسوأ الأنواع، وغالبًا إضافية بحتة. كل فرع بيضيف بلوك objectPermissions أو fieldPermissions، والإضافتين بيقعوا جنب بعض. خُد الطرفين، وبعدين شيل التكرار على أساس العنصر المفتاحي (field أو object أو apexClass) وأعِد الترتيب. متحلش تعارض بروفايل أبدًا بقبول طرف واحد بالكامل.

معلومة مهمة: Salesforce ألغت خطة سحب الصلاحيات من البروفايلات (مقال Salesforce Help رقم 003834041)، يعني البروفايلات مش رايحة في تاريخ محدد، والمشكلة دي مش هتحل نفسها. وبرضه Salesforce لسه بتوصي بنموذج أقل الامتيازات المبني على الـ permission sets، ونقل الصلاحيات بره البروفايلات بيقلّل فعلًا مساحة التعارض، لأن الـ permission sets ملفات صغيرة لكل فيتشر.

الـ Flows

متدمجهاش يدويًا. الـ XML فيه أسماء عناصر مولَّدة وإحداثيات كانفس، فالدمج على مستوى السطر بيطلّع حاجة شكلها منطقي وسلوكها غلط. اختار نسخة تكسب، وأعِد تطبيق التغيير التاني من Flow Builder.

الـ Page layouts وصفحات Lightning

ملف الـ layout بيسرد كل عنصر بترتيب موضعه، فاتنين بيضيفوا حقول في أقسام مختلفة ممكن يتصادموا برضه لو الأقسام متجاورة. اجمع الطرفين، وبعدين اتأكد إن كل layoutItem من الطرفين لسه موجود. ولو التعارض في صفحة Lightning أكبر من كام سطر، أعِد بناءها من Lightning App Builder بدل ما تدمجها.

الأوبچكتس والحقول المخصصة

لو الريبو بيخزّن الأوبچكت في ملف واحد، كل تعديل حقل بيلمس الملف ده. صيغة المصدر المفكّكة بتدي لكل حقل ملف مستقل وبتشيل معظم التعارضات دي قبل ما تحصل.

كلاسات Apex والـ triggers

عاملهم كتعارض كود عادي، لأنهم كده فعلًا. حل المنطق، وشغّل الاختبارات تاني، وبعدين اتأكد إن الكلاس لسه متمنوح في البروفايلات والـ permission sets اللي بتشاور عليه.

الـ custom labels والترجمات

ملفات مفردة مرتبة أبجديًا وإضافية بحتة. خُد الطرفين وأعِد الترتيب.

إزاي تقرأ الـ diff قبل ما تحل أي حاجة؟

1. حدد كل طرف مين. في الدمج، "ours" هو الفرع الهدف و"theirs" هو الوارد. وفي الـ rebase الاتنين بيتبدلوا. الخلط ده أشهر سبب لضياع الشغل.
2. استبعد الفروق اللي في الترتيب بس. لو الطرفين فيهم نفس العناصر بترتيب مختلف، يبقى محدش غيّر حاجة.
3. دوّر على المحذوفات مش على الإضافات. الإضافات غالبًا آمن تجمعها. البلوك اللي موجود في طرف وناقص في التاني هو التغيير اللي بيضيّع يوم شغل على حد.
4. قارن بالأورج الهدف مش بالفرع بس. ممكن حد يكون عدّل في الأورج مباشرة بعد ما الفرع اتعمل.
5. اعمل تحقق قبل ما تدمج الـ pull request. XML بيتدمج بنظافة ممكن برضه يسقط في تحقق النشر.

إزاي تحل تعارض بروفايل من غير ما تمسح صلاحية زميلك؟

1. اسرد البلوكات المتعارضة بالعنصر المفتاحي بتاعها مش برقم السطر.
2. احتفظ بالطرفين في أي بلوك موجود في طرف واحد بس.
3. لو نفس المفتاح ظهر في الطرفين بقيم مختلفة، قرر صلاحية صلاحية وسجّل السبب في الـ pull request.
4. شيل علامات التعارض وأعِد ترتيب الملف عشان الـ diff الجاي يفضل صغير.
5. اعمل تحقق للملف المدموج مقابل الأورج الهدف.
6. اطلب من المؤلفين الاتنين يأكدوا إن صلاحيتهم لسه موجودة بعد الدمج. بتاخد دقيقة وبتمسك اللي المراجعة بتفوّته.

إزاي تحل تعارض Flow بأمان؟

1. خُد النسخة الموجودة أصلاً على الفرع الهدف كأساس واستبعد الطرف التاني في Git.
2. افتح ساندبوكس فيها النسخة الأساس دي وأعِد تطبيق تغيير المؤلف التاني من Flow Builder.
3. اسحب الـ flow واعمل commit للملف المسحوب كحل للتعارض.
4. شوف أنهي نسخة نشطة في الأورج الهدف قبل النشر، لأن نشر الـ flow بيضيف نسخة مش بيستبدل نسخة.

إزاي تمنع التعارض الجاي؟

• فروع قصيرة العمر، بتتدمج في نفس الأسبوع اللي اتفتحت فيه.
• فيتشر واحدة لكل pull request.
• صلاحيات في permission sets لكل فيتشر بدل بروفايلات مشتركة.
• أوبچكتس متخزنة بصيغة مصدر مفكّكة.
• اسحب الفرع الهدف جوه فرعك قبل ما تفتح الـ PR، عشان تحل التعارض في وقتك وتغييرك لسه في دماغك.

الدليل ده جزء من أدلة Salesforce DevOps عندنا.

FAQ

هل Git يقدر يحل تعارضات ميتاداتا Salesforce لوحده؟

نصيًا بس. Git مش قادر يعرف إن بلوكين في البروفايل مستقلين، ولا إن ملف معاد ترتيبه ما اتغيرش، فبيطلّع تعارضات وهمية وبيقبل بسهولة دمج غلط من ناحية المعنى.

يعني إيه تعارض وهمي؟

تعارض الطرفين فيه نفس الميتاداتا بترتيب مختلف. الـ Metadata API مش بتضمن ترتيب العناصر، فسحبتين ممكن يختلفوا من غير أي تغيير حقيقي.

ينفع أعدّل XML الـ Flow بإيدي لحل تعارض؟

لأ. اختار نسخة، وأعِد تطبيق التغيير التاني من Flow Builder، واعمل commit لللي بتسحبه.

ليه البروفايلات بتتعارض وإحنا شغالين على فيتشرز مختلفة خالص؟

البروفايل ملف واحد بيغطي صلاحيات كل أوبچكت وحقل وكلاس في الأورج، فالفيتشرز غير المرتبطة بتكتب في سطور متجاورة.

إزاي أتأكد إن الدمج ما ضيّعش حاجة؟

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