مزالق حزم 2GP المُدارة التي تكلّف مطوّري ISV وقتًا حقيقيًا

الإجابة باختصار: أغلى الأخطاء في حزم Salesforce المُدارة من الجيل الثاني (2GP) هي الأخطاء التي لا رجعة فيها. الـ namespace الخاص بك، وسطح الـ API الـ global، واستراتيجية الـ ancestry كلها تُثبّت مبكرًا، ومع ذلك تقضي معظم الفرق خمس دقائق على قرارات ستعيش معها طوال عمر المنتج. فيما يلي المزالق التي تكلّف مطوّري ISV أسابيع فعلية، وذلك المزلق الوحيد الذي لا يمكن التراجع عنه أبدًا.

توثيق Salesforce يذكر معظم هذه النقاط لكنه يدفن عواقبها. هذا الدليل يضعها في المقدمة حتى تتخذ القرارات الدائمة بوعي بدلًا من اكتشافها وقت الـ promote.

لماذا يكون namespace الحزمة دائمًا؟

الـ namespace ليس "صعب التغيير." إنه دائم. ما تكتبه ظهر يوم جمعة في Dev Hub مؤقت هو البادئة التي ستحملها طوال عمر المنتج. إن كان هناك أي احتمال أن تفصل حزمة أو تبيعها لاحقًا، فلا تشارك namespace واحدًا عبر كل شيء، لأن الـ namespace لا يمكن تقسيمه بعد ذلك. هذا هو القرار الأكثر استحالة للتراجع في دورة الحياة كلها، ويستحق أكثر بكثير من خمس دقائق.

كيف يُعلّق الـ ancestry مشتركيك؟

الـ ancestry شجرة، ومشتركوك لا يمكنهم إلا تسلّقها. كل إصدار جديد يعلن عن ancestor، والمؤسسات المثبّتة تُحدّث على طول تلك السلسلة. اختر الـ ancestor الخطأ وقد تترك العملاء عالقين على فرع لا يستطيع الوصول إلى أحدث إصداراتك.

الجانب الآخر مفيد فعلًا: إذا صار الإصدار 1.3 فوضى، يمكنك التخلي عنه وبناء 1.4 على أساس 1.2. لكن هذا يعمل فقط إذا فهمت الشجرة قبل الشحن، لا بعده.

لماذا لا تُثبَّت حزمتك "المُصدَرة"؟

كل إصدار تنشئه هو beta حتى تقوم بترقيته (promote). لا يمكن تثبيت إصدارات الـ beta في مؤسسات الإنتاج ولا دفعها إلى المشتركين. تضيّع الفرق أيامًا في التساؤل عن سبب عدم تثبيت حزمتها المُصدَرة، والجواب أن لا أحد نفّذ خطوة الـ promote.

عملية الـ promote تُجري أيضًا عمليات تحقق، تشمل أنواع المؤسسات وتنفيذ الاختبارات، لذا قد تفشل في اللحظة الأخيرة. تعامل مع الـ promote كبوابة حقيقية لا كإجراء شكلي.

متى تضرب بوابة تغطية الكود بنسبة 75 بالمئة؟

شرط التغطية بنسبة 75 بالمئة يضرب وقت الـ promote لا وقت الإنشاء. يمكنك إنتاج إصدارات beta طوال اليوم باختبارات ضعيفة، ثم تصطدم بالجدار لحظة محاولتك الترقية للإصدار. إذا عاملت فرقك التغطية كمهمة تنظيف للاحقًا، فإن "لاحقًا" تأتي بالضبط حين تحاول الشحن.

أي حدود لـ Dev Hub ستوقف يوم إصدارك؟

حدود الـ Dev Hub حقيقية وتُعاد يوميًا. عمليات إنشاء إصدارات الحزم و scratch orgs مقيّدة يوميًا حسب الإصدار. في خضم الضغط، يعني بلوغ الحد أنك انتهيت حتى الغد. خطّط أيام الإصدار حول هذه الحدود بدلًا من اكتشافها تحت الضغط.

لماذا تُعدّ مؤسسة Dev Hub نقطة فشل وحيدة؟

الحزم مملوكة للـ Dev Hub. افقد الوصول إلى تلك المؤسسة، عبر تجربة منتهية، أو مسؤول غادر، أو بيانات دخول ضائعة، وستواجه مشكلة حقيقية. عمليات نقل الملكية موجودة لكنها مؤلمة. ضع الـ Dev Hub على مؤسسة يتحكم بها شخص مسؤول فعلًا، لا تجربة أنشأها أحدهم للاختبار.

ما هو namespaceAccessible ولماذا تكتشفه الفرق متأخرًا؟

namespaceAccessible هو آلية المشاركة التي يكتشفها الناس متأخرًا. الحزم التي تتشارك namespace يمكنها مشاركة Apex العام من خلاله دون أن تصبح global. الفرق التي لا تتعلم هذا إما تكشف واجهات global لا يمكنها استرجاعها أبدًا، لأن الـ global دائم في الحزمة المُدارة، أو تكرّر الكود عبر الحزم. وكلاهما يؤلم لسنوات.

الخلاصة: قرّر الأمور الدائمة بوعي

الـ 2GP تحسّن حقيقي مقارنة بالـ 1GP. فهو source driven، ولا توجد packaging orgs، والـ versioning أكثر مرونة بكثير. لكن كل مزلق أعلاه تقريبًا خفيّ حتى يعضّ، وعدد منها لا رجعة فيه. الفرق التي تشحن بسلاسة هي التي اتخذت القرارات الدائمة، الـ namespace والسطح الـ global واستراتيجية الـ ancestry، بوعي منذ البداية.

إن كنت تبني عملية Salesforce DevOps حول الـ packaging، فإن أدلة Salesforce DevOps الأخرى لدينا تغطي أنماط الـ pipeline التي تجعل هذه الإصدارات قابلة للتكرار.

الأسئلة الشائعة

هل يمكن تغيير namespace الحزمة المُدارة لاحقًا؟

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

لماذا لا تُثبَّت حزمة 2GP الخاصة بي في الإنتاج؟

الإصدارات المُنشأة حديثًا هي beta. إصدارات الـ beta تُثبَّت فقط في مؤسسات الـ scratch والـ sandbox. رقِّ الإصدار إلى الحالة المُصدَرة قبل أن يُثبَّت في الإنتاج أو يُدفع إلى المشتركين.

متى تُفرض تغطية الاختبار بنسبة 75 بالمئة لـ 2GP؟

عند الـ promote لا عند إنشاء الإصدار. يمكنك بناء إصدارات beta بتغطية منخفضة، لكن لا يمكنك ترقية إصدار للإصدار النهائي حتى يبلغ بوابة الـ 75 بالمئة.

هل يمكن التراجع عن دالة Apex من نوع global في حزمة مُدارة؟

لا. بمجرد شحنه، يصبح العضو الـ global جزءًا من سطح الـ API الدائم لديك. فضّل namespaceAccessible لمشاركة الكود بين الحزم في نفس الـ namespace بدلًا من كشف شيء global لا يمكنك إزالته أبدًا.