ليه الـ change sets بتعطّل فريق سيلزفورس بتاعك

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

ليه الـ change sets لسه عايشة في أغلب الـ orgs؟

مش لأن الفرق ما سمعتش عن البدائل. لأن الـ change set حامل أساسي في العملية اللي حواليه. حد ماسك ملف الإكسل بتاع المكوّنات. وحد تاني معاه البروفايل اللي بيسمح بالرفع. وموافقة الـ UAT صورة شاشة في تيكت. وليلة الإصدار دعوة في التقويم، والدعوة دي هي الخطة.

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

الـ change sets بتكلّف كام فعلًا؟

مش العشرين دقيقة بتاعة الضغط بالماوس. التكلفة هي إعادة الشغل، وبتتراكم في خمس أماكن.

• إعادة بناء القايمة. الـ change set جرد يدوي لللي إنت فاكر إنك غيّرته. أي حاجة تنساها بتوقّع النشر أو، أسوأ، بتخليه ينجح نص نجاح.
• مفيش رجوع. مفيش زرار عكس، فالنسخة المنضبطة من الممارسة إنك تبني change set تاني مطابق مع كل إصدار: شغل مضاعف مقابل نص شبكة أمان.
• ميتاداتا مش بتتحرك. في أنواع مكوّنات مش مدعومة أصلًا، وكل واحدة منها بتتحول لخطوة يدوية بعد النشر عايشة في دماغ حد (القيود الموثّقة).
• البروفايلات. نشر بروفايل بيكتب فوق الهدف، فالصلاحيات اللي كانت موجودة هناك بس بتختفي في صمت.
• مفيش شغل متوازي. اتنين بيعدّلوا نفس الكائن في ساندبوكسين بيكتشفوا ده وقت النشر، لأن مفيش حاجة بتقارن أي حاجة.

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

مش DevOps Center هو الحل؟

هو حل حقيقي لجزء من المشكلة، وهو مجاني. سيلزفورس أتاحت DevOps Center بشكل عام في ديسمبر 2022 (ملاحظات الإصدار)، واستبدلت اختيار المكوّنات اليدوي بتتبّع تغييرات وخط عمل قايم على Git.

السقف بيبان في اللي مش بيعمله: مفيش رجوع تلقائي، ولا نسخ احتياطي واسترجاع، ودعم التحكم في الإصدارات محصور في عدد قليل من مزوّدي Git المستضافين. وفي يوليو 2026 كتبت Salesforce Ben عن DX Inspector، ووصفته كأداة نشر من سيلزفورس بتنقل الميتاداتا وبيانات السجلات وتقدر تتكامل مع DevOps Center (المقال). الاتجاه واضح: حتى سيلزفورس نفسها مش بتستثمر في الـ change sets.

ليه حجة الميزانية بقت مش صامدة؟

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

الفجوة دي اتقفلت من الناحيتين. DevOps Center مجاني. وخطة Essentials من Serpent مجانية كمان، بمستخدمين بلا حد، ورجوع بضغطة واحدة، ومراجعة كود بالذكاء الاصطناعي، وسير عمل كامل للحزم، وSerpent مش بيثبّت أي حاجة جوه الـ org بتاعتك. وGearset وCopado وFlosum وAutoRABIT كلهم ناشرين قوايم طويلة لقيود الـ change sets، وده في حد ذاته إشارة: محدش بيبيع في السوق ده بينكر الألم.

يبقى السؤال مابقاش الأداة بتكلّف كام. السؤال بقى: فريقك مستعد يغيّر طريقة اعتماد الإصدار ولا لأ؟

إيه اللي بيتغيّر فعلًا لما تسيب العادة؟

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

أغلب فرق سيلزفورس أدمنز ومستشارين عمرهم ما فتحوا terminal. أي عملية بتشترط إتقان Git علشان تبقى آمنة مش هتتبنى، والفريق هيفضل بيضغط بالماوس.

ده الجزء اللي بيحدد التبنّي. أي أداة بتحوّل الأدمنز بتوعك لمستخدمي Git على مضض تكون نقلت عنق الزجاجة مش شالته.

إزاي تخرج من الـ change sets من غير ما توقّف التسليم؟

1. اختار خط واحد، غالبًا org إنتاج واحدة وساندبوكساتها، وسيب الباقي في حاله.
2. حط الحالة الحالية للـ org دي في نظام إصدارات قبل ما تغيّر أي عملية، علشان يبقى عندك أساس تقارن عليه.
3. شغّل الإصدار الجاي بالطريقتين لدورة واحدة. الخط الجديد يبني الحزمة، والعملية القديمة تفضل خطة الرجوع.
4. انقل الموافقات لعنصر الشغل، مش لملف إكسل. دي العادة اللي لازم تتكسر فعلًا.
5. وبعد كده بس شغّل الأتمتة: تحقق على الـ pull request، وتشغيل اختبارات، ورجوع، وكشف انحراف.

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

FAQ

هل الـ change sets اتلغت؟

لأ. لسه شغالة وسيلزفورس ما أعلنتش أي تاريخ إيقاف. لكن استثمار المنصة اتحوّل لـ DevOps Center والأدوات الأحدث، فبناء عملية الإصدار على الـ change sets رهان على الجمود.

ينفع ترجّع change set؟

مش بشكل أصلي. الحل الشائع تجهيز change set مطابق ينشر النسخة السابقة، وده بيفيد بس مع المكوّنات اللي كانت موجودة.

هل DevOps Center كفاية لوحده؟

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

هل لازم الأدمنز يتعلموا Git علشان يسيبوا الـ change sets؟

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