Paketubergreifende Abhangigkeiten in Salesforce: Modellierung, Installationsreihenfolge und sichere Upgrades

Kurze Antwort: Paketubergreifende Abhangigkeitsauflosung ist der Weg, auf dem Salesforce entscheidet, welche Pakete in welchen Versionen bereits vorhanden sein mussen, bevor ein weiteres installiert oder aktualisiert werden kann. Deklariert wird sie im Array dependencies in sfdx-project.json, in Installationsreihenfolge. Stimmen Reihenfolge und Mindestversionen, sind Subscriber-Upgrades langweilig. Stimmen sie nicht, landet eine Org auf einer Version, die sie nicht mehr verlassen kann.

Was ist eine Paketabhangigkeit genau?

Eine Abhangigkeit besteht, sobald Metadaten in einem Paket Metadaten in einem anderen referenzieren: ein Flow auf einem Managed Object, eine Apex-Klasse, die eine Basisklasse erweitert, ein Field Set auf einem fremden Feld. Die praktische Folge ist eine Vorbedingung. Das referenzierte Paket muss zuerst installiert sein, in einer Version mindestens so neu wie die, gegen die Sie gebaut haben, sonst schlagt die Installation fehl.

Wie deklariert man eine Abhangigkeit zwischen Paketen?

Im Package-Directory-Eintrag von sfdx-project.json, in einer von zwei Formen:

• Ein Alias, der die Version bereits tragt: { "package": "[email protected]" }
• Paket und Version getrennt: { "package": "MyPackage", "versionNumber": "1.0.0.RELEASED" }

Drei Regeln wiegen schwerer als die Syntax.

• Die Reihenfolge ist die Installationsreihenfolge. Hat ein Paket mehrere Abhangigkeiten, wird die Liste als Reihenfolge gelesen, in der sie installiert werden mussen.
• Zirkulare Abhangigkeiten werden nicht unterstutzt. A hangt von B ab, wahrend B von A abhangt, ist kein zu losendes Ratsel, sondern ein zu zerlegender Entwurf.
• Mehrstufige Ketten sind moglich. C kann von B abhangen und B von A. Mit "calculateTransitiveDependencies": true deklarieren Sie nur direkte Abhangigkeiten, die indirekten werden berechnet. Ohne das mussen Sie jede Ebene selbst auffuhren, dauerhaft.

Welche Pakettypen durfen von welchen abhangen?

Das schrankt die Architektur ein, prufen Sie es also, bevor Sie sie zeichnen.

• Managed 2GP darf von Managed 2GP und von Unlocked Packages abhangen.
• Managed 2GP darf nicht von Managed 1GP abhangen. Salesforce blockiert die Installation von Managed-2GP-Paketen in Managed-1GP-Packaging-Orgs. Wo ein Produkt es wirklich braucht, fuhrt der Weg uber einen Fall beim Salesforce Partner Support fur eine individuelle Ausnahme, nicht uber einen Trick im Build-Skript.
• Managed 1GP darf von Managed 1GP, Managed 2GP und Unlocked Packages abhangen.
• Unlocked Packages, die von Managed Packages abhangen, sind nicht empfohlen, und nichts Unterstutztes hangt von einem Unmanaged Package ab.

Ein 1GP-Basispaket unter einer 2GP-Erweiterung ist der mit Abstand haufigste Abhangigkeitsentwurf, der spat wieder aufgelost werden muss, und dann ist er teuer. Lesen Sie die unterstutzten Kombinationen vor dem ersten Build, nicht danach.

Wie modelliert man Pakete, damit der Graph flach bleibt?

1. Nur eine Richtung. Basis, dann Feature, dann Rand. Wollen zwei Pakete einander referenzieren, gehoren die gemeinsamen Metadaten in ein drittes Paket darunter.
2. Klein und modular schlagt ein grosses Paket. Erstellung und Installation sind schneller, und Sie stossen seltener an Limits.
3. Teuer ist die Tiefe, nicht die Breite. Jede zusatzliche Ebene vervielfacht die Release-Koordination: Eine Anderung ganz unten verlangt eine neue Version auf jeder Ebene daruber, bevor ein Subscriber irgendetwas davon sieht.
4. Pinnen Sie bewusst. Eine festgepinnte Buildnummer ist reproduzierbar und langweilig. Ein Schlusselwort wie RELEASED folgt Ihrer zuletzt veroffentlichten Version, was in der Entwicklung praktisch und im Release-Build eine Uberraschung ist.

Was ist die richtige Installationsreihenfolge in einer Subscriber-Org?

1. Installieren oder aktualisieren Sie zuerst das unterste Paket im Graphen, das selbst keine Abhangigkeiten hat.
2. Arbeiten Sie sich Ebene fur Ebene nach oben, damit jedes Paket seine Vorbedingung bei der Installation erfullt vorfindet.
3. Installieren Sie das oberste Paket, also das, was Ihr Kunde tatsachlich gekauft hat, zuletzt.
4. Prufen statt annehmen. Eine SOQL-Abfrage auf SubscriberPackageVersion sagt Ihnen, was in dieser Org installiert ist und in welcher Version, und das schlagt einen Blick auf die Seite Installed Packages mit Hoffnung im Gepack.

Wenn Sie diese Reihenfolge fur Ihr eigenes Produkt nicht aus dem Kopf nennen konnen, kann Ihr Support das in dem Moment auch nicht, in dem ein Kunde feststeckt.

Wie andert man eine Abhangigkeit, ohne Subscriber hangen zu lassen?

• Die neue Version muss ein direkter Nachfahre der installierten sein. Subscriber konnen die Linie nicht uberspringen, ein Paket mit gebrochener Ancestry ist also ein Paket, das manche Orgs nicht aktualisieren konnen.
• Beta-Pakete sind nicht upgradefahig. Ein Subscriber mit einer Beta muss deinstallieren, bevor er eine released Version installiert, und in Produktion ist das ein Gesprach uber Datenverlust. Lassen Sie nie eine Beta in einer Kunden-Org zuruck.
• Entfernte Metadaten werden beim Upgrade als veraltet markiert oder geloscht. Eine Komponente von einem Paket in ein anderes zu verschieben ist hier eine Entfernung und dort eine Erganzung, die Release-Reihenfolge zwischen beiden ist also das ganze Risiko.
• Heben Sie Mindestversionen schrittweise an. Die geforderte Version eines Basispakets um mehrere Releases anzuheben, erzwingt eine Upgrade-Kette bei Subscribern, die keine geplant hatten.

Die Reihenfolge, die funktioniert, wenn sich ein Basispaket andert: Basisversion veroffentlichen, Subscriber uber eine empfohlene Version oder ein Push Upgrade darauf bringen, und erst dann das abhangige Paket veroffentlichen, das sie voraussetzt. Wer die beiden vertauscht, erzeugt ein Upgrade, das an einer Vorbedingung scheitert, in einer Org, die Sie weder sehen noch von Ihrer Seite reparieren konnen.

Was sollte man automatisieren?

1. Den Graphen bei jedem Pipeline-Lauf aus sfdx-project.json aufbauen und den Build bei einem Zyklus scheitern lassen.
2. Die gesamte Kette jedes Mal in der deklarierten Reihenfolge in eine saubere Scratch Org installieren, damit Reihenfolgefehler beim Build auffallen und nicht in einer Kunden-Org.
3. Installierte Versionen je Subscriber-Org festhalten, damit der Support die Frage beantworten kann, bevor er sie dem Kunden stellt.

Serpent beherrscht paketubergreifende Abhangigkeitsauflosung, 1GP-, 2GP- und Managed-Package-Workflows sowie Versionsmanagement uber Subscriber-Orgs in jedem Tarif, auch im kostenlosen. Weitere Packaging-Playbooks finden Sie in unserer SF-Guides-Bibliothek.

FAQ

Darf ein Managed-2GP-Paket von einem Managed-1GP-Paket abhangen?

Standardmassig nicht. Salesforce blockiert die Kombination, und eine individuelle Ausnahme wird uber einen Fall beim Salesforce Partner Support beantragt.

Muss ich transitive Abhangigkeiten auflisten?

Nur wenn Sie wollen. Mit "calculateTransitiveDependencies": true deklarieren Sie direkte Abhangigkeiten, die indirekten werden berechnet. Ohne das muss jede Ebene von Hand in der Liste stehen.

Was passiert, wenn zwei Pakete voneinander abhangen?

Nichts Gutes, denn zirkulare Abhangigkeiten werden nicht unterstutzt. Ziehen Sie die gemeinsamen Metadaten in ein tieferes Paket, von dem beide abhangen.

Welches Paket aktualisiere ich in einer Subscriber-Org zuerst?

Das unterste im Graphen. Abhangigkeiten kommen vor den Paketen, die sie brauchen, in derselben Reihenfolge wie bei der Installation.

Warum scheitert das Upgrade meines Kunden mit einem Abhangigkeitsfehler?

Meist an einer Mindestversion. Das installierte Basispaket ist alter als das, was Ihr neues Release verlangt: Basispaket zuerst aktualisieren, dann erneut versuchen.