Ein Salesforce Managed Package Planen? Entscheide Zuerst die Permanenten 2GP-Weichen

Kurze Antwort: Wenn dein Team ein Salesforce Managed Package auf Second-Generation Packaging (2GP) bauen will, lassen sich drei deiner frühesten Entscheidungen nie mehr rückgängig machen: dein Namespace, die als global offengelegten Teile deines Codes und deine Versions-Ancestry. Triff sie bewusst, bevor du echten Code schreibst, und der Rest des Lebenszyklus verläuft weit ruhiger.

Wir arbeiten mit Produktteams und ISVs, die uns erreichen, nachdem der schwierige Teil bereits feststeht. Das Muster ist immer gleich: Die Plattform dokumentiert diese Regeln, betont aber nicht, welche permanent sind. Dieser Leitfaden trennt die Entscheidungen, die du vorab richtig treffen musst, von den operativen Fallen, von denen du dich später erholen kannst.

Welche 2GP-Entscheidungen kannst du nie zurücknehmen?

Drei, und es sind genau die, bei denen Teams sich beeilen.

Dein Namespace ist für immer

Der an ein Package gebundene Namespace kann später nicht geändert oder geteilt werden. Er wird zum Präfix jeder Komponente für die gesamte Lebensdauer des Produkts. Besteht die Chance, dass du eines Tages einen Teil deines Portfolios abspaltest oder verkaufst, lege nicht alles unter einen gemeinsamen Namespace, denn du kannst es danach nicht entwirren. Gib dieser Entscheidung eine echte Prüfung, keine schnelle Vermutung in einer Scratch Org.

Was global ist, bleibt global

Sobald du ein Member als global in einem Managed Package auslieferst, ist es dauerhaft Teil deiner öffentlichen API und du kannst es nicht entfernen. Bevor du zu global greifst, prüfe, ob namespaceAccessible das Problem löst: Packages, die einen Namespace teilen, können öffentlichen Apex darüber teilen, ohne eine global Surface offenzulegen, die du jahrelang unterstützen musst.

Ancestry entscheidet, wer aktualisieren kann

Jede veröffentlichte Version deklariert einen Ancestor, und installierte Orgs bewegen sich nur entlang dieser Kette nach oben. Wähle den Ancestor achtlos und du lässt Kunden auf einem Ast zurück, der deine neueste Version nicht erreichen kann. Früh verstanden ist derselbe Mechanismus ein Geschenk: Läuft eine Version schief, baust du die nächste aus einer früheren, gesunden Version.

Die operativen Fallen, die einen Release-Tag lahmlegen

Sie kosten dich Zeit, aber anders als die drei oben kannst du dich von ihnen erholen.

• Beta gegen veröffentlicht. Jede erstellte Version beginnt als Beta, die nicht in Produktion installiert und keine Subscriber erreicht, bis jemand sie promotet. Ein übersprungener Promote-Schritt ist der häufigste Grund, dass ein "fertiges" Package nicht installiert.
• Das Coverage-Gate greift bei der Promotion. Die Anforderung von 75 Prozent Testabdeckung wird bei der Promotion für die Release geprüft, nicht beim Erstellen einer Beta. Teams, die Tests aufschieben, treffen die Wand genau am geplanten Liefertag.
• Dev-Hub-Limits setzen sich täglich zurück. Version-Creates und Scratch Orgs sind je Edition pro Tag gedeckelt. Plane Release-Tage um die Limits herum, damit du mitten im Ansturm nicht bis morgen feststeckst.
• Dein Dev Hub ist ein Single Point of Failure. Packages gehören der Dev-Hub-Org. Lege sie auf eine Org, die eine verantwortliche Person kontrolliert, kein abgelaufenes Trial, denn Eigentumsübertragungen sind langsam und mühsam.

Wie du diese Entscheidungen bewusst triffst

Die Teams, die Packages reibungslos ausliefern, haben nicht mehr Glück, sie sind früher dran. Sie klären die permanenten Weichen, Namespace, Global-Surface und Ancestry-Strategie, in einer kurzen Design-Session, bevor Code existiert, und behandeln Promote als echtes Gate mit bereits vorhandenen Tests. Willst du ein zweites Paar Augen auf diese Entscheidungen, bevor sie sich verhärten, ist das genau die Art Review, die das Salesforce-Team von Tekunda mit Produktteams macht.

FAQ

Was sollten wir festlegen, bevor wir unser erstes 2GP-Package erstellen?

Den Namespace, welchen Apex du als global offenlegst, und deine Ancestry-Strategie. Alle drei sind faktisch permanent, also einigt euch, bevor ihr Produktionscode schreibt.

Wie vermeiden wir, Kunden auf einer alten Package-Version festzusetzen?

Plane deine Ancestry bewusst. Jede Version deklariert ihren Ancestor und Subscriber aktualisieren entlang dieser Kette, daher kann ein falscher Ancestor Kunden daran hindern, deine neueste Version zu erreichen.

Warum verweigert unser fertiges Package die Installation in Produktion?

Es ist fast immer noch eine Beta. Betas installieren nur in Scratch- und Sandbox-Orgs. Promote die Version auf veröffentlicht, bevor sie in Produktion installieren oder an Subscriber pushen kann.

Wann erzwingt Salesforce 75 Prozent Testabdeckung für ein Package?

Bei der Promotion. Du kannst Betas mit geringer Abdeckung bauen, aber das Gate blockiert das Promoten einer Version für die Release, bis die Abdeckung erreicht ist, also baue Tests von Anfang an ein.