Versiebeheer over subscriber-orgs, en waarom ISV's het nog handmatig doen

Versiebeheer over subscriber-orgs betekent dat je op elk moment weet welke versie van je managed package elke klant draait, en die klant ook kunt verplaatsen. Salesforce geeft ISV's het ruwe materiaal daarvoor: de License Management App, de Subscriber Support Console, push-upgrades. Wat je niet krijgt, is een actuele inventaris. Dus houden de meeste ISV's die met de hand bij, in een spreadsheet, en betalen ze ervoor in supporturen.

Wat betekent versiebeheer over subscriber-orgs precies?

Het zijn drie losse taken die in een term zijn samengevouwen:

• Inventaris. Welke versie staat op dit moment in welke subscriber-org.
• Spreiding. Hoeveel verschillende versies tegelijk live zijn, en hoe ver de oudste is afgedreven van de huidige.
• Beweging. Je vermogen om een afgebakende set orgs op een zelfgekozen moment van versie A naar versie B te brengen.

De meeste teams hebben een globaal antwoord op de eerste, geen antwoord op de tweede, en een handmatig proces voor de derde.

Waarom bepaalt de versiematrix de supportkosten van een ISV?

Omdat elk ticket begint met een vraag die het ticket zelf niet beantwoordt. Voordat iemand een bug reproduceert, moet eerst vaststaan op welke build de klant zit, of de fix al is uitgeleverd, en of het gedrag een defect is of een versieverschil. Doe dat honderd keer per maand en het is geen irritatie meer, maar formatie.

De spreiding is wat zich opstapelt. Twee live versies is een branch. Zes is een supportmatrix, en elke binnenkomende fix moet tegen alle zes worden afgewogen voordat je iets kunt beloven. Die spreiding terugbrengen is het meest renderende wat een ISV-supportafdeling kan doen, en het is precies waarom push-upgrades bestaan.

Hoe kom je erachter welke versie een subscriber draait?

Vier routes, elk met een addertje:

• De License Management App. Geinstalleerd in je partner business org maakt de LMA bij elke installatie een lead- en licentierecord aan, met Package- en Package Version-objecten voor elk 1GP- of 2GP-pakket dat je op AppExchange hebt staan. Dit is je administratie. Begin hier.
• De Subscriber Support Console. Nauwkeurig, maar de klant moet je eerst login-toegang verlenen. Daarmee is het een tool per incident, geen inventaris.
• Vraag het de beheerder. Setup, Installed Packages, versienummer aflezen. Prima een keer. Onbruikbaar bij tweehonderd orgs.
• Tooling API. Goed om te weten dat InstalledSubscriberPackageVersion deprecated is en wordt uitgefaseerd. Bouw er dus geen rapportagelaag op.

Merk op dat geen van deze routes een dashboard is. Dat is het gat, en daarom bestaat de spreadsheet.

Waarom doen ISV's dit nog steeds handmatig?

Niet uit luiheid. De data zit in drie systemen die niet met elkaar praten: licenties in de partner business org, pakketversies in de Dev Hub, en de echte releasehistorie in Git en je pipeline. Die koppelen is een klein intern integratieproject dat het nooit wint van klantgericht werk. Dus blijft het een spreadsheet, werkt iemand die na elke release bij, en vertrouwt in het derde kwartaal niemand hem meer helemaal.

Hoe ziet geautomatiseerd versiebeheer eruit?

1. Behandel de LMA als bron van waarheid voor wie wat heeft, en synchroniseer op schema in plaats van ad hoc te kijken.
2. Koppel licentierecords aan je releasehistorie, zodat elke subscriber-regel de geinstalleerde versie draagt, de releasedatum, en wat er sindsdien is veranderd.
3. Maak van de spreiding een getal dat je wekelijks volgt: aantal live versies, en de leeftijd van de oudste.
4. Stel een ondergrens voor support vast, de oudste versie waarop je nog bugs fixt, en maak die zichtbaar voor support en niet alleen voor engineering.
5. Groepeer orgs in upgradegolven: je eigen orgs, dan klantsandboxen, dan welwillende klanten, dan de rest.
6. Maak van "welke versie" een automatisch gevuld veld op het ticket, geen vraag die een supportengineer moet stellen.

Let op wat er niet in die lijst staat: iets wat je klanten moeten leren. Dit is een intern rapportageprobleem vermomd als een packagingprobleem.

Wanneer push je een upgrade in plaats van erom te vragen?

Push-upgrades brengen subscriber-orgs naar een nieuwe versie zonder dat de klant iets installeert, en jij kiest welke orgs, welke versie en wanneer. De randvoorwaarden waar je omheen moet plannen:

• Alleen pakketten die de AppExchange security review hebben doorstaan komen in aanmerking.
• Voor 2GP is er geen klikpad. Push-upgrades lopen via de CLI of de SOAP API.
• Doe het gefaseerd. De eigen best practices van Salesforce zijn: eerst je eigen orgs, dan klantsandboxen, dan een kleine productiebatch, en pas daarna de rest, en vermijd financiele afsluitperiodes en de weken direct na een grote Salesforce-release.
• Sinds Summer '26 kun je de poging begrenzen. Een PushUpgradeCustomizationRepository-record in je 1GP packaging org of 2GP Dev Hub stelt een vervalvenster in, waarna Salesforce stopt met opnieuw proberen.

Een push is een deployment in de productieomgeving van iemand anders. Behandel het ook zo: zelfde review, zelfde rollbackplan, zelfde change record.

Hoe staat het met de tooling?

De meeste Salesforce DevOps-platforms, Copado, Gearset, AutoRABIT, Flosum en de rest, zijn gebouwd rond org-naar-org en Git-gedreven levering, en dat doen ze goed. Pakketlevering voor ISV's is historisch de dunnere helft van de categorie. Dat is de helft waar we Serpent omheen hebben gebouwd: native 1GP-, 2GP- en managed-package-workflows, dependency-resolutie tussen pakketten, versiebeheer over subscriber-orgs en AppExchange-releaseworkflows, op elk plan inclusief het gratis plan.

FAQ

Kan ik standaard alle pakketversies van subscribers op een plek zien?

Nee. De LMA in je partner business org bevat licentie- en pakketversierecords, maar daar een live inventaris van maken die gekoppeld is aan je releasehistorie is werk dat je zelf moet doen.

Zijn push-upgrades veilig voor major versies?

Ze dragen meer risico dan patches, omdat een major versie gedrag kan wijzigen waar een subscriber van afhankelijk is. Test eerst in je eigen orgs en in klantsandboxen, en rol daarna uit in kleine batches.

Hoeveel live versies moet een ISV ondersteunen?

Salesforce noemt geen aantal. Kies een ondergrens die je daadwerkelijk kunt bemannen, communiceer die naar klanten, en meet de spreiding daartegen af.

Dekt de LMA zowel 1GP als 2GP?

Ja. De Package- en Package Version-objecten bevatten details voor elk 1GP- of 2GP-pakket en elke versie die je op AppExchange hebt staan.

Kan ik InstalledSubscriberPackageVersion nog gebruiken?

Het bestaat vanaf API-versie 41.0, maar Salesforce heeft het als deprecated gemarkeerd en gaat het verwijderen. Maak er geen afhankelijkheid van.

Versiebeheer over subscriber-orgs is oninteressant, onzichtbaar voor klanten, en bepaalt stilletjes wat je supportafdeling kost. Het verdient een pipeline, geen spreadsheet.