دليل DevOps الخاص بـ Salesforce لفرق الشركات المتوسطة النامية

مشكلة DevOps للشركات المتوسطة

مؤسسة Salesforce لديك معقدة جدًا بالنسبة للـ change sets، لكن ليس لديك الميزانية أو عدد الموظفين لأدوات DevOps بمستوى المؤسسات الكبرى. لديك 3-20 مطور Salesforce، وعدة sandboxes، ودورات إصدار يزداد صعوبة إدارتها مع نمو الفريق.

هذه مشكلة DevOps للشركات المتوسطة. هنا تعلق معظم فرق Salesforce النامية.

يغطي هذا الدليل ما يعمل فعليًا لفرق بهذا الحجم - بناءً على أنماط من عشرات تطبيقات Salesforce في الشركات المتوسطة.

استراتيجية المؤسسة الصحيحة لحجم فريقك

3-8 مطورين

عند هذا الحجم، البساطة هي صديقك. لست بحاجة إلى 6 بيئات.

• sandbox التطوير - كل مطور يعمل في sandbox خاص به، أو sandbox تطوير مشترك إذا كانت حدود المؤسسة ضيقة
• sandbox الجودة - للاختبار قبل الإنتاج
• الإنتاج

مسار النشر: التطوير ← الجودة ← الإنتاج، مؤتمت عبر خط نشر.

8-20 مطورًا

عند هذا الحجم، تحتاج إلى عزل الميزات لتجنب تعطيل المطورين لبعضهم البعض.

• sandboxes الميزات (واحد لكل epic نشط أو زوج مطورين)
• sandbox التكامل - يدمج من كل sandboxes الميزات
• sandbox UAT - لاعتماد الأعمال
• الإنتاج

sandbox التكامل هو الإضافة الأساسية - هنا تظهر تعارضات الدمج قبل أن تصل إلى الإنتاج.

وتيرة الإصدار: ما يعمل فعليًا

الفرق التي تشحن بوتيرة ثابتة تشحن بموثوقية أعلى من الفرق التي تشحن "عندما تكون جاهزة". الوتيرة تفرض ترتيب الأولويات وتمنع تراكم المخاطر التي تسبب أعطال الإنتاج.

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

توصية لفرق 5-15 مطورًا: إصدارات كل أسبوعين في يوم ثابت (مثل كل أربعاء ثانٍ). أعِدّ خط النشر مرة واحدة، وشغّله في كل دورة.

الأدوار التي يجب أن توجد (حتى في الفرق الصغيرة)

لست بحاجة إلى مهندسي DevOps بدوام كامل. أنت بحاجة إلى ملكية واضحة.

• منسّق الإصدار - يمتلك تقويم الإصدار وقرارات المتابعة أو الإيقاف. يمكن أن يكون مطورًا كبيرًا أو قائدًا تقنيًا. 2-3 ساعات لكل دورة إصدار.
• مراجع النشر - يراجع ما يدخل في كل نشر، ويتحقق من تغطية الاختبارات. يجب أن يكون شخصًا مختلفًا عن من كتب الكود.
• مالك التراجع - يعرف كيفية التراجع عن كل تغيير في الإصدار. مع Serpent، هذا ضغطة واحدة - لكن يجب أن يمتلك أحدهم قرار استخدامها.

المقاييس التي تخبرك أن DevOps لديك يعمل

• تكرار النشر: كم مرة تنشر بنجاح إلى الإنتاج؟ الهدف: مرة واحدة على الأقل لكل دورة.
• مهلة التغييرات: من أول commit إلى الإنتاج. الهدف: أقل من أسبوعين للتغييرات القياسية.
• معدل فشل التغييرات: نسبة عمليات النشر التي تسبب حادثة إنتاج. الهدف: أقل من 5%.
• متوسط وقت الاستعادة: المدة من عطل الإنتاج إلى نشر الإصلاح. الهدف: أقل من 4 ساعات.

هذه هي مقاييس DORA الأربعة. قسها شهريًا. إذا كان تكرار النشر ينخفض أو معدل الفشل يرتفع، فعمليتك بها عنق زجاجة يجب إصلاحه قبل أن يزداد سوءًا.

أخطاء شائعة بهذا الحجم من الفرق

• تخطي UAT في التغييرات "الصغيرة". أعطال الإنتاج تأتي غالبًا من تغييرات بدت صغيرة جدًا لدرجة أنها لا تحتاج UAT.
• ترك sandbox التكامل يصبح قديمًا. إذا تأخر أكثر من أسبوعين عن الإنتاج، فلم يعد مفيدًا. حدّثه وفق جدول ثابت.
• التعامل مع الإصدارات كبطولات فردية. إذا كان كل إصدار يتطلب بقاء شخص متأخرًا، فعمليتك هي المعطلة، لا فريقك.
• عدم توثيق محتوى كل إصدار. ملاحظات الإصدار لا تحتاج أن تكون رسمية - رسالة Slack بخمس نقاط كافية. افعل ذلك في كل مرة.

أسئلة شائعة

كم sandbox يحتاجه فريق Salesforce في شركة متوسطة؟

مع 3 إلى 8 مطورين، يكفي sandbox تطوير وsandbox جودة وإنتاج. بعد 8 مطورين، أضف sandboxes للميزات، وsandbox تكامل تظهر فيه تعارضات الدمج، وsandbox UAT لاعتماد الأعمال.

ما وتيرة الإصدار الأنسب لفريق Salesforce نامٍ؟

الوتيرة الثابتة أفضل من الشحن "عندما يكون جاهزًا"، لأنها تفرض ترتيب الأولويات وتوقف تراكم المخاطر. كل أسبوعين في يوم ثابت يناسب معظم الفرق بهذا الحجم، والأسبوعي يناسب التطوير النشط جدًا، والشهري يعمل فقط إذا كانت المؤسسة مستقرة.

هل تحتاج مهندس DevOps مخصصًا لـ Salesforce؟

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

ما المقاييس التي تُظهر أن DevOps الخاص بـ Salesforce لديك يعمل؟

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

اتخاذ قرار الأدوات

في شركة بحجم 50-200 موظف مع 5-20 مطور Salesforce، تحتاج إلى أداة:

• سريعة الإعداد - لا يمكنك قضاء 6 أشهر في التطبيق
• غير مسعّرة لكل مستخدم - فريقك ينمو ولا تريد مفاجآت في التكلفة
• منظمة بما يكفي للتعامل مع sandboxes الخاصة بك - وليست لوحة فارغة تجبرك على بناء خط النشر من الصفر

Serpent مبني خصيصًا لهذا الحجم من الفرق. اطّلع على الأسعار أو جرّبه مجانًا.