Der AppExchange-Release-Workflow: von der Paketversion zum Subscriber-Upgrade

Kurze Antwort: Ein AppExchange-Release läuft in fünf Schritten ab: eine Beta-Paketversion erstellen, sie validieren, sie zu released promoten, sie mit dem Listing verknüpfen und danach die Subscriber umziehen. Jede Second-Generation-Managed-Package-Version wird als Beta geboren, das Promoten ist eine Einbahnstraße, und nur Pakete mit bestandener Security Review lassen sich in Subscriber-Orgs pushen.

Wie sieht der AppExchange-Release-Workflow von Anfang bis Ende aus?

1. Version erstellen. Jede 2GP-Version entsteht als Beta. Eine Beta lässt sich zum Testen installieren, aber niemals listen.
2. Validieren. In eine saubere Scratch Org und in eine Sandbox installieren, die einem echten Subscriber gleicht, danach die vollständige Testsuite laufen lassen.
3. Promoten. sf package version promote macht aus der Beta eine released Version.
4. Listing aktualisieren. In der Partner Console unter Publishing und Listings mit Link Your Solution die released Version verknüpfen und veröffentlichen.
5. Subscriber umziehen. Selbstinstallation, empfohlene Version oder Push Upgrade.

Die meisten ISV-Teams machen alle fünf Schritte irgendwo. Was in der Regel fehlt, ist die Reihenfolge, das Tor zwischen den Schritten und ein verlässliches Verzeichnis darüber, welche Subscriber-Org auf welcher Version läuft.

Wie macht man eine Paketversion upgradefähig?

Über die Upgradefähigkeit entscheidet die Ancestry, nicht die Versionsnummer, die Sie getippt haben. Jede neue 2GP-Version deklariert einen Vorgänger in sfdx-project.json, und Salesforce empfiehlt ancestorVersion: HIGHEST, damit der Vorgänger automatisch Ihrer höchsten promoteten Version folgt. Bestehende Kunden können nicht auf eine Version aktualisieren, die ohne angegebenen Vorgänger erstellt wurde. Ein einziger Build ohne Vorgänger erzeugt also eine Version, die niemand erreicht.

• Halten Sie die Ancestry linear, außer Sie verzweigen bewusst.
• Behandeln Sie das Flag skip-ancestor-check als Vorfall, nicht als Arbeitsweise.
• Verwenden Sie Versionsnummern so, wie Subscriber sie lesen: Major für tiefgreifende Änderungen, Minor für neue Funktionen, Patch für kleine Korrekturen.

Was muss vor dem Promoten stimmen?

Das Promoten ist das wichtigste Tor, weil es sich nicht rückgängig machen lässt.

• Eine Beta-Version muss die Anforderung von 75% Code Coverage erfüllen, bevor sie promotet werden kann.
• Eine bestimmte Versionsnummer lässt sich nur einmal promoten und releasen, und Sie können sie nicht wieder auf Beta setzen.
• Der Vorgänger muss korrekt sein, denn die released Version ist die Stufe, über die Ihre Subscriber aktualisieren.

Das Promoten sollte aus der Pipeline heraus laufen, hinter genau einer expliziten menschlichen Freigabe, und nie von dem Laptop, der gerade am Dev Hub angemeldet ist. Die Berechtigung zum Promoten ist selbst eine Kontrolle: Vergeben Sie sie über ein Permission Set statt an alle mit CLI-Zugang.

Wann findet die Security Review wirklich statt?

Beim ersten Listing liegt die Security Review zwischen Validierung und Veröffentlichung und ist der längste Posten im Kalender. Bei Updates sieht es anders aus. Für jeden Patch oder jedes Upgrade ist keine vollständige Review nötig, und über die Veröffentlichung entscheidet der Status des Listings. Steht dort Ready to List, können Sie das aktualisierte Listing veröffentlichen, ohne die neue Version einzureichen. Steht dort Security Review Required, können Sie erst veröffentlichen, wenn diese Version besteht.

Salesforce führt außerdem periodische Re-Reviews durch, und eine Version mit erheblichen Änderungen löst sie eher aus. Planen Sie Reviewzeit also für Releases ein, die Architektur, Authentifizierung oder ausgehende Aufrufe verändern, und nicht mehr für gewöhnliche Fehlerkorrekturen. Prüfen Sie die aktuellen Regeln im ISVforce-Leitfaden zur Aktualisierung eines Listings, bevor Sie ein Quartal darauf aufbauen.

Wie bringt man Subscriber auf eine neue Version, ohne jemanden hängen zu lassen?

Drei Hebel, vom schwächsten zum stärksten Eingriff:

1. Selbstinstallation. Subscriber installieren aus dem Listing oder über eine Installations-URL, wenn es ihnen passt. Langsamste Konvergenz, geringstes Risiko.
2. Empfohlene Version. In 2GP können Sie eine Version als empfohlen markieren. Subscriber sehen dann auf ihrer Seite Installed Packages die Option Upgrade to Recommended Version. Ein Anstoß, keine Entscheidung an ihrer Stelle.
3. Push Upgrade. Sie aktualisieren die Subscriber-Orgs selbst und wählen, welche Orgs, welche Version und wann. Nur Pakete mit bestandener AppExchange Security Review sind berechtigt, die Funktion wird vom Salesforce Partner Support freigeschaltet, und bei 2GP läuft ein Push Upgrade über die CLI oder die SOAP-API statt über die Oberfläche.

Ein stufenweiser Rollout, der hält: zuerst die eigenen Orgs, dann Partner- und Sandbox-Orgs, dann eine kleine Gruppe einverstandener Kunden, dann alle übrigen in geplanten Batches außerhalb der Spitzenzeiten. Lassen Sie zwischen den Gruppen so viel Zeit, dass ein echtes Supportticket eintreffen kann, und das ist in der Regel ein voller Arbeitstag, keine Stunde.

Was in der Praxis schiefgeht

• Es gibt kein Downgrade. Wer einmal aktualisiert hat, kommt nicht zurück. Ihr Rollback ist eine Patchversion nach vorn, halten Sie den Release-Branch also so, dass Sie sie am selben Tag schneiden können.
• Listing und Paket driften auseinander. Eine promotete Version, die nie mit dem Listing verknüpft wurde, bedeutet, dass neue Interessenten den Build des letzten Quartals installieren, während Ihre Doku den aktuellen beschreibt.
• Die Ancestry bricht leise. Beim Build schlägt nichts fehl. Es schlägt Monate später in einer Kunden-Org fehl, als Upgrade, das nicht startet.
• Subscriber-Sandboxes werden übersprungen. Schreiben Sie in die Release Notes, dass zuerst eine Full oder Partial Sandbox aktualisiert wird. Es ist die einzige Generalprobe, die beide Seiten bekommen.

Was sollte man zuerst automatisieren?

1. Versionserstellung mit berechneter Code Coverage bei jedem Merge auf den Release-Branch.
2. Automatische Installation und Smoke Test dieser Beta in einer sauberen Scratch Org.
3. Promoten hinter genau einer menschlichen Freigabe, mit vorheriger Prüfung des Vorgängers.
4. Ein Versionsregister: welche Subscriber-Org auf welcher Version läuft, nach jedem Push aktualisiert.

Punkt vier schieben Teams auf und bereuen es, denn die Supportqualität hängt stärker daran als an allem anderen. Serpent deckt 1GP-, 2GP- und Managed-Package-Workflows, die Auflösung paketübergreifender Abhängigkeiten und das Versionsmanagement über Subscriber-Orgs in jedem Tarif ab, auch im kostenlosen. Weitere Packaging-Playbooks finden Sie in unserer SF-Guides-Bibliothek.

FAQ

Kann ich das Promoten einer Paketversion rückgängig machen?

Nein. Eine Versionsnummer lässt sich nur einmal promoten und releasen, und die Änderung ist endgültig. Behandeln Sie das Promoten daher als Release-Entscheidung, nicht als Build-Schritt.

Brauche ich für jedes Release eine neue Security Review?

Nein. Eine vollständige Review ist nicht für jeden Patch oder jedes Upgrade nötig. Die Veröffentlichung hängt vom Status Ihres Listings ab, und Salesforce kann bei erheblichen Änderungen weiterhin eine periodische Re-Review verlangen.

Warum kann mein Kunde nicht auf meine neueste Version aktualisieren?

Meist wegen der Ancestry. Bestehende Kunden können nicht auf eine Version aktualisieren, die ohne angegebenen Vorgänger erstellt wurde. Prüfen Sie also zuerst den Vorgänger.

Was unterscheidet eine empfohlene Version von einem Push Upgrade?

Eine empfohlene Version zeigt dem Subscriber die Option Upgrade to Recommended Version und überlässt ihm den Zeitpunkt. Ein Push Upgrade verschiebt seine Org für ihn, nach Ihrem Zeitplan.

Zählt eine Beta als Release?

Nein. Jede 2GP-Version startet als Beta und ist nur zum Testen installierbar. Zum Release wird sie in dem Moment, in dem Sie sie promoten.