إدارة الإصدارات عبر مؤسسات المشتركين، وليه الشركات لسه بتعملها بالإيد

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

يعني إيه بالظبط إدارة الإصدارات عبر مؤسسات المشتركين؟

دي في الحقيقة تلات مهام منفصلة اتلمّت في مصطلح واحد:

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

معظم الفرق عندها إجابة تقريبية على الأولى، ومفيش إجابة على التانية، وعملية يدوية للتالتة.

ليه مصفوفة الإصدارات هي اللي بتحدد تكلفة الدعم؟

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

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

إزاي تعرف أي إصدار شغال عند المشترك؟

أربع طرق، كل واحدة ليها قيد:

• تطبيق إدارة التراخيص. متثبّت في مؤسسة الأعمال الشريكة بتاعتك، والتطبيق ده بيعمل سجل عميل محتمل وسجل ترخيص مع كل تثبيت، وبيحمل كائنات Package و Package Version لكل حزمة 1GP أو 2GP منشورة عندك على AppExchange. ده سجلك الرسمي. ابدأ من هنا.
• وحدة دعم المشتركين. دقيقة، بس بتتطلب إن العميل يمنحك صلاحية الدخول الأول، وده بيخليها أداة لكل حادثة على حدة مش أداة جرد.
• اسأل المسؤول. Setup وبعدين Installed Packages واقرا رقم الإصدار. تمام مرة واحدة. بلا فايدة مع مئتين مؤسسة.
• واجهة Tooling API. يهمك تعرف إن InstalledSubscriberPackageVersion بقى مهجورًا ومُقرَّرًا إزالته، فمتبنيش عليه طبقة تقارير.

لاحظ إن مفيش واحدة من دول لوحة معلومات. دي الفجوة، وده سبب وجود ملف الجداول.

ليه لسه الشركات بتعمل ده بالإيد؟

مش كسل. البيانات موزعة على تلات أنظمة مش بتكلم بعض: التراخيص في مؤسسة الأعمال الشريكة، وإصدارات الحزم في Dev Hub، وتاريخ الإصدارات الحقيقي في Git وخط الإنتاج بتاعك. ربطهم مشروع تكامل داخلي صغير، وعمره ما بيكسب سبرنت قدام الشغل اللي العميل شايفه. فبيفضل ملف جداول، وحد بيحدّثه بعد كل إصدار، وفي الربع التالت محدش بيثق فيه بالكامل.

الأتمتة شكلها إيه؟

1. اعتبر تطبيق إدارة التراخيص هو مصدر الحقيقة لمين عنده إيه، وزامنه بجدول ثابت بدل ما تفتحه وقت الحاجة.
2. اربط سجلات التراخيص بتاريخ إصداراتك، عشان كل صف مشترك يحمل الإصدار المثبّت وتاريخ إطلاقه واللي اتغير من ساعتها.
3. حوّل التشتت لرقم بتتابعه كل أسبوع: عدد الإصدارات الشغالة، وعمر أقدم واحد فيهم.
4. حدد أرضية دعم، يعني أقدم إصدار هتفضل تصلح فيه الأخطاء، وخليها ظاهرة لفريق الدعم مش للهندسة بس.
5. قسّم المؤسسات لموجات ترقية: مؤسساتك إنت، بعدين بيئات اختبار العملاء، بعدين العملاء المتعاونين، بعدين الباقي.
6. خلي "أي إصدار؟" حقل بيتملي أوتوماتيك في التذكرة، مش سؤال مهندس الدعم مضطر يسأله.

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

إمتى تدفع الترقية بدل ما تطلبها؟

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

• الحزم اللي عدّت مراجعة أمان AppExchange بس هي المؤهلة.
• في 2GP مفيش مسار بالواجهة الرسومية. ترقيات الدفع بتشتغل من سطر الأوامر أو واجهة SOAP.
• وزّعها على مراحل. إرشادات سيلزفورس نفسها بتقول اختبر في مؤسساتك الأول، بعدين بيئات اختبار العملاء، بعدين دفعة إنتاج صغيرة، وبعد كده الباقي، وابعد عن فترات الإقفال المالي والأسابيع اللي بعد إصدار سيلزفورس الكبير مباشرة.
• من إصدار Summer '26 تقدر تحدّ المحاولة. سجل PushUpgradeCustomizationRepository في مؤسسة التغليف 1GP أو Dev Hub بتاع 2GP بيحدد نافذة انتهاء، وبعدها سيلزفورس بتبطل إعادة المحاولة.

الدفع ده نشر في بيئة إنتاج حد تاني. عامله كده: نفس المراجعة، ونفس خطة التراجع، ونفس سجل التغيير.

الأدوات واقفة فين دلوقتي؟

معظم منصات Salesforce DevOps، زي Copado و Gearset و AutoRABIT و Flosum وغيرهم، مبنية حوالين التسليم من مؤسسة لمؤسسة والمدعوم بـ Git، وبتعمل ده كويس. تسليم الحزم لشركات البرمجيات المستقلة كان تاريخيًا النص الأرفع من الفئة دي. وده النص اللي بنينا Serpent حواليه: مسارات عمل أصلية لـ 1GP و 2GP والحزم المُدارة، وحل الاعتماديات بين الحزم، وإدارة الإصدارات عبر مؤسسات المشتركين، ومسارات إصدار AppExchange، في كل الخطط بما فيها الخطة المجانية.

FAQ

أقدر أشوف إصدار كل مشترك في مكان واحد افتراضيًا؟

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

ترقيات الدفع آمنة للإصدارات الكبرى؟

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

كام إصدار شغال المفروض الشركة تدعمهم؟

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

تطبيق إدارة التراخيص بيغطي 1GP و 2GP الاتنين؟

أيوه. كائنات Package و Package Version بتحمل تفاصيل كل حزمة وكل إصدار 1GP أو 2GP منشور عندك على AppExchange.

لسه أقدر أستعلم عن InstalledSubscriberPackageVersion؟

موجود من إصدار الواجهة 41.0، لكن سيلزفورس علّمته كمهجور وناوية تشيله. متخليهوش اعتمادية عندك.

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