Gestion des versions sur les orgs abonnés: pourquoi les ISV la font encore à la main

La gestion des versions sur les orgs abonnés consiste à savoir, à tout moment, quelle version de votre package géré chaque client exécute, et à pouvoir l'en faire sortir. Salesforce fournit aux ISV la matière première: la License Management App, la Subscriber Support Console, les push upgrades. Ce qu'il ne fournit pas, c'est un inventaire vivant. La plupart des ISV le tiennent donc à la main, dans un tableur, et le paient en heures de support.

Que recouvre réellement la gestion des versions sur les orgs abonnés?

Ce sont trois tâches distinctes repliées dans une seule expression:

• Inventaire. Quelle version est installée dans quel org abonné, maintenant.
• Dispersion. Combien de versions distinctes sont en production simultanément, et à quelle distance la plus ancienne se trouve de la version courante.
• Déplacement. Votre capacité à faire passer un ensemble identifié d'orgs de la version A à la version B au moment que vous choisissez.

La plupart des équipes ont une réponse approximative à la première, aucune réponse à la deuxième, et un processus manuel pour la troisième.

Pourquoi la matrice de versions détermine-t-elle le coût du support ISV?

Parce que chaque ticket s'ouvre sur une question à laquelle le ticket ne répond pas. Avant de reproduire un bug, quelqu'un doit établir sur quel build se trouve le client, si le correctif est déjà livré, et si le comportement constitue un défaut ou un écart de version. Répétez cela cent fois par mois et ce n'est plus une gêne, c'est un poste.

C'est la dispersion qui s'accumule. Deux versions en production, c'est une branche. Six, c'est une matrice de support, et chaque correctif entrant doit être évalué contre les six avant que vous puissiez promettre quoi que ce soit. Réduire cette dispersion est l'action la plus rentable d'une fonction support ISV, et c'est précisément pour cela que les push upgrades existent.

Comment savoir quelle version exécute un abonné?

Quatre chemins, chacun avec sa limite:

• La License Management App. Installée dans votre partner business org, la LMA crée un lead et un enregistrement de licence à chaque installation, et porte des objets Package et Package Version pour chaque package 1GP ou 2GP publié sur l'AppExchange. C'est votre référentiel. Commencez là.
• La Subscriber Support Console. Précise, mais elle exige que le client vous accorde d'abord l'accès, ce qui en fait un outil par incident et non un inventaire.
• Demander à l'administrateur. Setup, Installed Packages, lire le numéro de version. Acceptable une fois. Inutilisable sur deux cents orgs.
• Tooling API. À savoir: InstalledSubscriberPackageVersion est déprécié et voué à être supprimé. N'y adossez pas une couche de reporting.

Aucun de ces chemins n'est un tableau de bord. C'est là le manque, et c'est pour cela que le tableur existe.

Pourquoi les ISV font-ils encore cela à la main?

Pas par paresse. Les données vivent dans trois systèmes qui ne se parlent pas: les licences dans le partner business org, les versions de package dans le Dev Hub, et l'historique réel des releases dans Git et votre pipeline. Les joindre est un petit projet d'intégration interne qui ne gagne jamais un sprint face au travail client. Cela reste donc un tableur, quelqu'un le met à jour après chaque release, et au troisième trimestre plus personne ne s'y fie vraiment.

À quoi ressemble une gestion des versions automatisée?

1. Traitez la LMA comme la source de vérité sur qui détient quoi, et synchronisez-la selon un calendrier plutôt que de la consulter au coup par coup.
2. Joignez les enregistrements de licence à votre historique de releases, pour que chaque ligne abonné porte la version installée, sa date de sortie et ce qui a changé depuis.
3. Faites de la dispersion un chiffre suivi chaque semaine: nombre de versions en production, et âge de la plus ancienne.
4. Fixez un plancher de support, la version la plus ancienne sur laquelle vous corrigez encore, et rendez-le visible au support et pas seulement à l'ingénierie.
5. Regroupez les orgs en vagues de mise à niveau: vos propres orgs, puis les sandbox clients, puis les clients proches, puis le reste.
6. Faites de "quelle version" un champ rempli automatiquement sur le ticket, et non une question que doit poser un ingénieur support.

Notez ce qui n'y figure pas: quoi que ce soit que vos clients doivent apprendre. C'est un problème de reporting interne déguisé en problème de packaging.

Quand pousser une mise à niveau plutôt que la demander?

Les push upgrades font passer les orgs abonnés à une nouvelle version sans que le client installe quoi que ce soit, et vous choisissez quels orgs, quelle version et quand. Les contraintes à intégrer au plan:

• Seuls les packages ayant passé la security review AppExchange sont éligibles.
• Pour le 2GP, il n'y a pas d'interface graphique. Les push upgrades passent par la CLI ou l'API SOAP.
• Échelonnez. Les bonnes pratiques de Salesforce recommandent de tester dans vos propres orgs, puis dans les sandbox clients, puis sur un petit lot de production avant le reste, et d'éviter les périodes de clôture financière et les semaines qui suivent une release majeure de Salesforce.
• Depuis Summer '26, vous pouvez borner la tentative. Un enregistrement PushUpgradeCustomizationRepository dans votre packaging org 1GP ou votre Dev Hub 2GP définit une fenêtre d'expiration, après laquelle Salesforce cesse de réessayer.

Un push est un déploiement dans l'org de production de quelqu'un d'autre. Traitez-le comme tel: même revue, même plan de retour arrière, même change record.

Où en est l'outillage?

La plupart des plateformes de Salesforce DevOps, Copado, Gearset, AutoRABIT, Flosum et les autres, sont construites autour de la livraison org à org adossée à Git, et elles le font bien. La livraison de packages pour ISV est historiquement la moitié la plus mince de la catégorie. C'est cette moitié autour de laquelle nous avons construit Serpent: workflows natifs 1GP, 2GP et managed package, résolution des dépendances entre packages, gestion des versions sur les orgs abonnés et workflows de release AppExchange, sur tous les plans, y compris le plan gratuit.

FAQ

Puis-je voir par défaut la version de chaque abonné au même endroit?

Non. La LMA de votre partner business org contient les enregistrements de licence et de version, mais en faire un inventaire vivant joint à votre historique de releases est un travail qui vous revient.

Les push upgrades sont-ils sûrs pour les versions majeures?

Ils comportent plus de risque que les patchs, car une version majeure peut modifier un comportement dont dépend un abonné. Testez d'abord dans vos orgs et dans les sandbox clients, puis déployez par petits lots.

Combien de versions en production un ISV doit-il supporter?

Salesforce ne fixe aucun nombre. Choisissez un plancher de support que vous pouvez réellement staffer, annoncez-le aux clients, et mesurez la dispersion par rapport à lui.

La LMA couvre-t-elle à la fois le 1GP et le 2GP?

Oui. Ses objets Package et Package Version portent les détails de chaque package et version 1GP ou 2GP publié sur l'AppExchange.

Puis-je encore interroger InstalledSubscriberPackageVersion?

Il existe depuis la version 41.0 de l'API, mais Salesforce l'a marqué déprécié et prévoit sa suppression. N'en faites pas une dépendance.

La gestion des versions sur les orgs abonnés est ingrate, invisible pour les clients, et décide en silence de ce que coûte votre support. Elle mérite un pipeline, pas un tableur.