مسرد Salesforce DevOps

Change Set

الطريقة الأصلية في Salesforce، القائمة على النقر والاختيار، لنقل البيانات الوصفية (metadata) بين المؤسسات المتصلة، رفعة يدوية واحدة في كل مرة.

التعريف

الـ change set هي طريقة Salesforce الأصلية القائمة على النقر والاختيار لنقل تغييرات الإعداد، الحقول، الكائنات، الـ flows، وتخطيطات الصفحات، بين مؤسستين مرتبطتين عبر deployment connection ضمن نفس التسلسل الهرمي للإنتاج، مثل الانتقال من sandbox إلى الإنتاج. يمكن تضمين أنواع البيانات الوصفية التي تدعمها change sets فقط، ويمكن لفئات Apex التي لا تملك تغطية اختبار كافية أن توقف نشر المجموعة بأكملها.

كل خطوة يدوية: يفتح المسؤول Setup، ويبني change set صادرة مكونًا تلو الآخر، ويرفعها، ثم يتحقق منها مسؤول في المؤسسة الهدف وينشرها. لا توجد جدولة مدمجة ولا حل تلقائي للاعتماديات يتجاوز تحقق Salesforce نفسه، لذا يظهر المكون المفقود عادةً كخطأ في النشر بدلاً من أن يُدرج تلقائيًا.

لا تملك change sets أيضًا آلية rollback؛ التراجع عن نشر سيئ يعني بناء ونشر change set ثانية يدويًا. هذا قابل للتطبيق مع إصدارات صغيرة وغير متكررة على قائمة مؤسسات مستقرة، لكنه ينهار بسرعة بمجرد أن تضيف الفرق بيئات أكثر أو تُصدر بوتيرة أعلى. الفرق التي تحتاج إلى إبقاء كل شيء داخل Salesforce تنظر غالبًا أولاً في الأدوات الأصلية، وهو ما تزنه مقارنة Serpent وFlosum. راجع دليل Salesforce DevOps لدينا لمعرفة كيف تتخطاه الفرق عادةً.

من واقع الاستخدام

إزاي بيشتغل في Serpent

يستبدل Serpent خطوة بناء change set اليدوية بسير عمل قائم على المهام: اختر المكونات التي لمستها مهمة ما، ويتتبعها Serpent تلقائيًا باستخدام source tracking بدلاً من بيان (manifest) مبني يدويًا. تمر عمليات النشر عبر خط أنابيب مجدول وقابل للتدقيق مع ترتيب الاعتماديات، بحيث تصل التغييرات دائمًا بنفس التسلسل عبر sandboxes وstaging والإنتاج. يحتفظ كل إصدار بسجل كامل: ماذا نُشر، ومتى، ومن قِبل من، مع rollback بنقرة واحدة إذا حدث خلل. ولأن Serpent يتواصل مع المؤسسات عبر واجهات Salesforce القياسية، فإنه يتوسع بسهولة إلى ما بعد حد المؤسستين أو الثلاث حيث تصبح change sets مؤلمة، دون أن يطلب من الفرق تعلّم Git أولاً. راجع مقارنة change sets مقابل Serpent الكاملة للاطلاع على المقارنة جنبًا إلى جنب.

قائمة إصدارات Serpent مع مسار حالة يتتبع عمليات نشر change set عبر الـ orgs
أسئلة شائعة

Change Set، تمت الإجابة

هل يمكنني الاستمرار في استخدام change sets إلى جانب Serpent؟
نعم، لكن معظم الفرق تنقل تتبع المكونات إلى مهام Serpent بمجرد أن يتجاوز عدد المؤسسات اثنتين أو ثلاثًا، لأن change sets تصبح عرضة للأخطاء مع زيادة الحجم.
لماذا تفشل عمليات نشر change set حتى عندما يبدو كل شيء صحيحًا في Setup؟
غالبًا بسبب اعتمادية مفقودة، مثل حقل صيغة يشير إلى حقل مخصص لم يُضَف إلى المجموعة، أو تغطية اختبار Apex أقل من الحد الذي تفرضه Salesforce. لا تحل change sets الاعتماديات تلقائيًا، لذا لا يظهر الإغفال إلا كخطأ تحقق.
كم عدد المؤسسات التي يمكنني إدارتها فعليًا باستخدام change sets؟
تعمل change sets بشكل جيد مع مؤسستين أو ثلاث في تسلسل هرمي مستقر، لكن كل بيئة إضافية تضاعف خطوات الرفع والتحقق اليدوية، وهذا سبب انتقال معظم الفرق إلى خطوط أنابيب آلية بمجرد إضافة مؤسسة staging أو UAT.

ابدأ مجانًا. بلا بطاقة ائتمان، بلا تثبيت، بلا التزام.

الإعداد في أقل من 15 دقيقة. لا حاجة لتوظيف DevOps.

هل تريد معرفة كيف يمكنكم الشحن أسرع قبل البدء؟ لنتحدث

بدون التزام.