مسار إصدار AppExchange: من نسخة الحزمة إلى ترقية المشترك

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

ما هو مسار إصدار AppExchange من أوله لآخره؟

1. إنشاء النسخة. كل نسخة 2GP تُنشأ كـ beta. نسخة beta قابلة للتثبيت للاختبار فقط ولا يمكن نشرها في صفحة التطبيق أبدا.
2. التحقق منها. ثبّتها في scratch org نظيفة وفي sandbox تشبه بيئة عميل حقيقي، ثم شغّل مجموعة الاختبارات كاملة.
3. ترقيتها. الأمر sf package version promote يحوّل نسخة beta إلى نسخة released.
4. تحديث صفحة التطبيق. من Partner Console، تحت Publishing ثم Listings، استخدم Link Your Solution لربط النسخة released ثم انشر.
5. نقل المشتركين. إما تثبيت ذاتي، أو نسخة موصى بها، أو push upgrade.

معظم فرق الـ ISV تنفذ الخطوات الخمس بشكل أو بآخر. الناقص عادة هو الترتيب، والبوابة الفاصلة بين كل مرحلة والتي تليها، وسجل موثوق يوضح أي مؤسسة مشتركة تعمل على أي نسخة.

كيف تجعل نسخة الحزمة قابلة للترقية؟

قابلية الترقية تحددها سلسلة الأصل (ancestry)، لا رقم النسخة الذي كتبته. كل نسخة 2GP جديدة تعلن عن نسخة أصل في sfdx-project.json، وسيلزفورس توصي باستخدام ancestorVersion: HIGHEST حتى يتتبع الأصل أعلى نسخة تمت ترقيتها تلقائيا. العملاء الحاليون لا يستطيعون الترقية إلى نسخة أُنشئت بدون أصل محدد، لذلك بناء واحد ناقص الأصل ينتج نسخة لا يصل إليها أحد.

• حافظ على سلسلة أصل خطية إلا إذا كان لديك سبب مدروس للتفرع.
• تعامل مع خيار skip-ancestor-check باعتباره حادثا استثنائيا، لا أسلوب عمل.
• استخدم أرقام النسخ كما يقرأها المشتركون: رقم رئيسي للتغيير الجذري، ورقم فرعي للمزايا الجديدة، ورقم patch للتصحيحات الصغيرة.

ما الذي يجب أن يكون سليما قبل الترقية إلى released؟

الترقية هي أهم بوابة في المسار كله، لأنها لا تُلغى.

• لا بد أن تحقق نسخة beta شرط تغطية كود بنسبة 75% قبل أن تصبح قابلة للترقية.
• رقم النسخة الواحد يمكن ترقيته وإصداره مرة واحدة فقط، ولا يمكن إعادته إلى beta.
• لا بد أن يكون الأصل صحيحا، لأن النسخة released هي الدرجة التي يصعد عبرها المشتركون.

الأفضل أن تتم الترقية من داخل خط التسليم خلف موافقة بشرية واحدة صريحة، لا من الجهاز الذي تصادف أنه مسجل الدخول إلى Dev Hub. صلاحية الترقية نفسها وسيلة تحكم: امنحها عبر permission set بدلا من منحها لكل من لديه وصول إلى الـ CLI.

متى تحدث المراجعة الأمنية فعليا؟

في أول إدراج للتطبيق، تقع المراجعة الأمنية بين مرحلة التحقق ومرحلة النشر، وهي أطول بند في الجدول الزمني. أما مع التحديثات فالصورة مختلفة. لست مضطرا لمراجعة أمنية كاملة مع كل patch أو ترقية، والذي يحكم النشر هو حالة صفحة التطبيق. إذا ظهرت الحالة Ready to List، يمكنك نشر الصفحة المحدثة بدون تقديم النسخة الجديدة للمراجعة. أما إذا ظهرت Security Review Required، فلن تستطيع النشر حتى تجتاز تلك النسخة المراجعة.

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

كيف ترقّي المشتركين بدون أن تترك أحدا عالقا؟

ثلاث أدوات، من الأقل تدخلا إلى الأكثر:

1. التثبيت الذاتي. يثبّت المشترك من صفحة التطبيق أو من رابط تثبيت وقتما يناسبه. أبطأ تقارب بين النسخ، وأقل مخاطرة.
2. النسخة الموصى بها. في 2GP يمكنك وسم نسخة بأنها موصى بها، فيظهر للمشترك خيار Upgrade to Recommended Version في صفحة Installed Packages عنده. تنبيه ودعوة، لا قرار تتخذه نيابة عنه.
3. الـ push upgrade. أنت من يرقّي مؤسسات المشتركين، وتختار أي مؤسسات وأي نسخة وفي أي وقت. الحزم التي اجتازت المراجعة الأمنية لـ AppExchange وحدها المؤهلة، والخاصية يفعّلها دعم الشركاء في سيلزفورس، وفي 2GP يتم الـ push upgrade من الـ CLI أو SOAP API لا من الواجهة.

طرح تدريجي يصمد عمليا: مؤسساتك أنت أولا، ثم مؤسسات الشركاء وبيئات الـ sandbox، ثم مجموعة صغيرة من العملاء الموافقين، ثم البقية على دفعات مجدولة خارج ساعات الذروة. اترك بين كل دفعة وأخرى وقتا يكفي لوصول تذكرة دعم حقيقية، وهذا عادة يوم عمل كامل لا ساعة واحدة.

ما الذي يقع فيه الجميع عمليا

• لا يوجد رجوع لنسخة أقدم. المشترك الذي رقّى لا يستطيع العودة. خطة التراجع عندك هي نسخة patch جديدة للأمام، فاحتفظ بفرع الإصدار في حالة تسمح بإخراجها في نفس اليوم.
• انفصال صفحة التطبيق عن الحزمة. نسخة تمت ترقيتها ولم تُربط بالصفحة تعني أن العملاء الجدد يثبتون بناء الربع الماضي بينما توثيقك يصف بناء هذا الربع.
• انكسار سلسلة الأصل بهدوء. لا شيء يفشل وقت البناء. الفشل يظهر بعد شهور، داخل مؤسسة عميل، على هيئة ترقية ترفض أن تبدأ.
• تخطي بيئات الاختبار عند العميل. اكتب في ملاحظات الإصدار أن يرقّي العميل بيئة Full أو Partial sandbox أولا. هذه هي البروفة الوحيدة المتاحة للطرفين.

ما الذي تؤتمته أولا؟

1. إنشاء النسخة مع حساب تغطية الكود عند كل دمج في فرع الإصدار.
2. تثبيت نسخة الـ beta واختبارها اختبارا سريعا في scratch org نظيفة، بشكل آلي.
3. الترقية خلف موافقة بشرية واحدة بالضبط، مع فحص نسخة الأصل قبلها.
4. سجل نسخ: أي مؤسسة مشتركة تعمل على أي نسخة، يُحدَّث بعد كل عملية دفع.

البند الرابع هو ما تؤجله الفرق ثم تندم عليه، لأن جودة الدعم تعتمد عليه أكثر من أي بند آخر في القائمة. Serpent يغطي مسارات 1GP و2GP والحزم المُدارة، وحل الاعتماديات بين الحزم، وإدارة النسخ عبر مؤسسات المشتركين في كل الخطط بما فيها الخطة المجانية. تجد أدلة تعبئة أخرى في مكتبة SF Guides عندنا.

FAQ

هل أستطيع التراجع عن ترقية نسخة إلى released؟

لا. رقم النسخة يُرقّى ويُصدر مرة واحدة فقط والتغيير لا يُلغى، فتعامل مع الترقية كقرار إصدار لا كخطوة بناء.

هل أحتاج مراجعة أمنية جديدة مع كل إصدار؟

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

لماذا لا يستطيع عميلي الترقية إلى أحدث نسخة عندي؟

السبب غالبا سلسلة الأصل. العملاء الحاليون لا يستطيعون الترقية إلى نسخة أُنشئت بدون أصل محدد، فافحص الأصل قبل أي شيء آخر.

ما الفرق بين النسخة الموصى بها والـ push upgrade؟

النسخة الموصى بها تعرض للمشترك خيار Upgrade to Recommended Version وتترك له التوقيت. أما الـ push upgrade فينقل مؤسسته بدلا عنه وفق جدولك أنت.

هل تُحسب نسخ beta إصدارات؟

لا. كل نسخة 2GP تبدأ beta وتُثبّت للاختبار فقط. وتصبح إصدارا في اللحظة التي تُرقّى فيها.