Vous Planifiez un Package Managé Salesforce ? Décidez d'abord les Choix 2GP Permanents

Réponse courte : Si votre équipe s'apprête à construire un package managé Salesforce en packaging de deuxième génération (2GP), trois de vos premiers choix ne pourront jamais être annulés : votre namespace, les parties de votre code exposées en global, et votre ancestry de version. Décidez-les délibérément avant d'écrire du vrai code, et le reste du cycle de vie devient bien plus serein.

Nous travaillons avec des équipes produit et des ISV qui nous contactent une fois la partie difficile déjà figée. Le schéma est toujours le même : la plateforme documente ces règles mais ne crie pas lesquelles sont permanentes. Ce guide sépare les décisions à réussir en amont des pièges opérationnels dont vous pouvez vous remettre plus tard.

Quelles décisions 2GP ne pouvez-vous jamais reprendre ?

Trois, et ce sont précisément celles que les équipes bâclent.

Votre namespace est définitif

Le namespace attaché à un package ne peut être ni changé ni scindé plus tard. Il devient le préfixe de chaque composant pour toute la vie du produit. S'il y a la moindre chance que vous sépariez ou vendiez un jour une partie de votre portefeuille, ne mettez pas tout sous un namespace partagé, car vous ne pourrez pas le démêler ensuite. Accordez à cette décision une vraie revue, pas une supposition rapide dans une scratch org.

Tout ce qui est global le reste

Une fois un membre livré en global dans un package managé, il fait définitivement partie de votre API publique et vous ne pouvez pas le retirer. Avant de recourir à global, vérifiez si namespaceAccessible résout le problème : les packages qui partagent un namespace peuvent partager de l'Apex public à travers lui sans exposer une surface global que vous devrez supporter des années.

L'ancestry décide qui peut mettre à jour

Chaque version publiée déclare un ancestor, et les orgs installées ne se déplacent que vers le haut le long de cette chaîne. Choisissez l'ancestor sans soin et vous laissez des clients sur une branche qui ne peut atteindre votre dernière version. Compris tôt, le même mécanisme est un atout : si une version tourne mal, vous construisez la suivante à partir d'une version antérieure et saine.

Les pièges opérationnels qui bloquent un jour de release

Ils vous coûteront du temps mais, contrairement aux trois ci-dessus, vous pouvez vous en remettre.

• Bêta contre publié. Chaque version créée commence en bêta qui ne s'installe pas en production et n'atteint pas les subscribers tant que personne ne la promeut. Une étape de promotion oubliée est la raison la plus fréquente qu'un package "terminé" ne s'installe pas.
• La barrière de couverture tombe à la promotion. L'exigence de 75 pour cent de couverture est vérifiée lors de la promotion pour release, pas à la création d'une bêta. Les équipes qui reportent les tests heurtent le mur le jour même prévu pour livrer.
• Les limites du Dev Hub se réinitialisent chaque jour. Les créations de version et les scratch orgs sont plafonnées par jour selon l'édition. Planifiez les jours de release autour des plafonds pour ne pas rester bloqué jusqu'à demain en plein rush.
• Votre Dev Hub est un point de défaillance unique. Les packages appartiennent à l'org Dev Hub. Placez-la sur une org contrôlée par une personne responsable, pas un trial expiré, car les transferts de propriété sont lents et pénibles.

Comment prendre ces décisions de manière délibérée

Les équipes qui livrent des packages sans accroc ne sont pas plus chanceuses, elles sont plus en amont. Elles règlent les choix permanents, namespace, surface global et stratégie d'ancestry, dans une courte session de conception avant tout code, et traitent la promotion comme une vraie barrière avec des tests déjà en place. Si vous voulez un second regard sur ces décisions avant qu'elles ne durcissent, c'est exactement le type de revue que l'équipe Salesforce de Tekunda mène avec les équipes produit.

FAQ

Que devons-nous verrouiller avant de créer notre premier package 2GP ?

Le namespace, quel Apex vous exposez en global, et votre stratégie d'ancestry. Les trois sont de fait permanents, alors mettez-vous d'accord avant d'écrire du code de production.

Comment éviter de bloquer des clients sur une ancienne version de package ?

Planifiez votre ancestry délibérément. Chaque version déclare son ancestor et les subscribers se mettent à jour le long de cette chaîne, donc un mauvais ancestor peut empêcher les clients d'atteindre votre dernière version.

Pourquoi notre package terminé refuse-t-il de s'installer en production ?

C'est presque toujours encore une bêta. Les bêtas ne s'installent qu'en scratch et sandbox. Promouvez la version en publié avant qu'elle puisse s'installer en production ou pousser vers les subscribers.

Quand Salesforce impose-t-il 75 pour cent de couverture de tests pour un package ?

À la promotion. Vous pouvez construire des bêtas à faible couverture, mais la barrière bloque la promotion d'une version pour release tant que la couverture n'est pas atteinte, alors intégrez les tests dès le départ.