Pieges des Packages Manages 2GP Qui Coutent du Temps aux ISV

Reponse courte : Les erreurs les plus couteuses avec les packages manages de deuxieme generation (2GP) de Salesforce sont les erreurs irreversibles. Votre namespace, votre surface d'API global et votre strategie d'ancestry sont figes tot, alors que la plupart des equipes consacrent cinq minutes a des decisions qu'elles garderont toute la vie du produit. Voici les pieges qui coutent reellement des semaines aux ISV, et celui qui ne peut jamais etre annule.

La documentation Salesforce mentionne la plupart de ces points, mais enterre les consequences. Ce guide les met en avant pour que vous fassiez les choix permanents de maniere deliberee, plutot que de les decouvrir au moment de la promotion.

Pourquoi le namespace de votre package est-il permanent ?

Votre namespace n'est pas "difficile a changer." Il est permanent. Ce que vous tapez un vendredi apres-midi dans un Dev Hub jetable est le prefixe que vous porterez toute la vie du produit. S'il y a la moindre chance que vous separiez ou vendiez un package plus tard, ne partagez pas un seul namespace pour tout, car un namespace ne peut pas etre scinde ensuite. C'est la decision la plus irreversible de tout le cycle de vie et elle merite 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 declare un ancestor, et les orgs installees se mettent a jour le long de cette chaine. Choisissez le mauvais ancestor et vous pouvez bloquer des clients sur une branche qui ne peut pas atteindre votre derniere version.

Le revers est vraiment utile : si la 1.3 devient un desastre, vous pouvez l'abandonner et construire la 1.4 a partir de la 1.2. Mais cela ne fonctionne que si vous avez compris l'arbre avant de livrer, pas apres.

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

Chaque version que vous creez est une beta jusqu'a ce que vous la promouviez. Les betas ne peuvent pas etre installees dans les orgs de production ni poussees vers les subscribers. Les equipes perdent des jours a se demander pourquoi leur package publie ne s'installe pas, et la reponse est que personne n'a execute l'etape de promotion.

La promotion execute aussi des validations, y compris les types d'org et l'execution des tests, elle peut donc echouer au dernier moment. Traitez la promotion comme une vraie barriere, pas une formalite.

Quand la barriere des 75 pour cent de couverture s'applique-t-elle ?

L'exigence de 75 pour cent de couverture s'applique a la promotion, pas a la creation. Vous pouvez produire des betas toute la journee avec des tests faibles, puis heurter le mur au moment ou vous voulez promouvoir pour la release. Si votre equipe traite la couverture comme une tache 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 reelles et se reinitialisent chaque jour. Les creations de version de package et les scratch orgs sont plafonnees par jour selon l'edition. En plein rush, atteindre le plafond signifie que vous avez fini jusqu'a demain. Planifiez les jours de release autour de ces limites plutot que de les decouvrir sous pression.

Pourquoi votre org Dev Hub est-elle un point de defaillance unique ?

Les packages appartiennent au Dev Hub. Perdez l'acces a cette org, via un trial expire, un admin parti, ou des identifiants perdus, et vous avez un vrai probleme. Les transferts de propriete existent mais sont penibles. Placez le Dev Hub sur une org qu'une personne responsable controle vraiment, pas un trial que quelqu'un a cree pour tester.

Qu'est-ce que namespaceAccessible, et pourquoi les equipes le decouvrent-elles trop tard ?

namespaceAccessible est le mecanisme de partage que les gens decouvrent trop tard. Les packages qui partagent un namespace peuvent partager de l'Apex public a travers lui sans devenir global. Les equipes qui ne l'apprennent jamais exposent soit des API global qu'elles ne peuvent jamais reprendre, car global est definitif dans un package manage, soit dupliquent du code entre packages. Les deux font mal pendant des annees.

L'essentiel : decidez les choses permanentes de maniere deliberee

2GP est une vraie amelioration par rapport a 1GP. C'est source driven, il n'y a pas d'orgs de packaging, et le versioning est bien plus flexible. Mais presque chaque piege ci-dessus est invisible jusqu'a ce qu'il morde, et plusieurs sont irreversibles. Les equipes qui livrent sans accroc sont celles qui ont pris les decisions permanentes, namespace, surface global et strategie d'ancestry, deliberement des le debut.

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 manage plus tard ?

Non. Un namespace de package manage est permanent et ne peut pas etre change ou scinde apres liaison. Choisissez-le deliberement et evitez de partager un namespace entre des produits que vous pourriez separer plus tard.

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

Les versions nouvellement creees sont des betas. Les betas ne s'installent que dans les orgs scratch et sandbox. Promouvez la version vers l'etat publie avant qu'elle puisse s'installer en production ou etre poussee vers les subscribers.

Quand la couverture de tests de 75 pour cent est-elle imposee pour 2GP ?

A la promotion, pas a la creation de version. Vous pouvez construire des betas avec une faible couverture, mais vous ne pouvez pas promouvoir une version pour la release tant qu'elle n'atteint pas la barriere des 75 pour cent.

Une methode Apex global est-elle reversible dans un package manage ?

Non. Une fois livre, un membre global fait partie de votre surface d'API permanente. Preferez namespaceAccessible pour partager du code entre packages du meme namespace plutot que d'exposer quelque chose de global que vous ne pourrez jamais retirer.