Pièges des Packages Managés 2GP Qui Coûtent du Temps aux ISV

Réponse courte : Les erreurs les plus coûteuses avec les packages managés de deuxième génération (2GP) de Salesforce sont les erreurs irréversibles. Votre namespace, votre surface d'API global et votre stratégie d'ancestry sont figés tôt, alors que la plupart des équipes consacrent cinq minutes à des décisions qu'elles garderont toute la vie du produit. Voici les pièges qui coûtent réellement des semaines aux ISV, et celui qui ne peut jamais être annulé.

La documentation Salesforce mentionne la plupart de ces points, mais enterre les conséquences. Ce guide les met en avant pour que vous fassiez les choix permanents de manière délibérée, plutôt que de les découvrir au moment de la promotion.

Pourquoi le namespace de votre package est-il permanent ?

Votre namespace n'est pas "difficile à changer." Il est permanent. Ce que vous tapez un vendredi après-midi dans un Dev Hub jetable est le préfixe que vous porterez toute la vie du produit. S'il y a la moindre chance que vous sépariez ou vendiez un package plus tard, ne partagez pas un seul namespace pour tout, car un namespace ne peut pas être scindé ensuite. C'est la décision la plus irréversible de tout le cycle de vie et elle mérite bien plus que cinq minutes.

Comment l'ancestry bloque-t-elle vos subscribers ?

L'ancestry est un arbre, et vos subscribers ne peuvent que le gravir. Chaque nouvelle version déclare un ancestor, et les orgs installées se mettent à jour le long de cette chaîne. Choisissez le mauvais ancestor et vous pouvez bloquer des clients sur une branche qui ne peut pas atteindre votre dernière version.

Le revers est vraiment utile : si la 1.3 devient un désastre, vous pouvez l'abandonner et construire la 1.4 à partir de la 1.2. Mais cela ne fonctionne que si vous avez compris l'arbre avant de livrer, pas après.

Pourquoi votre package "publié" ne s'installe-t-il pas ?

Chaque version que vous créez est une bêta jusqu'à ce que vous la promouviez. Les bêtas ne peuvent pas être installées dans les orgs de production ni poussées vers les subscribers. Les équipes perdent des jours à se demander pourquoi leur package publié ne s'installe pas, et la réponse est que personne n'a exécuté l'étape de promotion.

La promotion exécute aussi des validations, y compris les types d'org et l'exécution des tests, elle peut donc échouer au dernier moment. Traitez la promotion comme une vraie barrière, pas une formalité.

Quand la barrière des 75 pour cent de couverture s'applique-t-elle ?

L'exigence de 75 pour cent de couverture s'applique à la promotion, pas à la création. Vous pouvez produire des bêtas toute la journée avec des tests faibles, puis heurter le mur au moment où vous voulez promouvoir pour la release. Si votre équipe traite la couverture comme une tâche de nettoyage pour plus tard, "plus tard" arrive exactement quand vous essayez de livrer.

Quelles limites du Dev Hub stopperont votre jour de release ?

Les limites du Dev Hub sont réelles et se réinitialisent chaque jour. Les créations de version de package et les scratch orgs sont plafonnées par jour selon l'édition. En plein rush, atteindre le plafond signifie que vous avez fini jusqu'à demain. Planifiez les jours de release autour de ces limites plutôt que de les découvrir sous pression.

Pourquoi votre org Dev Hub est-elle un point de défaillance unique ?

Les packages appartiennent au Dev Hub. Perdez l'accès à cette org, via un trial expiré, un admin parti, ou des identifiants perdus, et vous avez un vrai problème. Les transferts de propriété existent mais sont pénibles. Placez le Dev Hub sur une org qu'une personne responsable contrôle vraiment, pas un trial que quelqu'un a créé pour tester.

Qu'est-ce que namespaceAccessible, et pourquoi les équipes le découvrent-elles trop tard ?

namespaceAccessible est le mécanisme de partage que les gens découvrent trop tard. Les packages qui partagent un namespace peuvent partager de l'Apex public à travers lui sans devenir global. Les équipes qui ne l'apprennent jamais exposent soit des API global qu'elles ne peuvent jamais reprendre, car global est définitif dans un package managé, soit dupliquent du code entre packages. Les deux font mal pendant des années.

L'essentiel : décidez les choses permanentes de manière délibérée

2GP est une vraie amélioration par rapport à 1GP. C'est source driven, il n'y a pas d'orgs de packaging, et le versioning est bien plus flexible. Mais presque chaque piège ci-dessus est invisible jusqu'à ce qu'il morde, et plusieurs sont irréversibles. Les équipes qui livrent sans accroc sont celles qui ont pris les décisions permanentes, namespace, surface global et stratégie d'ancestry, délibérément dès le début.

Si vous construisez un processus Salesforce DevOps autour du packaging, nos autres guides Salesforce DevOps couvrent les patterns de pipeline qui rendent ces releases reproductibles.

FAQ

Peut-on changer un namespace de package managé plus tard ?

Non. Un namespace de package managé est permanent et ne peut pas être changé ou scindé après liaison. Choisissez-le délibérément et évitez de partager un namespace entre des produits que vous pourriez séparer plus tard.

Pourquoi mon package 2GP ne s'installe-t-il pas en production ?

Les versions nouvellement créées sont des bêtas. Les bêtas ne s'installent que dans les orgs scratch et sandbox. Promouvez la version vers l'état publié avant qu'elle puisse s'installer en production ou être poussée vers les subscribers.

Quand la couverture de tests de 75 pour cent est-elle imposée pour 2GP ?

À la promotion, pas à la création de version. Vous pouvez construire des bêtas avec une faible couverture, mais vous ne pouvez pas promouvoir une version pour la release tant qu'elle n'atteint pas la barrière des 75 pour cent.

Une méthode Apex global est-elle réversible dans un package managé ?

Non. Une fois livré, un membre global fait partie de votre surface d'API permanente. Préférez namespaceAccessible pour partager du code entre packages du même namespace plutôt que d'exposer quelque chose de global que vous ne pourrez jamais retirer.