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

Kurze Antwort: Ein AppExchange-Release lauft in funf Schritten ab: eine Beta-Paketversion erstellen, sie validieren, sie zu released promoten, sie mit dem Listing verknupfen und danach die Subscriber umziehen. Jede Second-Generation-Managed-Package-Version wird als Beta geboren, das Promoten ist eine Einbahnstrasse, 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 lasst 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 vollstandige 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 verknupfen und veroffentlichen.
5. Subscriber umziehen. Selbstinstallation, empfohlene Version oder Push Upgrade.

Die meisten ISV-Teams machen alle funf Schritte irgendwo. Was in der Regel fehlt, ist die Reihenfolge, das Tor zwischen den Schritten und ein verlassliches Verzeichnis daruber, welche Subscriber-Org auf welcher Version lauft.

Wie macht man eine Paketversion upgradefahig?

Uber die Upgradefahigkeit entscheidet die Ancestry, nicht die Versionsnummer, die Sie getippt haben. Jede neue 2GP-Version deklariert einen Vorganger in sfdx-project.json, und Salesforce empfiehlt ancestorVersion: HIGHEST, damit der Vorganger automatisch Ihrer hochsten promoteten Version folgt. Bestehende Kunden konnen nicht auf eine Version aktualisieren, die ohne angegebenen Vorganger erstellt wurde. Ein einziger Build ohne Vorganger erzeugt also eine Version, die niemand erreicht.

• Halten Sie die Ancestry linear, ausser Sie verzweigen bewusst.
• Behandeln Sie das Flag skip-ancestor-check als Vorfall, nicht als Arbeitsweise.
• Verwenden Sie Versionsnummern so, wie Subscriber sie lesen: Major fur tiefgreifende Anderungen, Minor fur neue Funktionen, Patch fur kleine Korrekturen.

Was muss vor dem Promoten stimmen?

Das Promoten ist das wichtigste Tor, weil es sich nicht ruckgangig machen lasst.

• Eine Beta-Version muss die Anforderung von 75% Code Coverage erfullen, bevor sie promotet werden kann.
• Eine bestimmte Versionsnummer lasst sich nur einmal promoten und releasen, und Sie konnen sie nicht wieder auf Beta setzen.
• Der Vorganger muss korrekt sein, denn die released Version ist die Stufe, uber 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 uber 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 Veroffentlichung und ist der langste Posten im Kalender. Bei Updates sieht es anders aus. Fur jeden Patch oder jedes Upgrade ist keine vollstandige Review notig, und uber die Veroffentlichung entscheidet der Status des Listings. Steht dort Ready to List, konnen Sie das aktualisierte Listing veroffentlichen, ohne die neue Version einzureichen. Steht dort Security Review Required, konnen Sie erst veroffentlichen, wenn diese Version besteht.

Salesforce fuhrt ausserdem periodische Re-Reviews durch, und eine Version mit erheblichen Anderungen lost sie eher aus. Planen Sie Reviewzeit also fur Releases ein, die Architektur, Authentifizierung oder ausgehende Aufrufe verandern, und nicht mehr fur gewohnliche Fehlerkorrekturen. Prufen 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 hangen zu lassen?

Drei Hebel, vom schwachsten zum starksten Eingriff:

1. Selbstinstallation. Subscriber installieren aus dem Listing oder uber eine Installations-URL, wenn es ihnen passt. Langsamste Konvergenz, geringstes Risiko.
2. Empfohlene Version. In 2GP konnen Sie eine Version als empfohlen markieren. Subscriber sehen dann auf ihrer Seite Installed Packages die Option Upgrade to Recommended Version. Ein Anstoss, keine Entscheidung an ihrer Stelle.
3. Push Upgrade. Sie aktualisieren die Subscriber-Orgs selbst und wahlen, 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 lauft ein Push Upgrade uber die CLI oder die SOAP-API statt uber die Oberflache.

Ein stufenweiser Rollout, der halt: zuerst die eigenen Orgs, dann Partner- und Sandbox-Orgs, dann eine kleine Gruppe einverstandener Kunden, dann alle ubrigen in geplanten Batches ausserhalb 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 zuruck. Ihr Rollback ist eine Patchversion nach vorn, halten Sie den Release-Branch also so, dass Sie sie am selben Tag schneiden konnen.
• Listing und Paket driften auseinander. Eine promotete Version, die nie mit dem Listing verknupft wurde, bedeutet, dass neue Interessenten den Build des letzten Quartals installieren, wahrend Ihre Doku den aktuellen beschreibt.
• Die Ancestry bricht leise. Beim Build schlagt nichts fehl. Es schlagt Monate spater in einer Kunden-Org fehl, als Upgrade, das nicht startet.
• Subscriber-Sandboxes werden ubersprungen. 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 Prufung des Vorgangers.
4. Ein Versionsregister: welche Subscriber-Org auf welcher Version lauft, nach jedem Push aktualisiert.

Punkt vier schieben Teams auf und bereuen es, denn die Supportqualitat hangt starker daran als an allem anderen. Serpent deckt 1GP-, 2GP- und Managed-Package-Workflows, die Auflosung paketubergreifender Abhangigkeiten und das Versionsmanagement uber 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 ruckgangig machen?

Nein. Eine Versionsnummer lasst sich nur einmal promoten und releasen, und die Anderung ist endgultig. Behandeln Sie das Promoten daher als Release-Entscheidung, nicht als Build-Schritt.

Brauche ich fur jedes Release eine neue Security Review?

Nein. Eine vollstandige Review ist nicht fur jeden Patch oder jedes Upgrade notig. Die Veroffentlichung hangt vom Status Ihres Listings ab, und Salesforce kann bei erheblichen Anderungen weiterhin eine periodische Re-Review verlangen.

Warum kann mein Kunde nicht auf meine neueste Version aktualisieren?

Meist wegen der Ancestry. Bestehende Kunden konnen nicht auf eine Version aktualisieren, die ohne angegebenen Vorganger erstellt wurde. Prufen Sie also zuerst den Vorganger.

Was unterscheidet eine empfohlene Version von einem Push Upgrade?

Eine empfohlene Version zeigt dem Subscriber die Option Upgrade to Recommended Version und uberlasst ihm den Zeitpunkt. Ein Push Upgrade verschiebt seine Org fur ihn, nach Ihrem Zeitplan.

Zahlt 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.