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

التعريف الأول: التطوير المدفوع بالمصدر هو النموذج اللي بيبقى فيه مستودع Git بتاعك، مش أي org، هو مصدر الحقيقة لإعدادات Salesforce وكودها. الـ orgs بتتحوّل لبيئات قابلة للاستبدال بتنشر لها من المستودع، بدل ما تكون أماكن بتنقل بينها التغييرات. كل حاجة تانية في الدليل ده متفرّعة من الجملة دي.

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

في النموذج ده، كل تغيير بينزل في التحكم بالإصدارات الأول وبيوصل للـ org تاني. المستودع بيمثّل الحالة المقصودة للـ org، والنشر هو فعل مطابقة الـ org للنية دي.

وبيجي معاه ثلاث خصائص عملية:

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

إيه الفرق بينه وبين النشر من org لـ org؟

النشر من org لـ org، سواء بحزم التغيير أو بمقارنة مباشرة بين org واتنين، بياخد org حية كمرجع. ده الفرق الحقيقي، وله نتايج.

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

خد بالك من اللي مش في القائمة: السرعة. النموذج ده مش أسرع تلقائيًا، لكنه قابل للتكرار، وهي خاصية مختلفة وأطول عمرًا.

إيه هو تتبّع المصدر وفين بيشتغل؟

تتبّع المصدر هو خاصية المنصة اللي بتسجّل أي المكوّنات اتغيّرت في الـ org أو في مشروعك المحلي من آخر مزامنة، علشان تسحب اللي اتحرّك فعلًا بدل ما تسحب كل حاجة وتقعد تقرأ الفروق.

الحد اللي بيقابل الناس هو التغطية. تتبّع المصدر متاح في الـ scratch orgs وفي صناديق Developer و Developer Pro، ومش متاح في كل مكان. يعني النموذج المدفوع بالمصدر لازم يجاوب عن البيئات اللي مش قادرة تتبّع التغييرات: الصناديق الكاملة والنسخ الجزئية والإنتاج. ودي بالظبط الـ orgs اللي بتحصل فيها تغييرات غير موثّقة.

Source format ولا metadata format: تعمل كوميت لأنهي واحد؟

اعمل كوميت للـ source format. الصيغتين بيوصفوا نفس البيانات الوصفية بشكل مختلف:

• صيغة الـ metadata هي شكل الـ Metadata API: ملفات عريضة لكل كائن مع ملف package.xml. تعديل حقل واحد بيعيد كتابة ملف كبير، فالفروق بتشيل الكائن كله والمراجعة بتبقى مزعجة.
• صيغة الـ source بتفكّك البنية دي: كل حقل وقاعدة تحقق وعرض قائمة بياخد ملف لوحده في شجرة مجلدات، ومجلدات الحزم معرّفة في sfdx-project.json.

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

لكن source format مش بيقسّم كل حاجة. الـ profiles وpermission sets وsharing rules لسه بينزلوا في ملفات كبيرة مشتركة، فاتنين بيعدّلوا نفس الـ profile ممكن يتعارضوا برضه. حدّد مين المسؤول عن الملفات دي قبل ما تبدأ الانتقال. وتتبّع المصدر كمان مش بيغطي كل أنواع الميتاداتا: راجع Metadata Coverage Report قبل ما تفترض إن نوع معيّن متتبَّع.

يحصل إيه لما الـ org والمستودع يختلفوا؟

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

احسم الثلاث نقط دول قبل الترحيل مش بعده:

1. مين يكسب. المستودع يكسب كسياسة. يعني التغيير اللي حصل بره المسار مش "ضايع"، لكنه بيتصالح: يتسحب، ويتعمله كوميت بشرح، وبعدين يترجع نشره من الفرع.
2. إزاي تعرف. شغّل كشف الانحراف ضد الإنتاج بجدول منتظم. اكتشاف الاختلاف وقت الإصدار هو اكتشاف متأخر.
3. إيه اللي بره النطاق عمدًا. في بيانات وصفية فعلًا خاصة بالبيئة أو مملوكة لحزمة مثبّتة. اكتب قائمة الاستثناءات دي. قائمة استثناءات صادقة أحسن من مستودع الكل بيشك فيه في السر.

إزاي تتبنّى ده وفريقك مش متمكّن من Git؟

أغلب فرق Salesforce أدمنز واستشاريين، مش مستخدمي سطر أوامر، وهنا بالظبط بتتعطّل الترحيلات. رتّب الخطوات بحيث محدش يحتاج يتعلم Git علشان يكمّل شغله:

1. ابدأ بحدود حزمة واحدة. فريق واحد ومجموعة بيانات وصفية واحدة. ما تحاولش تعمل كوميت للـ org كلها في أول أسبوع.
2. اسحب بصيغة الـ source واوصل لنشر نظيف للنطاق ده على صندوق اختبار قبل ما حد يغيّر عاداته.
3. حط بوابة قدام الإنتاج. حتى موافقة يدوية على فرع بتتحسب. الحقيقة من غير بوابة بترجع تنحرف خلال شهر.
4. خلّي الواجهة اليومية مألوفة. الأدمنز يفضلوا يشتغلوا في تذكرة أو عنصر عمل، والكوميت والفرع والدمج يحصلوا تحتيهم.
5. ضيف كشف الانحراف في الآخر. أول ما خط الأنابيب ياخد ثقة، هو اللي هيقولك النموذج بيسرّب منين.

لسه شغال بالـ change sets؟ ابدأ بدليل إزاي تنتقل من change sets للتحكم في المصدر، وبعدها أتمت التسليم عن طريق خط CI/CD لـ Salesforce على GitHub Actions. أو خلّينا ننفّذ الانتقال معاك.

FAQ

هل كل أدمن لازم يتعلم Git؟

لأ. المطلوب إن المستودع يبقى المرجع. مين بيتعامل مع Git مباشرةً ده اختيار أدوات، مش خاصية في النموذج.

هل لازم أحوّل الـ org كلها لصيغة المصدر مرة واحدة؟

لأ. حوّل بحدود الحزم أو بالفرق. مستودع جزئي مرجعي فعلًا في نطاقه أحسن من مستودع كامل محدش واثق فيه.

هل ده نفس الـ CI/CD؟

لأ. التطوير المدفوع بالمصدر بيقرر مكان الحقيقة، والـ CI/CD بيأتمت نقلها للـ orgs. ممكن يبقى عندك الأول من غير التاني، والعكس نادرًا ما يكون مفيدًا.

وإيه موقف البيانات الوصفية اللي مش بتتحط في التحكم بالإصدارات؟

في إعدادات ومكوّنات مملوكة لحزم مش بترجع نظيفة. وثّقها كمستثناة وسيطر عليها بإجراء، بدل ما تدّعي إن المستودع مغطيها.

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

لأ. Salesforce DX هو الأدوات وصيغة الملفات، أما التطوير المدفوع بالمصدر فهو ممارسة إنك تخلي المستودع، مش الـ org، هو مصدر الحقيقة.

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

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

‏Serpent متبني بالظبط للفريق اللي الدليل ده بيوصفه: المستودع يفضل مصدر الحقيقة والأدمنز والاستشاريين شغالين في تذاكر، وفوقه نشر بالفروقات وكشف انحراف وتراجع بضغطة واحدة. في أدلة مرجعية أكتر في SF Guides.