Gestion des versions sur les orgs abonnes: pourquoi les ISV la font encore a la main

La gestion des versions sur les orgs abonnes consiste a savoir, a tout moment, quelle version de votre package gere chaque client execute, et a pouvoir l'en faire sortir. Salesforce fournit aux ISV la matiere premiere: 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 a la main, dans un tableur, et le paient en heures de support.

Que recouvre reellement la gestion des versions sur les orgs abonnes?

Ce sont trois taches distinctes repliees dans une seule expression:

• Inventaire. Quelle version est installee dans quel org abonne, maintenant.
• Dispersion. Combien de versions distinctes sont en production simultanement, et a quelle distance la plus ancienne se trouve de la version courante.
• Deplacement. Votre capacite a faire passer un ensemble identifie d'orgs de la version A a la version B au moment que vous choisissez.

La plupart des equipes ont une reponse approximative a la premiere, aucune reponse a la deuxieme, et un processus manuel pour la troisieme.

Pourquoi la matrice de versions determine-t-elle le cout du support ISV?

Parce que chaque ticket s'ouvre sur une question a laquelle le ticket ne repond pas. Avant de reproduire un bug, quelqu'un doit etablir sur quel build se trouve le client, si le correctif est deja livre, et si le comportement constitue un defaut ou un ecart de version. Repetez cela cent fois par mois et ce n'est plus une gene, 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 etre evalue contre les six avant que vous puissiez promettre quoi que ce soit. Reduire cette dispersion est l'action la plus rentable d'une fonction support ISV, et c'est precisement pour cela que les push upgrades existent.

Comment savoir quelle version execute un abonne?

Quatre chemins, chacun avec sa limite:

• La License Management App. Installee dans votre partner business org, la LMA cree un lead et un enregistrement de licence a chaque installation, et porte des objets Package et Package Version pour chaque package 1GP ou 2GP publie sur l'AppExchange. C'est votre referentiel. Commencez la.
• La Subscriber Support Console. Precise, mais elle exige que le client vous accorde d'abord l'acces, ce qui en fait un outil par incident et non un inventaire.
• Demander a l'administrateur. Setup, Installed Packages, lire le numero de version. Acceptable une fois. Inutilisable sur deux cents orgs.
• Tooling API. A savoir: InstalledSubscriberPackageVersion est deprecie et voue a etre supprime. N'y adossez pas une couche de reporting.

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

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

Pas par paresse. Les donnees vivent dans trois systemes qui ne se parlent pas: les licences dans le partner business org, les versions de package dans le Dev Hub, et l'historique reel des releases dans Git et votre pipeline. Les joindre est un petit projet d'integration interne qui ne gagne jamais un sprint face au travail client. Cela reste donc un tableur, quelqu'un le met a jour apres chaque release, et au troisieme trimestre plus personne ne s'y fie vraiment.

A quoi ressemble une gestion des versions automatisee?

1. Traitez la LMA comme la source de verite sur qui detient quoi, et synchronisez-la selon un calendrier plutot que de la consulter au coup par coup.
2. Joignez les enregistrements de licence a votre historique de releases, pour que chaque ligne abonne porte la version installee, sa date de sortie et ce qui a change depuis.
3. Faites de la dispersion un chiffre suivi chaque semaine: nombre de versions en production, et age 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 a l'ingenierie.
5. Regroupez les orgs en vagues de mise a 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 ingenieur support.

Notez ce qui n'y figure pas: quoi que ce soit que vos clients doivent apprendre. C'est un probleme de reporting interne deguise en probleme de packaging.

Quand pousser une mise a niveau plutot que la demander?

Les push upgrades font passer les orgs abonnes a une nouvelle version sans que le client installe quoi que ce soit, et vous choisissez quels orgs, quelle version et quand. Les contraintes a integrer au plan:

• Seuls les packages ayant passe la security review AppExchange sont eligibles.
• Pour le 2GP, il n'y a pas d'interface graphique. Les push upgrades passent par la CLI ou l'API SOAP.
• Echelonnez. 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'eviter les periodes de cloture financiere 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 definit une fenetre d'expiration, apres laquelle Salesforce cesse de reessayer.

Un push est un deploiement dans l'org de production de quelqu'un d'autre. Traitez-le comme tel: meme revue, meme plan de retour arriere, meme change record.

Ou 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 a org adossee a Git, et elles le font bien. La livraison de packages pour ISV est historiquement la moitie la plus mince de la categorie. C'est cette moitie autour de laquelle nous avons construit Serpent: workflows natifs 1GP, 2GP et managed package, resolution des dependances entre packages, gestion des versions sur les orgs abonnes et workflows de release AppExchange, sur tous les plans, y compris le plan gratuit.

FAQ

Puis-je voir par defaut la version de chaque abonne au meme endroit?

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

Les push upgrades sont-ils surs pour les versions majeures?

Ils comportent plus de risque que les patchs, car une version majeure peut modifier un comportement dont depend un abonne. Testez d'abord dans vos orgs et dans les sandbox clients, puis deployez 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 reellement staffer, annoncez-le aux clients, et mesurez la dispersion par rapport a lui.

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

Oui. Ses objets Package et Package Version portent les details de chaque package et version 1GP ou 2GP publie sur l'AppExchange.

Puis-je encore interroger InstalledSubscriberPackageVersion?

Il existe depuis la version 41.0 de l'API, mais Salesforce l'a marque deprecie et prevoit sa suppression. N'en faites pas une dependance.

La gestion des versions sur les orgs abonnes est ingrate, invisible pour les clients, et decide en silence de ce que coute votre support. Elle merite un pipeline, pas un tableur.