التطوير المعتمد على المصدر في Salesforce، شرح مبسط

التطوير المعتمد على المصدر في Salesforce يعني إن مستودع Git، مش الـ org، هو مصدر الحقيقة الوحيد. كل تغيير بيعيش كملف بإصدار، وكل عملية نشر بترجع لـ commit محدد، وخط الإنتاج بيعيد بناء البيئات من المصدر ده بدل ما تنقل الميتاداتا بين الـ orgs بإيدك. ده الموديل اللي اتبنى حواليه Salesforce DX، وفي 2026 بقى الافتراض الأساسي ورا أي عملية إصدار جادة.

يعني إيه التطوير المعتمد على المصدر في Salesforce؟

في الطريقة الكلاسيكية، الـ org بيتعامل كمصدر للحقيقة. بتعمل التغييرات في sandbox، وتجمعها في change set، وتدفعها للأمام، وأنت متأمل إن مفيش حاجة تنحرف في الطريق. التطوير المعتمد على المصدر بيقلب ده. الميتاداتا بتاعتك بتعيش كملفات في نظام التحكم بالإصدارات، والـ org بيبقى انعكاس لما بيقوله المستودع. زي ما دليل DX الرسمي من Salesforce بيوضح، تتبّع المصدر بيراقب اللي بتنشئه أو تعدّله أو تحذفه علشان المستودع والـ org يفضلوا متسقين مع بعض.

العائد هو إمكانية التتبّع. كل تغيير في الإنتاج بيرتبط بـ commit محدد، ومراجعة الكود بتحصل قبل الدمج، وبتاخد سجل تدقيق كامل ببلاش. الحوكمة دي مش رفاهية في org خاضع للتنظيم؛ دي السبب اللي خلّى التطوير المعتمد على المصدر ينتصر.

إيه الفرق بينه وبين org development model؟

Salesforce بيقدّم موديلين للتطوير، والفرق في جوهره عن تتبّع المصدر:

• Org development model: بتشتغل على orgs مش بتتبّع المصدر، زي الإنتاج، أو orgs من نوع Developer Edition، أو sandboxes غير متتبَّعة. بتحدد بإيدك إيه اللي بتسحبه وتنشره.
• الموديل المعتمد على المصدر (package): بتشتغل على orgs بتتبّع المصدر، أساسًا scratch orgs وsandboxes متتبَّعة للمصدر. Salesforce DX بيتتبّع التغييرات على الجانبين تلقائيًا، وsf project deploy start أو sf project retrieve start بينقلوا اللي اتغيّر فعلًا بس.

معظم الفرق بيعيشوا في مكان ما بين الاتنين. وده تمام. لكن اتجاه الحركة ناحية تتبّع المصدر وبعيدًا عن الـ change sets اليدوية، وهي نفس النقلة اللي بنفصّلها في ليه كل أداة DevOps في Salesforce بتتجاهل تطوير الحزم.

ليه source format غيّر كل حاجة؟

التطوير المعتمد على المصدر بيشتغل بس بفضل source format. الصيغة القديمة (metadata format) بتحشر custom object كامل، وحقوله، وقواعد التحقق، وقوائم العرض بتاعته في ملف XML طويل واحد. source format بيقسّم ده لملفات صغيرة ومعيارية، واحد لكل مكوّن، تحت هيكل مجلدات هرمي. النتيجة، زي ما Gearset بتوثّق، هي diffs أنضف وتعارضات دمج أقل بكتير: مطوّرين اتنين بيعدّلوا حقول مختلفة على نفس الـ object مبقوش بيتصادموا، لأن تغييراتهم في ملفات منفصلة. source format دلوقتي هو الافتراضي اللي بترشّحه Salesforce للمشاريع الجديدة.

فين لسه التطوير المعتمد على المصدر بيوجع؟

ده الجزء اللي أغلب الشروحات بتتخطاه. source format مش بيقسّم كل حاجة. الـ profiles، وpermission sets، وsharing rules، وworkflows، وexternal services لسه بينزلوا في ملفات كبيرة مشتركة، فاتنين بيعدّلوا نفس الـ profile هيفضلوا يتخانقوا في نظام الإصدارات. وتتبّع المصدر كمان مش بيغطي كل أنواع الميتاداتا؛ لازم تراجع Metadata Coverage Report علشان تعرف إيه اللي متتبَّع فعلًا، والثغرات دي هي اللي بتحرق الفرق.

الـ scratch orgs بتخلي ده أنضف نظريًا، لكن الـ orgs الحقيقية شايلة سنين من الإعدادات اللي عمرها ما كانت في Git. الوصول للتطوير المعتمد على المصدر هجرة، مش زرار بتقلبه، وتكلفة عدم عمل النقلة دي بتظهر مع كل إصدار، وهي بالظبط الحسبة اللي بنعملها في التكلفة الحقيقية لعمليات النشر اليدوية في Salesforce. الأدوات المبنية علشان توفّق الحواف الفوضوية دي، بدل ما تفترض مشروع من الصفر، هي اللي بتفرق بين خط إنتاج شغّال وبين عرض توضيحي.

إزاي تتبنى التطوير المعتمد على المصدر فعليًا؟

1. حطّ الميتاداتا بتاعتك في Git بصيغة source format. اسحب من الـ org الحالي، حوّل لـ source format، واعمل commit. ده خط الأساس الجديد بتاعك.
2. اختار موديل branching بيتطابق مع الـ orgs بتاعتك، علشان كل بيئة تبقى قابلة للبناء من branch.
3. فعّل تتبّع المصدر حيث تقدر، باستخدام sandboxes متتبَّعة وscratch orgs لشغل الميزات.
4. أتمتة النشر من الـ commits، علشان مفيش حاجة توصل للإنتاج إلا من خلال تغيير مُراجَع وبإصدار.
5. خطّط مقدمًا للأنواع غير المقسّمة، وقرّر مين بيمتلك الـ profiles وpermission sets قبل ما تسبب تعارضات.

خط إنتاج بيعامل Git كمصدر للحقيقة، وبيتتبّع التغييرات بدقة، وبيتعامل مع الميتاداتا اللي Salesforce مش بيقسّمها بالكامل، هو بالظبط اللي Serpent اتبنى علشان يشغّله. الحزمة مفتوحة المصدر ممكن توصّلك هناك كمان، وبنديها قراءة صادقة في نظرتنا على sfdx-hardis.

FAQ

هل التطوير المعتمد على المصدر هو نفسه Salesforce DX؟

لأ. Salesforce DX هو الأدوات والصيغة؛ أما التطوير المعتمد على المصدر فهو ممارسة جعل مستودع Git، بدل الـ org، هو مصدر الحقيقة.

هل محتاج scratch orgs للتطوير المعتمد على المصدر؟

لأ. الـ scratch orgs بتساعد، لكن الـ sandboxes المتتبَّعة للمصدر بتدعم تتبّع المصدر كمان، فتقدر تتبنى الموديل من غير سير عمل كامل قائم على scratch orgs.

هل source format بيقضي على تعارضات الدمج؟

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

هل أقدر أخلط التطوير المعتمد على المصدر مع الـ change sets؟

تقدر خلال فترة انتقالية، لكن الهدف هو إنهاء الـ change sets اليدوية علشان كل تغيير يبقى بإصدار ومُراجَع وقابل للتتبّع لـ commit.