كيف تحدد حجم تطبيق Salesforce DevOps لفريق من 10 أشخاص

الإجابة المختصرة: حدد حجم تطبيق Salesforce DevOps لفريق من 10 أشخاص بناءً على العمل، وليس على عدد الأفراد. احسب من يغيّر الـ metadata، وكم تغييرًا يجري بالتوازي، وكم مرة تُصدر، ثم خطط لبيئة قصيرة العمر لكل تغيير، وsandbox مشتركة واحدة لـ UAT، وثلاثة مسؤولين بدوام جزئي، وتطبيق على مراحل. معظم الفرق المكونة من 10 أشخاص لا تحتاج إلى تعيين مهندس DevOps متفرغ.

ماذا يعني تحديد حجم تطبيق Salesforce DevOps فعليًا؟

تحديد الحجم يعني أن تقرر كم تحتاج من أربعة أشياء قبل أن تشتري أو تبني أي شيء:

• الوصول: من يحتاج إلى مقعد في الأداة.
• البيئات: كم منظمة (org) يمر بها الـ pipeline.
• الحجم: كم عملية نشر وإصدار في الشهر.
• المسؤولية: من يحافظ على سلامة الـ pipeline.

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

كم شخصًا في فريق من 10 يحتاج إلى وصول؟

عادةً الجميع، ولأسباب مختلفة. الفريق المعتاد من عشرة أشخاص يضم admins ومطورين ومحلل أعمال وشخصًا يختبر أو يعتمد. الـ admins والمطورون يجرون التغييرات، والمحلل يربط العمل بالـ tickets، ومن يعتمدون التغييرات يحتاجون إلى رؤية ما يتجه إلى الإنتاج.

هنا يصبح نموذج التسعير مهمًا. في التسعير لكل مستخدم يصبح كل مقعد قرارًا. على سبيل المثال، تذكر أسعار Gearset المنشورة خطة Teams بسعر $320 لكل مستخدم شهريًا للميزات الأساسية، مع تسعير الأتمتة بشكل منفصل لكل فريق. هذا النموذج يدفعك إلى السؤال عمن يحتاج فعلًا إلى مقعد، ومن يُستبعد ينتهي به الأمر يعمل خارج العملية. التسعير لكل شركة يلغي هذه المفاضلة.

كم بيئة يحتاجها فريق من 10 أشخاص؟

عدد أقل من الـ sandboxes طويلة العمر مما تظن، وعدد أكبر من المنظمات قصيرة العمر.

1. بيئة واحدة لكل تغيير. منظمة scratch أو sandbox للمطور لكل work item، حتى لا تتصادم التغييرات. وتمنح مخصصات منظمات scratch من Salesforce الـ Dev Hub على Enterprise Edition عدد 40 منظمة نشطة و80 منظمة يوميًا، وهذا أكثر من كافٍ لعشرة أشخاص.
2. sandbox مشتركة واحدة للتكامل أو UAT. حيث تلتقي التغييرات ويعتمدها مستخدمو الأعمال. وتكفي Partial Copy لمعظم الفرق.
3. sandbox من نوع Full إذا كان عقدك يتضمنها، لفحوصات الانحدار والأداء النهائية على بيانات قريبة من الإنتاج.
4. الإنتاج. يستقبل عمليات النشر فقط، ولا تعديلات مباشرة أبدًا.

عدد الـ sandboxes المتاحة يعتمد على إصدار Salesforce وعقدك، لذا تأكد منه قبل تصميم الـ pipeline. وبمجرد أن تعمل بأكثر من sandbox طويلة العمر، خطط لكيفية عودة الإصلاحات إلى البيئات الأدنى، كما يشرح دليل إعداد back-promotion في pipeline لـ Salesforce DevOps.

من يجب أن يتولى الـ pipeline في فريق من 10 أشخاص؟

حدد مسؤولين بالاسم بدلًا من تعيين فريق. ثلاثة أدوار بدوام جزئي تكفي:

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

إذا كان شخص واحد فقط يستطيع الإصدار، فهذا الشخص هو إيقاع إصداراتك. ضع شخصين على الأقل خلف كل دور.

ما حجم العمل الذي يجب أن تخطط له في الـ pipeline؟

قدّره من الـ backlog لديك، وليس من مستوى يحدده المورد. مثال عملي لفريق من عشرة:

• 40 ticket شهريًا، كل منها يُنشر مرة واحدة إلى بيئته الخاصة: 40 عملية نشر.
• إصدارات أسبوعية إلى الإنتاج: حوالي 4 إصدارات.
• مراجعة بالذكاء الاصطناعي على كل تغيير.

حوّل ذلك إلى ما تقيسه أداتك. في نموذج الأرصدة لدى Serpent، نشر الميزة يكلف رصيدًا واحدًا، والإصدار إلى الإنتاج رصيدين، وإجراء الذكاء الاصطناعي يضيف رصيدًا واحدًا، فيصل هذا المثال إلى حوالي 90 رصيدًا شهريًا: أكثر من الـ 30 المتضمنة في خطة Essentials المجانية، وأقل بكثير من الـ 300 في خطة Scale. احسب أرقامك بنفسك على صفحة الأسعار قبل أن تلتزم.

كيف يبدو التطبيق على مراحل؟

1. خط الأساس. سجّل كم يستغرق التغيير من الاعتماد حتى الإطلاق، وكم مشكلة تصل إلى الإنتاج.
2. الربط والتجربة. ضع الإنتاج وsandbox واحدة تحت إدارة الإصدارات، ومرّر اثنين أو ثلاثة tickets حقيقية مع مجموعة صغيرة.
3. أضف البوابات. فعّل الاختبارات الآلية والتحليل الثابت والمراجعة لكل تغيير. وتصلح الركائز الخمس لـ Salesforce DevOps كقائمة تحقق لما يجب أن تغطيه هذه البوابات.
4. أدخل الجميع. انقل بقية الـ admins والمطورين، وتوقف عن استخدام change sets لكل ما يتولاه الـ pipeline الآن.
5. قِس وعدّل. قارن بخط الأساس بعد بضع دورات إصدار قبل إضافة بيئات أو أدوات.

ما الأداة المناسبة لفريق من 10 أشخاص؟

حدد الحجم أولًا، ثم أعد القائمة المختصرة. يمكن تثبيت DevOps Center الخاص بـ Salesforce دون تكلفة إضافية في منظمات Professional (مع وصول API) وEnterprise وUnlimited Edition. وتناسب كل من Gearset وCopado وAutoRABIT وFlosum وBlue Canvas وSalto أشكالًا مختلفة من الفرق والميزانيات، ومقارنتنا لـ أفضل أدوات Salesforce DevOps لعام 2026 تستعرضها منصة تلو الأخرى. قيّم كل خيار وفق أسئلة الحجم الأربعة: من يستطيع استخدامه، وكيف يتعامل مع البيئات، وكم يكلف الحجم، وكم مسؤولية يتطلب.

FAQ

هل يحتاج فريق Salesforce من 10 أشخاص إلى مهندس DevOps متفرغ؟

عادةً لا. مسؤولون محددون بدوام جزئي للإصدار والمراجعة وسلامة الـ pipeline يغطون معظم الفرق بهذا الحجم.

كم sandbox يحتاجها فريق من 10 أشخاص؟

عادةً sandbox مشتركة واحدة للتكامل أو UAT، بالإضافة إلى منظمة قصيرة العمر لكل تغيير، وsandbox من نوع Full للانحدار النهائي إذا كان عقدك يتضمنها.

كم يجب أن يستغرق التطبيق؟

وقتًا كافيًا لتشغيل تجربة وبضع دورات إصدار قبل التوسع. نفّذه على مراحل بدلًا من نقل الجميع دفعة واحدة.

هل يجب أن يكون الـ admins جزءًا من التطبيق؟

نعم. الـ admins يجرون كثيرًا من التغييرات في معظم فرق Salesforce، والـ pipeline الذي لا يستطيعون استخدامه يترك هذا العمل خارجه.

تسعّر Serpent لكل شركة مع عدد غير محدود من المستخدمين، لذلك يستطيع الأشخاص العشرة جميعًا العمل في الـ pipeline من اليوم الأول. ابدأ مجانًا مع Essentials، وانتقل إلى Scale عندما يزيد حجم العمل، واعثر على مزيد من الأدلة خطوة بخطوة في مكتبة SF Guides.