تخطط لحزمة Salesforce مُدارة؟ احسم قرارات 2GP الدائمة أولًا

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

نعمل مع فرق المنتجات ومطوّري ISV الذين يصلون إلينا بعد أن يكون الجزء الصعب قد تثبّت بالفعل. النمط دائمًا نفسه: المنصة توثّق هذه القواعد لكنها لا تُبرز أيها دائم. هذا الدليل يفصل القرارات التي يجب أن تصيبها مسبقًا عن المزالق التشغيلية التي يمكنك التعافي منها لاحقًا.

أي قرارات 2GP لا يمكنك التراجع عنها أبدًا؟

ثلاثة، وهي تحديدًا التي تتعجّل فيها الفرق.

الـ namespace إلى الأبد

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

ما هو global يبقى global

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

الـ ancestry يقرّر من يستطيع الترقية

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

المزالق التشغيلية التي تُعطّل يوم الإصدار

ستكلّفك وقتًا، لكنها بعكس الثلاثة أعلاه يمكنك التعافي منها.

• beta مقابل released. كل إصدار تنشئه يبدأ beta لا يُثبَّت في الإنتاج ولا يصل المشتركين حتى يقوم أحد بترقيته. تخطّي خطوة الـ promote هو السبب الأكثر شيوعًا لعدم تثبيت حزمة "مكتملة".
• بوابة التغطية تقع وقت الـ promote. شرط تغطية 75 بالمئة يُفحص عند الترقية للإصدار لا عند إنشاء beta. الفرق التي تؤجّل الاختبار تصطدم بالجدار في اليوم نفسه المخطط للشحن.
• حدود Dev Hub تُعاد يوميًا. إنشاءات الإصدارات و scratch orgs مقيّدة يوميًا حسب الإصدار. خطّط أيام الإصدار حول الحدود كي لا تعلق حتى الغد وسط الضغط.
• الـ Dev Hub نقطة فشل وحيدة. الحزم مملوكة لمؤسسة الـ Dev Hub. ضعها على مؤسسة يتحكم بها شخص مسؤول، لا تجربة منتهية، لأن نقل الملكية بطيء ومؤلم.

كيف تتخذ هذه القرارات بوعي

الفرق التي تشحن الحزم بسلاسة ليست أكثر حظًا، بل أبكر. تحسم القرارات الدائمة، الـ namespace والسطح الـ global واستراتيجية الـ ancestry، في جلسة تصميم قصيرة قبل وجود أي كود، وتعامل الـ promote كبوابة حقيقية مع اختبارات جاهزة. إن أردت رأيًا ثانيًا في هذه القرارات قبل أن تترسّخ، فهذا بالضبط نوع المراجعة التي يجريها فريق Salesforce في Tekunda مع فرق المنتجات.

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

ما الذي يجب أن نحسمه قبل إنشاء أول حزمة 2GP؟

الـ namespace، وأي Apex تكشفه كـ global، واستراتيجية الـ ancestry. الثلاثة دائمة فعليًا، فاتفقوا عليها قبل كتابة كود الإنتاج.

كيف نتجنّب حبس العملاء على إصدار حزمة قديم؟

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

لماذا ترفض حزمتنا المكتملة التثبيت في الإنتاج؟

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

متى تفرض Salesforce تغطية اختبار 75 بالمئة لحزمة؟

عند الترقية. يمكنك بناء إصدارات beta بتغطية منخفضة، لكن البوابة تمنع ترقية إصدار للإصدار النهائي حتى تُستوفى التغطية، لذا ادمج الاختبارات من البداية.