DevOps في سيلزفورس مش للمطورين بس

الفكرة في تلات جمل: معظم التغييرات في سيلزفورس مش بيعملها المطورين، لكن بيعملها الأدمن والاستشاريين اللي عمرهم ما فتحوا terminal. تحليل استطلاعات 2026 من Salesforce Ben بيحط الـ change sets عند 41.8% كأشهر طريقة نشر عند الأدمن، مقابل 2.6% بس لـ DevOps Center. يعني أي أداة DevOps أول شاشة فيها بتفترض إتقان Git تكون بهدوء استبعدت أغلب الناس اللي بتشحن على المنصة دي.

مين اللي بينشر تغييرات سيلزفورس فعلاً دلوقتي؟

التوزيع حسب الدور واضح جداً. حسب تحليل Salesforce Ben لاستطلاعات المطورين والمعماريين والأدمن لسنة 2026:

• الأدمن: change sets بنسبة 41.8%، ومزوّدو DevOps الخارجيون 29.9%، وDevOps Center 2.6%، و9.3% مش متأكدين أو مفوّضين النشر لحد تاني بالكامل.
• المطورون: خطوط CI مفتوحة المصدر 37.8%، ومزوّدون خارجيون 30.8%، وchange sets 19.4%.
• المعماريون: مزوّدون خارجيون 38.2%، وخطوط مفتوحة المصدر 34.8%، وchange sets 18.9%.

اقرا الأرقام دي تاني من ناحية الأدوات. المطورون والمعماريون ساب معظمهم الـ change sets. الأدمن لأ، وهما أكبر مجموعة بتعمل تغييرات. الفرق مش في الرغبة، لكن في إن الأدوات اللي اتبنت للمجموعتين الأولانيين ما كانتش قابلة للاستخدام من التالتة.

ليه "DevOps للمطورين" بيستبعد سوقه نفسه؟

لأن قاعدة عملاء سيلزفورس شكلها مش شكل شركة برمجيات. الفريق النموذجي أدمن اتنين، واستشاري بعقد شهري، ومفيش مهندس DevOps خالص. ولما المسار الطبيعي لأداة يبدأ بأنك تعمل clone لمستودع، وتختار استراتيجية فروع، وتحل تعارض دمج جوه عارض فروقات، فالترجمة الصريحة تبقى: وظّف حد تاني الأول.

وعشان كده رقم الـ change sets رافض ينزل. مش لأن الأدمن بيفضّلوا أداة من غير سجل ومن غير تراجع ومن غير طريقة لنقل الميتاداتا بين مؤسسات غير مرتبطة، لكن لأن الـ change sets هي الخيار الوحيد اللي ما طلبش منهم يتحولوا لمطورين في الطريق.

والنسخة الصريحة: منتج DevOps بيطلب إتقان Git مش منتج DevOps لسيلزفورس، ده أداة مطورين بتصادف إنها بتنشر ميتاداتا سيلزفورس.

أداة مبنية للأغلبية شكلها إيه؟

مش أداة مطورين مبسّطة، لكن مدخل مختلف على نفس المحرك. أربع اختبارات تصميم بتفرق بين الاتنين:

1. وحدة الشغل هي التذكرة مش الفرع. الأدمن بيفكر بـ"تغيير تصعيد الحالات"، مش بفروع الميزات. لو أول كلمة على الشاشة هي فرع، فالمنتج لسه متفصّل على المطورين.
2. تتبّع النسخ نتيجة مش شرط مسبق. اختيار المكوّنات المفروض يولّد commit، ومفيش حد المفروض يكتبه بإيده.
3. المراجعة على التغيير مش على صيغة الفروقات. المراجع لازم يشوف المكوّنات اللي اتحركت وإيه اللي رفعته الفحوص الآلية، من غير ما يقرا XML ميتاداتا خام.
4. التراجع موجود وبحركة واحدة. الرجوع للخلف هو القدرة الوحيدة اللي الـ change sets ما امتلكتهاش أبداً، وهي اللي بتحوّل أدمن متوتر لمسؤول إصدار واثق.

وGit بيفضل هو اللي شغال تحت النقط الأربعة، بس بيبطل يبقى الواجهة: المطورون بيحتفظوا بالمستودع والفروع والـ CLI، والأدمن بيشتغل من واجهة على نفس السجل.

هل سيلزفورس بتصلّح ده بنفسها؟

بتتحرك في الاتجاه ده فعلاً، وده أقوى دليل إن إعادة التأطير حقيقية. الجيل الجديد من DevOps Center بقى أصلياً في المنصة بدل ما يكون حزمة مُدارة، وبتفعّله من Setup، ومبني حوالين work items وخطوط أنابيب مرئية وترقية لكل عنصر على حدة وDX Inspector بيتتبّع تغييرات المؤسسة، مع إدارة وكيلة لخط النشر عبر خادم DX MCP (Salesforce Ben).

نقل سيلزفورس لـ DevOps جوه المنصة الأساسية إشارة على مستوى الفئة كلها: صاحب المنصة بقى موافق إن إدارة الإصدارات شغل الفريق كله. وده كمان بيرفع السقف على الجميع، فلو تميّزك كان "أسهل من سطر الأوامر"، الخيار الأصلي المجاني جاي على الناحية دي.

ده معناه إيه لو أنت المعماري أو مسؤول الإصدارات؟

أنت الشخص اللي بيرث نتايج الانقسام ده. تلات خطوات عملية:

• عُدّ اللي بينشروا، مش اللي بيطوّروا. لو تمن أشخاص بيغيّروا الميتاداتا واتنين بس يعرفوا يستخدموا خط النشر، فخط النشر بيغطي ربع المخاطرة عندك.
• خلّي الطريق الآمن هو الطريق السهل. كل ساعة بيدفعها الأدمن في المسار الرسمي هي ساعة ضغط ناحية change set يوم الجمعة الساعة خمسة.
• اشترِ لأقل شخص تقني بيشحن. مش لأكتر شخص تقني بيقيّم. دول نادراً ما يكونوا نفس الشخص، والتاني هو اللي بيكتب القائمة المختصرة.

وعلى الافتراض ده بالظبط اتبنى Serpent: نشر بنظام التذاكر وGit شغال في الخلفية، وتراجع بحركة واحدة، ومراجعة كود بالذكاء الاصطناعي في كل الخطط بما فيها المجانية، عشان الأدمن والمطوّر يشحنوا من نفس خط النشر.

FAQ

هل الأدمن محتاجين DevOps فعلاً ولا مجرد change sets أحسن؟

هما محتاجين اللي بيقدمه الـ DevOps: سجل، ومراجعة، وتراجع. والـ change sets مش قادرة تديهم ده بحكم تكوينها، لأنها ما بتحتفظش بسجل نسخ وما ينفعش تتعاد.

هل سير عمل من غير Git معناه من غير تتبّع نسخ؟

لا. معناه إن الـ commits بتتعمل نيابة عنك. المستودع لسه موجود، والمطورون يقدروا يشتغلوا فيه مباشرة.

هل DevOps Center الأصلي هيغني عن الأدوات الخارجية؟

في خطوط النشر البسيطة من مؤسسة لمؤسسة هيغطي فرق أكتر من الحزمة المُدارة. لكن النسخ الاحتياطي والتراجع ومسارات الحزم وشركاء ISV والاختبارات الآلية لسه هي الفجوة.

الفريق اللي مالوش مهندس DevOps يبدأ منين؟

خط نشر واحد، ومؤسسة إنتاج واحدة، وتذكرة لكل تغيير، واعتماد واحد. مرّر إصدار واحد قليل المخاطر من أوله لآخره قبل ما تنقل أي حاجة تانية.