دروس Salesforce DevOps من Web Summit لشبونة 2025

لم يكن Web Summit لشبونة 2025 فعالية خاصة بـ Salesforce، لكن Salesforce ظهرت في كل حوار جاد تقريبًا خضته مع مؤسسين ومسؤولي RevOps يديرون أعمالهم على المنصة. النمط كان ثابتًا: الفرق ما زالت تنشر الميتاداتا يدويًا، وما زالت تخشى إصدار يوم الجمعة، وما زال ليس لديها خطة تراجع حقيقية. هذه بالضبط الفجوة التي بُني Serpent لسدها.

لم أكن هناك لأكرر جملة جناح تسويقي. تحدثت مع أشخاص بين الجلسات، وفي صالة المستثمرين، وفي Night Summit، وكان DevOps الخاص بـ Salesforce يظهر باستمرار كمشكلة لم يحلها أحد بشكل نظيف.

لماذا ظهرت إدارة إصدارات Salesforce في مؤتمر تقني عام؟

يغطي Web Summit نطاقًا واسعًا: شركات ناشئة، مستثمرين، تكنولوجيا مالية، ذكاء اصطناعي. لكن عددًا مفاجئًا ممن التقيت بهم كانوا يديرون شركات في مرحلة نمو على Salesforce، إما كنظام CRM الأساسي لديهم أو كعمود فقري لمنتج شريك ISV. بمجرد أن يتجاوز الحديث سؤال "ماذا تبنون"، كان ألم الإصدار يظهر في كل مرة تقريبًا، غالبًا من تلقاء نفسه.

الخيط المشترك كان أن مسؤولي ومطوري Salesforce تجاوزوا الـ change sets منذ سنوات، لكنهم ما زالوا يجمعون بين sandboxes وجداول بيانات ومحادثات Slack لتنسيق إصدار. لم يصف أحد تحدثت معه عملية النشر لديه بأنها شيء يثق فيه.

ما ألم النشر الذي وصفه المؤسسون والفرق؟

تكررت بضع شكاوى محددة عبر شركات لا صلة بينها:

• لا توجد طريقة موثوقة لمعرفة ما يختلف فعليًا بين sandbox والإنتاج قبل النشر.
• تعارضات دمج في الميتاداتا لا تظهر إلا بعد فشل النشر، لا قبله.
• تحديثات يدوية للبروفايلات ومجموعات الصلاحيات تُنسى بين البيئات.
• نوافذ إصدار تعتمد على توفر شخص واحد، لأنه الوحيد الذي يفهم ترتيب النشر.
• عمليات تراجع تعني استعادة نسخة احتياطية بدلًا من التراجع عن تغيير واحد.

لا شيء من هذا غريب. إنها نفس القائمة القصيرة من المشاكل التي تعمل أدوات DevOps الخاصة بـ Salesforce على معالجتها منذ عقد. ما لفت الانتباه هو كم عدد الفرق، بعضها بعد جولة استثمارية Series A بوقت طويل، التي ما زالت تحل هذا بالانضباط والمعرفة المتوارثة بدلًا من منصة.

كيف يؤكد هذا اتجاه Serpent؟

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

ما غيّر رأيي قليلًا هو كم عدد هذه الفرق التي لم تكن شركات Salesforce فقط. كانت تقارن انضباط إصدار Salesforce بـ CI/CD الذي تديره بالفعل لمكدسها على الويب، وتجد أن Salesforce متأخرة بشدة. هذا إطار مفيد عندما تُري شخصًا ما يفعله Serpent فعليًا، لأنك لا تشرح DevOps من الصفر، بل تشرح لماذا تأخرت Salesforce.

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

ما الذي يجب أن تأخذه معك إذا كنت تقيّم أداة DevOps لـ Salesforce؟

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

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

أسئلة شائعة

لماذا يهم DevOps الخاص بـ Salesforce خارج فعاليات Salesforce تحديدًا؟

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

ما أكثر خطأ نشر Salesforce شيوعًا وصفه المؤسسون؟

الاعتماد على المعرفة المتوارثة لشخص واحد بترتيب النشر بدلًا من خط نشر قابل للتكرار وخاضع للتحكم بالإصدارات.

هل تختلف إدارة إصدارات Salesforce عن CI/CD العام؟

المبادئ نفسها، لكن اعتماديات ميتاداتا Salesforce والإعدادات الخاصة بكل مؤسسة تجعل أدوات CI/CD العامة غير مناسبة بدون أدوات مدركة لطبيعة Salesforce.

كيف يختلف Serpent عن الـ change sets اليدوية؟

يستبدل Serpent التجميع اليدوي للـ change sets بمقارنة تلقائية وكشف تعارضات وخط نشر مبني خصيصًا لميتاداتا Salesforce.