Een Salesforce Managed Package Plannen? Beslis Eerst de Permanente 2GP-keuzes

Kort antwoord: Staat je team op het punt een Salesforce managed package te bouwen op second-generation packaging (2GP), dan zijn drie van je vroegste keuzes nooit meer terug te draaien: je namespace, de delen van je code die je als global blootstelt, en je version ancestry. Beslis die bewust voordat je echte code schrijft, en de rest van de levenscyclus verloopt veel rustiger.

Wij werken met productteams en ISV's die ons bereiken nadat het moeilijke deel al vastligt. Het patroon is altijd hetzelfde: het platform documenteert deze regels, maar benadrukt niet welke permanent zijn. Deze gids scheidt de beslissingen die je vooraf goed moet krijgen van de operationele valkuilen waarvan je later kunt herstellen.

Welke 2GP-beslissingen kun je nooit terugnemen?

Drie, en het zijn juist die waar teams zich in haasten.

Je namespace is voor altijd

De namespace die je aan een package koppelt, kan later niet worden gewijzigd of gesplitst. Hij wordt het voorvoegsel op elk component voor de hele levensduur van het product. Bestaat er enige kans dat je ooit een deel van je portfolio afsplitst of verkoopt, zet dan niet alles onder een gedeelde namespace, want je kunt het achteraf niet ontwarren. Geef deze beslissing een echte review, geen snelle gok in een scratch org.

Alles wat global is, blijft global

Zodra je een member als global uitlevert in een managed package, is die permanent deel van je publieke API en kun je hem niet verwijderen. Controleer voordat je naar global grijpt of namespaceAccessible het probleem oplost: packages die een namespace delen, kunnen publieke Apex daardoor delen zonder een global surface bloot te stellen die je jarenlang moet ondersteunen.

Ancestry bepaalt wie kan upgraden

Elke uitgebrachte versie declareert een ancestor, en geinstalleerde orgs bewegen alleen omhoog langs die keten. Kies de ancestor onzorgvuldig en je laat klanten achter op een tak die je nieuwste release niet kan bereiken. Vroeg begrepen is hetzelfde mechanisme een cadeau: gaat een versie mis, dan bouw je je volgende release vanaf een eerdere, gezonde versie.

De operationele valkuilen die een release-dag stilleggen

Deze kosten je tijd, maar anders dan de drie hierboven kun je ervan herstellen.

• Beta versus released. Elke versie die je maakt begint als beta die niet in productie installeert of subscribers bereikt totdat iemand hem promoot. Een overgeslagen promote-stap is de meest voorkomende reden dat een "afgerond" package niet installeert.
• De coverage-gate valt bij promotie. De eis van 75 procent testdekking wordt gecontroleerd bij het promoten voor release, niet bij het maken van een beta. Teams die testen uitstellen, raken de muur precies op de dag dat ze wilden shippen.
• Dev Hub-limieten resetten dagelijks. Version creates en scratch orgs zijn per dag gemaximeerd per editie. Plan release-dagen rond de limieten zodat je middenin de drukte niet tot morgen vastzit.
• Je Dev Hub is een single point of failure. Packages zijn eigendom van de Dev Hub-org. Zet die op een org die een verantwoordelijk persoon beheert, geen verlopen trial, want eigendomsoverdrachten zijn traag en pijnlijk.

Hoe je deze beslissingen bewust maakt

De teams die packages soepel shippen hebben niet meer geluk, ze zijn eerder. Ze regelen de permanente keuzes, namespace, global surface en ancestry-strategie, in een korte ontwerpsessie voordat er code bestaat, en behandelen promote als een echte gate met tests al aanwezig. Wil je een tweede paar ogen op die beslissingen voordat ze verharden, dan is dat precies het soort review dat het Salesforce-team van Tekunda met productteams doet.

FAQ

Wat moeten we vastleggen voordat we ons eerste 2GP-package maken?

De namespace, welke Apex je als global blootstelt, en je ancestry-strategie. Alle drie zijn feitelijk permanent, dus spreek ze af voordat je productiecode schrijft.

Hoe voorkomen we dat klanten op een oude packageversie stranden?

Plan je ancestry bewust. Elke versie declareert zijn ancestor en subscribers upgraden langs die keten, dus een verkeerde ancestor kan klanten blokkeren om je nieuwste release te bereiken.

Waarom weigert ons afgeronde package te installeren in productie?

Het is bijna altijd nog een beta. Beta's installeren alleen in scratch- en sandbox-orgs. Promoot de versie naar released voordat hij in productie kan installeren of naar subscribers pusht.

Wanneer dwingt Salesforce 75 procent testdekking af voor een package?

Bij promotie. Je kunt beta's bouwen met lage dekking, maar de gate blokkeert het promoten van een versie voor release totdat de dekking is gehaald, dus bouw tests er vanaf het begin in.