Vous Planifiez un Package Manage Salesforce ? Decidez d'abord les Choix 2GP Permanents

Reponse courte : Si votre equipe s'apprete a construire un package manage Salesforce en packaging de deuxieme generation (2GP), trois de vos premiers choix ne pourront jamais etre annules : votre namespace, les parties de votre code exposees en global, et votre ancestry de version. Decidez-les deliberement avant d'ecrire du vrai code, et le reste du cycle de vie devient bien plus serein.

Nous travaillons avec des equipes produit et des ISV qui nous contactent une fois la partie difficile deja figee. Le schema est toujours le meme : la plateforme documente ces regles mais ne crie pas lesquelles sont permanentes. Ce guide separe les decisions a reussir en amont des pieges operationnels dont vous pouvez vous remettre plus tard.

Quelles decisions 2GP ne pouvez-vous jamais reprendre ?

Trois, et ce sont precisement celles que les equipes bâclent.

Votre namespace est definitif

Le namespace attache a un package ne peut etre ni change ni scinde plus tard. Il devient le prefixe de chaque composant pour toute la vie du produit. S'il y a la moindre chance que vous separiez ou vendiez un jour une partie de votre portefeuille, ne mettez pas tout sous un namespace partage, car vous ne pourrez pas le demeler ensuite. Accordez a cette decision une vraie revue, pas une supposition rapide dans une scratch org.

Tout ce qui est global le reste

Une fois un membre livre en global dans un package manage, il fait definitivement partie de votre API publique et vous ne pouvez pas le retirer. Avant de recourir a global, verifiez si namespaceAccessible resout le probleme : les packages qui partagent un namespace peuvent partager de l'Apex public a travers lui sans exposer une surface global que vous devrez supporter des annees.

L'ancestry decide qui peut mettre a jour

Chaque version publiee declare un ancestor, et les orgs installees ne se deplacent que vers le haut le long de cette chaine. Choisissez l'ancestor sans soin et vous laissez des clients sur une branche qui ne peut atteindre votre derniere version. Compris tot, le meme mecanisme est un atout : si une version tourne mal, vous construisez la suivante a partir d'une version anterieure et saine.

Les pieges operationnels qui bloquent un jour de release

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

• Beta contre publie. Chaque version creee commence en beta qui ne s'installe pas en production et n'atteint pas les subscribers tant que personne ne la promeut. Une etape de promotion oubliee est la raison la plus frequente qu'un package "termine" ne s'installe pas.
• La barriere de couverture tombe a la promotion. L'exigence de 75 pour cent de couverture est verifiee lors de la promotion pour release, pas a la creation d'une beta. Les equipes qui reportent les tests heurtent le mur le jour meme prevu pour livrer.
• Les limites du Dev Hub se reinitialisent chaque jour. Les creations de version et les scratch orgs sont plafonnees par jour selon l'edition. Planifiez les jours de release autour des plafonds pour ne pas rester bloque jusqu'a demain en plein rush.
• Votre Dev Hub est un point de defaillance unique. Les packages appartiennent a l'org Dev Hub. Placez-la sur une org controlee par une personne responsable, pas un trial expire, car les transferts de propriete sont lents et penibles.

Comment prendre ces decisions de maniere deliberee

Les equipes qui livrent des packages sans accroc ne sont pas plus chanceuses, elles sont plus en amont. Elles reglent les choix permanents, namespace, surface global et strategie d'ancestry, dans une courte session de conception avant tout code, et traitent la promotion comme une vraie barriere avec des tests deja en place. Si vous voulez un second regard sur ces decisions avant qu'elles ne durcissent, c'est exactement le type de revue que l'equipe Salesforce de Tekunda mene avec les equipes produit.

FAQ

Que devons-nous verrouiller avant de creer notre premier package 2GP ?

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

Comment eviter de bloquer des clients sur une ancienne version de package ?

Planifiez votre ancestry deliberement. Chaque version declare son ancestor et les subscribers se mettent a jour le long de cette chaine, donc un mauvais ancestor peut empecher les clients d'atteindre votre derniere version.

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

C'est presque toujours encore une beta. Les betas ne s'installent qu'en scratch et sandbox. Promouvez la version en publie 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 ?

A la promotion. Vous pouvez construire des betas a faible couverture, mais la barriere bloque la promotion d'une version pour release tant que la couverture n'est pas atteinte, alors integrez les tests des le depart.