Le workflow de release AppExchange : de la version de package a l'upgrade des abonnes

Reponse courte : une release AppExchange se deroule en cinq etapes : creer une version beta du package, la valider, la promouvoir en version released, la relier a votre listing, puis faire migrer vos abonnes. Chaque version de package geree de seconde generation nait en beta, la promotion est irreversible, et seuls les packages ayant passe la security review peuvent etre pousses dans les orgs abonnees.

A quoi ressemble le workflow de release AppExchange de bout en bout ?

1. Creer la version. Toute version 2GP est creee en beta. Une beta s'installe pour tester et ne peut jamais figurer sur un listing.
2. La valider. Installez-la dans une scratch org propre et dans une sandbox qui ressemble a un vrai abonne, puis lancez la suite de tests complete.
3. La promouvoir. sf package version promote transforme la beta en version released.
4. Mettre a jour le listing. Dans la Partner Console, sous Publishing puis Listings, utilisez Link Your Solution pour rattacher la version released, puis publiez.
5. Faire migrer les abonnes. Installation en libre service, version recommandee ou push upgrade.

La plupart des equipes ISV font deja ces cinq etapes quelque part. Ce qui manque, en general, c'est l'ordre, la barriere entre chaque etape et un registre fiable indiquant quelle org abonnee tourne sur quelle version.

Comment rendre une version de package upgradable ?

L'upgradabilite depend de l'ancestry, pas du numero de version que vous avez saisi. Chaque nouvelle version 2GP declare un ancetre dans sfdx-project.json, et Salesforce recommande ancestorVersion: HIGHEST pour que l'ancetre suive automatiquement votre plus haute version promue. Les clients existants ne peuvent pas migrer vers une version creee sans ancetre declare : un seul build sans ancetre produit donc une version que personne ne peut atteindre.

• Gardez une ancestry lineaire, sauf raison deliberee de bifurquer.
• Traitez le drapeau skip-ancestor-check comme un incident, pas comme une methode de travail.
• Utilisez les numeros de version comme vos abonnes les lisent : majeur pour un changement profond, mineur pour de nouvelles fonctionnalites, patch pour de petites corrections.

Que faut-il verifier avant de promouvoir ?

La promotion est la barriere la plus importante, parce qu'elle ne se defait pas.

• Une version beta doit satisfaire l'exigence de 75% de couverture de code avant de pouvoir etre promue.
• Un numero de version donne ne peut etre promu et publie qu'une seule fois, et vous ne pouvez pas le repasser en beta.
• L'ancetre doit etre correct, car la version released est le palier par lequel vos abonnes montent.

La promotion doit partir de votre pipeline, derriere une approbation humaine explicite, jamais du portable qui se trouve authentifie sur le Dev Hub. Le droit de promouvoir est lui-meme un controle : accordez-le via un permission set plutot qu'a tous ceux qui ont acces a la CLI.

Quand la security review intervient-elle vraiment ?

Pour un premier listing, la security review se place entre la validation et la publication, et c'est le poste le plus long du calendrier. Pour les mises a jour, la logique change. Une review complete n'est pas requise pour chaque patch ou chaque upgrade, et ce qui commande la publication, c'est le statut du listing. S'il affiche Ready to List, vous pouvez publier le listing mis a jour sans soumettre la nouvelle version. S'il affiche Security Review Required, vous ne publiez pas tant que cette version n'est pas validee.

Salesforce mene aussi des re-reviews periodiques, et une version porteuse de changements significatifs les declenche plus facilement. Budgetez donc du temps de review pour les releases qui touchent l'architecture, l'authentification ou les appels sortants, et arretez d'en prevoir pour les corrections de routine. Verifiez les regles en vigueur dans le guide ISVforce sur la mise a jour d'un listing avant de batir un trimestre dessus.

Comment faire monter les abonnes de version sans en bloquer aucun ?

Trois leviers, du moins au plus intrusif :

1. Installation en libre service. L'abonne installe depuis le listing ou une URL d'installation quand il est pret. Convergence la plus lente, risque le plus faible.
2. Version recommandee. En 2GP vous pouvez marquer une version comme recommandee : l'abonne voit alors l'option Upgrade to Recommended Version sur sa page Installed Packages. Une incitation, pas une decision prise a sa place.
3. Push upgrade. Vous mettez a jour les orgs abonnees vous-meme, en choisissant quelles orgs, quelle version et quand. Seuls les packages ayant passe la security review AppExchange y sont eligibles, la fonction est activee par le Salesforce Partner Support, et en 2GP le push upgrade se pilote depuis la CLI ou l'API SOAP, pas depuis l'interface.

Un deploiement progressif qui tient : vos propres orgs d'abord, puis les orgs partenaires et sandbox, puis une petite cohorte de clients volontaires, puis tous les autres par lots planifies hors heures de pointe. Laissez entre deux cohortes le temps qu'un vrai ticket de support arrive, ce qui represente en general une journee ouvree complete et non une heure.

Ce qui derape en pratique

• Il n'y a pas de retour arriere. Un abonne qui a upgrade ne peut pas redescendre. Votre plan de rollback est une version patch en avant : gardez la branche de release dans un etat permettant de la sortir le jour meme.
• Le listing s'ecarte du package. Une version promue jamais reliee au listing signifie que vos nouveaux prospects installent le build du trimestre dernier pendant que votre documentation decrit celui de ce trimestre.
• L'ancestry casse en silence. Rien n'echoue au build. Cela echoue des mois plus tard, dans une org client, sous la forme d'un upgrade qui refuse de demarrer.
• Les sandboxes des abonnes sont sautees. Indiquez dans vos release notes de mettre a jour une sandbox Full ou Partial d'abord. C'est la seule repetition generale dont disposent les deux parties.

Qu'automatiser en premier ?

1. La creation de version avec couverture de code calculee a chaque merge sur la branche de release.
2. L'installation et le smoke test automatiques de cette beta dans une scratch org propre.
3. La promotion derriere exactement une approbation humaine, avec verification de l'ancetre en premier.
4. Un registre des versions : quelle org abonnee tourne sur quelle version, mis a jour apres chaque push.

Ce quatrieme point est celui que les equipes repoussent et regrettent, car la qualite du support en depend plus que de tout le reste. Serpent couvre les workflows 1GP, 2GP et managed package, la resolution des dependances entre packages et la gestion des versions a travers les orgs abonnees sur toutes les formules, y compris la formule gratuite. D'autres playbooks de packaging sont dans notre bibliotheque SF Guides.

FAQ

Puis-je annuler la promotion d'une version de package ?

Non. Un numero de version ne peut etre promu et publie qu'une fois, et le changement est irreversible. Traitez la promotion comme une decision de release, pas comme une etape de build.

Faut-il une nouvelle security review a chaque release ?

Non. Une review complete n'est pas exigee pour chaque patch ou upgrade. La publication depend du statut de votre listing, et Salesforce peut demander une re-review periodique si une version change significativement.

Pourquoi mon client ne peut-il pas passer a ma derniere version ?

Le plus souvent, l'ancestry. Les clients existants ne peuvent pas migrer vers une version creee sans ancetre declare : verifiez donc l'ancetre avant tout le reste.

Quelle difference entre version recommandee et push upgrade ?

Une version recommandee affiche a l'abonne l'option Upgrade to Recommended Version et lui laisse le calendrier. Un push upgrade deplace son org a votre place, selon votre calendrier.

Une beta compte-t-elle comme une release ?

Non. Toute version 2GP commence en beta et ne s'installe que pour tester. Elle devient une release au moment ou vous la promouvez.