إزاي تنتقل من الـ change sets للتحكم في المصدر (خطوة بخطوة)

باختصار: عشان تنتقل من الـ change sets للتحكم في المصدر، اسحب ميتاداتا مؤسستك في مشروع Salesforce DX، اعمله commit في مستودع Git كمصدر وحيد للحقيقة، اتبنّى نموذج فرع-لكل-بيئة، وانشر عبر pipeline آلية بدل ما تدوس change sets من org لـ org. اعملها بالتدريج: ابدأ بمشروع واحد، أثبت سير العمل، وبعدين انقل الباقي.

ليه أصلاً ننتقل من الـ change sets للتحكم في المصدر؟

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

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

إمتى يبقى وقت التحويل؟

فكّر في الانتقال بمجرد ما أي واحدة من دول تبقى صح:

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

لو اتنين أو أكتر بيتحققوا، فالـ change sets بتكلّفك بالفعل أكتر مما بتوفّر.

إزاي تنتقل من الـ change sets للتحكم في المصدر خطوة بخطوة؟

1. حوّل ميتاداتاك لصيغة مصدر. استخدم Salesforce CLI عشان تسحب الميتاداتا في مشروع Salesforce DX (SFDX)، بحيث مؤسستك تتوصف كملفات بدل لقطة change-set.
2. اعمل مستودع Git. اعمل commit للمشروع ده كخط أساس - أول مصدر وحيد للحقيقة للمؤسسة.
3. اختار نموذج تفريع. الأبسط هو فرع طويل العمر لكل بيئة (مثلاً dev، uat، main)، مع فروع ميزات بتتدمج عبر pull requests.
4. أتمِت النشر. جهّز pipeline بتنشر من كل فرع لبيئته عند الدمج، وبتشغّل التحقق والاختبارات آلياً بدل رفع change-set يدوي.
5. ضيف اختبارات وفحوصات. اشترط نجاح اختبارات Apex ومراجعة الكود والتحقق قبل ما الدمج يوصل للإنتاج.
6. أوقف الـ change sets. سيبها كخيار طوارئ بس بعد ما الـ pipeline تبقى موثوقة.

مش لازم تعملها دفعة واحدة. ابدأ بمشروع أو فريق واحد، أثبت سير العمل، وبعدين انقل باقي المؤسسة.

محتاج أنهي أدوات عشان تعمل النقلة؟

الحد الأدنى: مضيف Git (GitHub أو GitLab أو Bitbucket)، وSalesforce CLI، ومشروع Salesforce DX. الـ DevOps Center المجاني من Salesforce بيضيف تحكم في المصدر وعناصر عمل وتتبّع للتغييرات عبر واجهة بالنقر، وده خطوة أولى قوية للفرق منخفضة الكود. الفرق النامية عادةً بتنتقل لمنصة مخصصة بتجمع التحكم في المصدر والاختبارات الآلية والتراجع عشان الأدمنز ميعيشوش في الـ CLI. شوف إزاي القطع بتتركّب مع بعض في مكتبة أدلة SF بتاعتنا.

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

إزاي تتجنب أخطاء الترحيل الشائعة؟

• ماتسحبش كل حاجة مرة واحدة. ابدأ بالميتاداتا اللي فريقك بيغيّرها بنشاط، وبعدين وسّع.
• خلي بالك من الـ profiles والـ permission sets. دي أصعب ميتاداتا في التحكم النظيف بالإصدارات، فخطّطلها بعناية.
• ماتشغّلش change sets وGit بالتوازي على المدى الطويل. مصدرين للحقيقة بيهدموا الهدف.
• خُد الأدمنز معاك. النقلة بتفشل بسبب الثقافة أكتر من الأدوات.

لما تبقى جاهز تنتقل من غير العبء اليدوي، دليل الترحيل بتاعنا بيمشي معاك الطريق كله.

الأسئلة الشائعة

أقدر أنتقل من الـ change sets لـ Git من غير ما أكتب كود؟

لحد كبير أيوه. الـ DevOps Center والمنصات الخارجية بتوفّر تحكم في المصدر بالنقر، مع إن حد لسه بيشغّل السحب الأولي بالـ CLI عشان يملأ المستودع.

يعني إيه مشروع Salesforce DX؟

هو تمثيل بصيغة المصدر لميتاداتا مؤسستك كملفات ومجلدات، بيتسحب بالـ Salesforce CLI، وGit بعدها بيتتبعه ويعمله إصدارات.

هل الـ DevOps Center بديل كامل للـ change sets؟

لكتير من الفرق، أيوه. بيضيف تحكم في الإصدار وتتبّع للتغييرات فوق Git، لكن الفرق الأكبر غالباً بتحتاج الاختبارات الآلية والتراجع اللي المنصات المخصصة بتقدّمها.

الترحيل بياخد قد إيه؟

مشروع واحد ممكن ينتقل في أيام. مؤسسة كاملة بفرق متعددة عادةً طرح مرحلي على مدى أسابيع، بيئة ورا بيئة.