Le workflow de release AppExchange : de la version de package à l'upgrade des abonnés

Réponse courte : une release AppExchange se déroule en cinq étapes : créer une version bêta du package, la valider, la promouvoir en version released, la relier à votre listing, puis faire migrer vos abonnés. Chaque version de package gérée de seconde génération naît en bêta, la promotion est irréversible, et seuls les packages ayant passé la security review peuvent être poussés dans les orgs abonnées.

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

1. Créer la version. Toute version 2GP est créée en bêta. Une bêta 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 à un vrai abonné, puis lancez la suite de tests complète.
3. La promouvoir. sf package version promote transforme la bêta en version released.
4. Mettre à 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 abonnés. Installation en libre service, version recommandée ou push upgrade.

La plupart des équipes ISV font déjà ces cinq étapes quelque part. Ce qui manque, en général, c'est l'ordre, la barrière entre chaque étape et un registre fiable indiquant quelle org abonnée tourne sur quelle version.

Comment rendre une version de package upgradable ?

L'upgradabilité dépend de l'ancestry, pas du numéro de version que vous avez saisi. Chaque nouvelle version 2GP déclare un ancêtre dans sfdx-project.json, et Salesforce recommande ancestorVersion: HIGHEST pour que l'ancêtre suive automatiquement votre plus haute version promue. Les clients existants ne peuvent pas migrer vers une version créée sans ancêtre déclaré : un seul build sans ancêtre produit donc une version que personne ne peut atteindre.

• Gardez une ancestry linéaire, sauf raison délibérée de bifurquer.
• Traitez le drapeau skip-ancestor-check comme un incident, pas comme une méthode de travail.
• Utilisez les numéros de version comme vos abonnés les lisent : majeur pour un changement profond, mineur pour de nouvelles fonctionnalités, patch pour de petites corrections.

Que faut-il vérifier avant de promouvoir ?

La promotion est la barrière la plus importante, parce qu'elle ne se défait pas.

• Une version bêta doit satisfaire l'exigence de 75% de couverture de code avant de pouvoir être promue.
• Un numéro de version donné ne peut être promu et publié qu'une seule fois, et vous ne pouvez pas le repasser en bêta.
• L'ancêtre doit être correct, car la version released est le palier par lequel vos abonnés montent.

La promotion doit partir de votre pipeline, derrière une approbation humaine explicite, jamais du portable qui se trouve authentifié sur le Dev Hub. Le droit de promouvoir est lui-même un contrôle : accordez-le via un permission set plutôt qu'à tous ceux qui ont accès à 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 à jour, la logique change. Une review complète 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 à jour sans soumettre la nouvelle version. S'il affiche Security Review Required, vous ne publiez pas tant que cette version n'est pas validée.

Salesforce mène aussi des re-reviews périodiques, et une version porteuse de changements significatifs les déclenche plus facilement. Budgétez donc du temps de review pour les releases qui touchent l'architecture, l'authentification ou les appels sortants, et arrêtez d'en prévoir pour les corrections de routine. Vérifiez les règles en vigueur dans le guide ISVforce sur la mise à jour d'un listing avant de bâtir un trimestre dessus.

Comment faire monter les abonnés de version sans en bloquer aucun ?

Trois leviers, du moins au plus intrusif :

1. Installation en libre service. L'abonné installe depuis le listing ou une URL d'installation quand il est prêt. Convergence la plus lente, risque le plus faible.
2. Version recommandée. En 2GP vous pouvez marquer une version comme recommandée : l'abonné voit alors l'option Upgrade to Recommended Version sur sa page Installed Packages. Une incitation, pas une décision prise à sa place.
3. Push upgrade. Vous mettez à jour les orgs abonnées vous-même, en choisissant quelles orgs, quelle version et quand. Seuls les packages ayant passé la security review AppExchange y sont éligibles, la fonction est activée 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 déploiement 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 planifiés hors heures de pointe. Laissez entre deux cohortes le temps qu'un vrai ticket de support arrive, ce qui représente en général une journée ouvrée complète et non une heure.

Ce qui dérape en pratique

• Il n'y a pas de retour arrière. Un abonné qui a upgrade ne peut pas redescendre. Votre plan de rollback est une version patch en avant : gardez la branche de release dans un état permettant de la sortir le jour même.
• Le listing s'écarte du package. Une version promue jamais reliée au listing signifie que vos nouveaux prospects installent le build du trimestre dernier pendant que votre documentation décrit celui de ce trimestre.
• L'ancestry casse en silence. Rien n'échoue au build. Cela échoue des mois plus tard, dans une org client, sous la forme d'un upgrade qui refuse de démarrer.
• Les sandboxes des abonnés sont sautées. Indiquez dans vos release notes de mettre à jour une sandbox Full ou Partial d'abord. C'est la seule répétition générale dont disposent les deux parties.

Qu'automatiser en premier ?

1. La création de version avec couverture de code calculée à chaque merge sur la branche de release.
2. L'installation et le smoke test automatiques de cette bêta dans une scratch org propre.
3. La promotion derrière exactement une approbation humaine, avec vérification de l'ancêtre en premier.
4. Un registre des versions : quelle org abonnée tourne sur quelle version, mis à jour après chaque push.

Ce quatrième point est celui que les équipes repoussent et regrettent, car la qualité du support en dépend plus que de tout le reste. Serpent couvre les workflows 1GP, 2GP et managed package, la résolution des dépendances entre packages et la gestion des versions à travers les orgs abonnées sur toutes les formules, y compris la formule gratuite. D'autres playbooks de packaging sont dans notre bibliothèque SF Guides.

FAQ

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

Non. Un numéro de version ne peut être promu et publié qu'une fois, et le changement est irréversible. Traitez la promotion comme une décision de release, pas comme une étape de build.

Faut-il une nouvelle security review à chaque release ?

Non. Une review complète n'est pas exigée pour chaque patch ou upgrade. La publication dépend du statut de votre listing, et Salesforce peut demander une re-review périodique si une version change significativement.

Pourquoi mon client ne peut-il pas passer à ma dernière version ?

Le plus souvent, l'ancestry. Les clients existants ne peuvent pas migrer vers une version créée sans ancêtre déclaré : vérifiez donc l'ancêtre avant tout le reste.

Quelle différence entre version recommandée et push upgrade ?

Une version recommandée affiche à l'abonné l'option Upgrade to Recommended Version et lui laisse le calendrier. Un push upgrade déplace son org à votre place, selon votre calendrier.

Une bêta compte-t-elle comme une release ?

Non. Toute version 2GP commence en bêta et ne s'installe que pour tester. Elle devient une release au moment où vous la promouvez.