Versionsverwaltung ueber Subscriber-Orgs, und warum ISVs sie noch von Hand machen

Versionsverwaltung ueber Subscriber-Orgs bedeutet, jederzeit zu wissen, welche Version deines Managed Package jeder Kunde ausfuehrt, und ihn davon wegbewegen zu koennen. Salesforce liefert ISVs das Rohmaterial dafuer: die License Management App, die Subscriber Support Console, Push Upgrades. Was nicht mitgeliefert wird, ist ein laufendes Inventar. Also fuehren die meisten ISVs eines von Hand, in einer Tabelle, und bezahlen dafuer in Supportstunden.

Was bedeutet Versionsverwaltung ueber Subscriber-Orgs genau?

Es sind drei getrennte Aufgaben, die in einem Begriff zusammenfallen:

• Inventar. Welche Version ist gerade in welcher Subscriber-Org installiert.
• Streuung. Wie viele verschiedene Versionen gleichzeitig produktiv laufen, und wie weit die aelteste von der aktuellen abgedriftet ist.
• Bewegung. Deine Faehigkeit, eine benannte Menge von Orgs zu einem selbst gewaehlten Zeitpunkt von Version A auf Version B zu bringen.

Die meisten Teams haben eine grobe Antwort auf die erste, keine Antwort auf die zweite und einen manuellen Prozess fuer die dritte.

Warum entscheidet die Versionsmatrix ueber die Supportkosten eines ISV?

Weil jedes Ticket mit einer Frage beginnt, die das Ticket selbst nicht beantwortet. Bevor jemand einen Bug reproduziert, muss geklaert werden, auf welchem Build der Kunde sitzt, ob der Fix bereits ausgeliefert ist und ob das Verhalten ein Defekt oder eine Versionsluecke ist. Mach das hundertmal im Monat, und es ist keine Stoerung mehr, sondern eine Stelle.

Die Streuung ist das, was sich aufsummiert. Zwei produktive Versionen sind ein Branch. Sechs sind eine Supportmatrix, und jeder eingehende Fix muss gegen alle sechs bewertet werden, bevor du irgendetwas zusagen kannst. Diese Streuung zu verkleinern ist der wirksamste Hebel einer ISV-Supportfunktion, und genau dafuer gibt es Push Upgrades.

Wie findest du heraus, welche Version ein Subscriber ausfuehrt?

Vier Wege, jeder mit einem Haken:

• Die License Management App. In deiner Partner Business Org installiert, legt die LMA bei jeder Installation einen Lead und einen Lizenzdatensatz an und fuehrt Package- und Package-Version-Objekte fuer jedes 1GP- oder 2GP-Paket, das du auf der AppExchange gelistet hast. Das ist dein System of Record. Fang hier an.
• Die Subscriber Support Console. Genau, aber der Kunde muss dir zuerst Login-Zugriff gewaehren, womit sie ein Werkzeug pro Vorfall ist und kein Inventar.
• Den Admin fragen. Setup, Installed Packages, Versionsnummer ablesen. Einmal in Ordnung. Bei zweihundert Orgs unbrauchbar.
• Tooling API. Wichtig zu wissen: InstalledSubscriberPackageVersion ist veraltet und zur Entfernung vorgesehen. Baue darauf keine Reporting-Schicht.

Keiner dieser Wege ist ein Dashboard. Das ist die Luecke, und deshalb existiert die Tabelle.

Warum machen ISVs das immer noch von Hand?

Nicht aus Bequemlichkeit. Die Daten liegen in drei Systemen, die nicht miteinander reden: Lizenzen in der Partner Business Org, Paketversionen im Dev Hub und die tatsaechliche Release-Historie in Git und deiner Pipeline. Sie zu verbinden ist ein kleines internes Integrationsprojekt, das gegen kundennahe Arbeit nie einen Sprint gewinnt. Also bleibt es eine Tabelle, jemand pflegt sie nach jedem Release, und im dritten Quartal traut ihr niemand mehr ganz.

Wie sieht automatisierte Versionsverwaltung aus?

1. Behandle die LMA als Quelle der Wahrheit dafuer, wer was hat, und synchronisiere sie nach Zeitplan statt sie ad hoc zu lesen.
2. Verbinde Lizenzdatensaetze mit deiner Release-Historie, sodass jede Subscriber-Zeile die installierte Version, ihr Release-Datum und die Aenderungen seitdem traegt.
3. Mache aus der Streuung eine Zahl, die du woechentlich beobachtest: Anzahl produktiver Versionen und Alter der aeltesten.
4. Lege eine Supportuntergrenze fest, die aelteste Version, auf der du noch Fehler behebst, und mache sie fuer den Support sichtbar, nicht nur fuer die Entwicklung.
5. Gruppiere Orgs in Upgrade-Wellen: eigene Orgs, dann Kundensandboxen, dann wohlgesinnte Kunden, dann der Rest.
6. Mache "welche Version" zu einem automatisch befuellten Feld am Ticket, nicht zu einer Frage, die ein Supportmitarbeiter stellen muss.

Beachte, was nicht auf der Liste steht: irgendetwas, das deine Kunden lernen muessen. Das ist ein internes Reporting-Problem, verkleidet als Packaging-Problem.

Wann solltest du ein Upgrade pushen statt darum zu bitten?

Push Upgrades bringen Subscriber-Orgs auf eine neue Version, ohne dass der Kunde etwas installiert, und du waehlst welche Orgs, welche Version und wann. Die Randbedingungen, um die herum geplant werden muss:

• Nur Pakete, die die AppExchange Security Review bestanden haben, sind zugelassen.
• Fuer 2GP gibt es keinen Klickweg. Push Upgrades laufen ueber die CLI oder die SOAP API.
• Staffle sie. Die Best Practices von Salesforce empfehlen, zuerst in eigenen Orgs zu testen, dann in Kundensandboxen, dann in einem kleinen Produktionsstapel, und erst danach im Rest, sowie Jahresabschlusszeiten und die Wochen direkt nach einem grossen Salesforce-Release zu meiden.
• Seit Summer '26 laesst sich der Versuch begrenzen. Ein PushUpgradeCustomizationRepository-Datensatz in deiner 1GP Packaging Org oder deinem 2GP Dev Hub setzt ein Ablauffenster, nach dem Salesforce keine weiteren Versuche unternimmt.

Ein Push ist ein Deployment in die Produktivorg eines anderen. Behandle ihn so: gleiche Pruefung, gleicher Rollback-Plan, gleicher Change Record.

Wie steht es um die Werkzeuge?

Die meisten Salesforce-DevOps-Plattformen, Copado, Gearset, AutoRABIT, Flosum und die uebrigen, sind um Org-zu-Org- und Git-gestuetzte Auslieferung gebaut, und das koennen sie gut. Paketauslieferung fuer ISVs war historisch die duennere Haelfte der Kategorie. Um diese Haelfte haben wir Serpent gebaut: native 1GP-, 2GP- und Managed-Package-Workflows, paketuebergreifende Abhaengigkeitsaufloesung, Versionsverwaltung ueber Subscriber-Orgs und AppExchange-Release-Workflows, in jedem Plan einschliesslich des kostenlosen.

FAQ

Sehe ich standardmaessig die Paketversion jedes Subscribers an einem Ort?

Nein. Die LMA in deiner Partner Business Org enthaelt Lizenz- und Paketversionsdatensaetze, aber daraus ein lebendes, mit der Release-Historie verknuepftes Inventar zu machen, ist Arbeit, die bei dir liegt.

Sind Push Upgrades bei Major-Versionen sicher?

Sie tragen mehr Risiko als Patches, weil eine Major-Version Verhalten aendern kann, auf das ein Subscriber angewiesen ist. Teste zuerst in eigenen Orgs und in Kundensandboxen und rolle dann in kleinen Stapeln aus.

Wie viele produktive Versionen sollte ein ISV unterstuetzen?

Salesforce nennt keine Zahl. Waehle eine Supportuntergrenze, die du personell wirklich tragen kannst, kommuniziere sie an Kunden und miss die Streuung daran.

Deckt die LMA sowohl 1GP als auch 2GP ab?

Ja. Ihre Package- und Package-Version-Objekte tragen Details zu jedem 1GP- oder 2GP-Paket und jeder Version, die du auf der AppExchange gelistet hast.

Kann ich InstalledSubscriberPackageVersion noch abfragen?

Es existiert ab API-Version 41.0, aber Salesforce hat es als veraltet markiert und zur Entfernung vorgesehen. Mache es nicht zur Abhaengigkeit.

Versionsverwaltung ueber Subscriber-Orgs ist unspektakulaer, fuer Kunden unsichtbar, und entscheidet still darueber, was dein Support kostet. Sie verdient eine Pipeline, keine Tabelle.