كيف تنتقل من change sets إلى التحكم بالمصدر في Salesforce

باختصار: للانتقال من change sets إلى التحكم بالمصدر، ضع ميتاداتا مؤسستك في مستودع Git، وتبنَّ بيئة تطوير مُتتبَّعة المصدر، وانشر عبر خط أنابيب بدل انتقاء المكونات يدويًا. افعل ذلك تدريجيًا: فعّل source tracking، وجرّب فريقًا واحدًا على Git وخط أنابيب للتحقق فقط، ثم تخلّص من change sets نطاقًا تلو الآخر.

توصي Salesforce نفسها الآن العملاء بتجاوز نموذج الإصدار من مؤسسة إلى مؤسسة، ومعظم الأدلة تخبرك لماذا تقصّر change sets. قليل منها يمنحك مسار الانتقال الفعلي. هذا الدليل هو ذلك المسار: كتيّب قابل للتكرار تنفّذه دون تجميد التسليم.

ماذا يعني الانتقال من change sets إلى التحكم بالمصدر؟

يعني نقل مصدر الحقيقة للميتاداتا خارج المؤسسة إلى نظام تحكم بالإصدارات، غالبًا Git. تنسخ change sets المكونات من مؤسسة إلى أخرى ولا تترك تاريخًا. أما التحكم بالمصدر فيخزّن كل layout وflow وpermission set وفئة Apex كملفات مُؤرّخة، فتستطيع التفرّع والمراجعة والنشر والتراجع. تصبح المؤسسة هدف نشر بدل السجل الرئيسي.

لماذا تترك change sets؟

change sets نقطة بداية جيدة وتبقى مفيدة للفرق الصغيرة. لكنها تصطدم بجدار مع نموّك:

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

كيف تنتقل من change sets إلى التحكم بالمصدر؟

نفّذ هذه الخطوات بالترتيب. الهدف خط أنابيب يعمل لنطاق واحد قبل أن توسّع.

1. أنشئ المستودع. جهّز مستودع Git واتفق على نموذج تفرّع يفهمه فريقك.
2. فعّل source tracking في الإنتاج. عندها ترثه sandboxes التطوير الجديدة من نوعَي Developer وDeveloper Pro، وهو ما يتيح الالتقاط الآلي للتغييرات.
3. ثبّت خط أساس. اسحب ميتاداتا مؤسستك الحالية عبر Salesforce CLI والتزم بها كأول لقطة للحقيقة.
4. حوّل إلى صيغة المصدر. استخدم الـ CLI لتقسيم ملفات الميتاداتا الكبيرة إلى ملفات مصدر أصغر قابلة للدمج تقلّل التعارضات.
5. جرّب فريقًا واحدًا. انقل فريقًا أو مشروعًا واحدًا إلى feature branches ونشر للتحقق فقط بينما يواصل الباقون استخدام change sets.
6. أضف التكامل المستمر. اربط خط أنابيب يتحقق من كل pull request وينشر المصدر المدموج إلى البيئة التالية.
7. تخلّص من change sets حسب النطاق. حين يُوثَق أول خط أنابيب، أوقف change sets لهذا النطاق وكرّر للفريق التالي.

change sets مقابل التحكم بالمصدر: ما الذي يتغيّر فعلًا؟

• مصدر الحقيقة: المؤسسة تصبح وجهة للنشر، بينما يحتفظ المستودع بمصدر الحقيقة.
• التقاط التغيير: التأشير اليدوي يصبح source tracking آليًا.
• المراجعة: لا مراجعة تصبح pull requests.
• النشر: النقرات اليدوية تصبح خط أنابيب قابلًا للتكرار.
• الاسترجاع: لا تراجع يصبح تراجعًا وإعادة نشر من التاريخ.

ما الأدوات التي ينبغي استخدامها؟

الأساس المجاني من Salesforce نفسها: Salesforce CLI وSalesforce DX وDevOps Center، الذي يستبدل change sets بواجهة معتمدة على Git ويتكامل مع GitHub وBitbucket. وعندما تحتاج خطوط أنابيب مُدارة، ونسخًا احتياطية، وفروق diff واعية بالميتاداتا، وبوابات جودة، تبني منصات مثل Serpent وCopado وGearset وAutoRABIT وFlosum وSalto وBlue Canvas على أساس Git نفسه. ابدأ مجانًا، ثم تبنَّ منصة حين تكون العملية، لا الأدوات، عنق الزجاجة. ونشرح مسار الترقية هذا تحديدًا في change sets مقابل Serpent. لمزيد من أدلة Salesforce DevOps، اطّلع على أدلة Serpent.

كيف تتجنّب أخطاء الانتقال الشائعة؟

لا تجرّب تحويلًا دفعة واحدة. انتقل بنطاق واحد في كل مرة وأبقِ change sets تعمل بالتوازي حتى يثبت كل خط أنابيب. فعّل source tracking قبل أن تبني لا بعده، وإلا لن تلتقط sandboxes الأولى التغييرات. وثبّت خط أساس للمؤسسة بأكملها قبل أن يبدأ أحد feature branch، ليعكس مستودعك الإنتاج من اليوم الأول بدل أن ينحرف عنه.

FAQ

هل عليّ التوقف عن استخدام change sets فورًا؟

لا. انتقل نطاقًا تلو الآخر وأبقِ change sets للفرق التي لم تنتقل بعد، كي لا يتجمّد التسليم أبدًا.

ما البيئات التي تدعم source tracking؟

تدعمه scratch orgs وsandboxes من نوعَي Developer وDeveloper Pro؛ أما Partial Copy وFull فلا تدعمانه.

هل DevOps Center كافٍ أم أحتاج أداة مدفوعة؟

DevOps Center نقطة بداية مجانية معتمدة على Git. أضف منصة تجارية حين تحتاج خطوط أنابيب مُدارة أو نسخًا احتياطية أو بوابات جودة متقدمة.

كيف أثبّت خط أساس لمؤسسة قائمة؟

اسحب ميتاداتا المؤسسة عبر Salesforce CLI، وحوّلها إلى صيغة المصدر، والتزم بها كأول إصدار في مستودعك.