Andrew Hanna

Aktualisiert vor 4 Monaten

Managed vs. Unmanaged Packages in Salesforce

Einleitung

Als Salesforce Engineer oder Consultant ist die Entscheidung zwischen Managed und Unmanaged Packages strategisch wichtig. Sie kann Ihre Workflows und den Anwendungslebenszyklus auf Salesforce erheblich beeinflussen. Dieser Leitfaden betrachtet beide Package-Typen genauer und zeigt Anwendungsfälle, Vorteile und wichtige Überlegungen, damit Sie auf Basis Ihrer konkreten Anforderungen eine fundierte Wahl treffen können.

Was sind Managed und Unmanaged Packages?

Managed Packages werden typischerweise von Salesforce-Partnern erstellt und über Salesforce AppExchange bereitgestellt. Sie enthalten einen Namespace, der sie vollständig von Ihrer Org und anderen Packages isoliert. Dadurch werden Namenskonflikte zwischen Salesforce-Orgs vermieden, allerdings bringt das eigene Einschränkungen mit sich.

Unmanaged Packages werden häufig genutzt, um Open-Source-Projekte oder Templates zu verteilen, die Entwickler anpassen können. Sie enthalten keinen Namespace und sind dadurch vollständig editierbar, aber auch anfälliger für Namenskonflikte. Unmanaged Packages eignen sich gut, um Anpassungen und Entwicklung in Ihrer Org zu versionieren, während alles offen bleibt und Sie weiterhin Metadaten und Code referenzieren können, die bereits in der Ziel-Org existieren.

Bei Tekunda haben wir die Verwaltungs- und Release-Prozesse für Managed und Unmanaged Packages mit Tekunda Serpent vereinfacht. Unser Tool macht die Verwaltung von Metadaten und Packages mühelos, damit Sie sich auf Innovation statt auf administrative Aufgaben konzentrieren können. Bereit, Ihre Salesforce-Entwicklung zu straffen?

Kostenlos starten - keine Kreditkarte und gehören Sie zu den Ersten, die ihren Workflow mit Tekunda Serpent transformieren!

Detaillierter Vergleich

Konfiguration und Anpassung

Managed Packages
- Anwendungsfälle: Ideal für Anwendungen wie Integrationen mit Drittanbietern oder die Erweiterung von Salesforce mit einem eigenständigen Package. Beispiele sind das Erstellen oder Installieren eines vorgefertigten Marketing-Automation-Tools oder einer Customer-Service-Anwendung.
- Vorteile: Sie sind gesperrt. Kernkomponenten können also nicht bearbeitet werden, was Integrität und Support durch den Anbieter sicherstellt.
- Überlegungen: Begrenzte Anpassbarkeit passt möglicherweise nicht zu allen geschäftsspezifischen Anforderungen.
Unmanaged Packages
- Anwendungsfälle: Am besten geeignet, wenn eine stark zugeschnittene Lösung benötigt wird, etwa eine individuelle Anwendung für Ihre Geschäftsprozesse oder Templates, die für verschiedene Kundensetups angepasst werden können.
- Vorteile: Voller Zugriff auf den Code erlaubt Entwicklern, jeden Aspekt des Packages exakt an ihre Anforderungen anzupassen.
- Überlegungen: Erfordert tiefere Salesforce-Entwicklungskenntnis und kann zu längeren Deployment-Zeiten führen.

Support und Wartung

Managed Packages
- Sie bieten Anbieter-Support, regelmäßige Updates und Kompatibilitätszusagen für neue Salesforce-Releases, wodurch der administrative Aufwand für Kunden oder Nutzer sinkt.
Unmanaged Packages
- Wartung und Updates liegen in der Verantwortung des Kunden oder Nutzers. Das kann die Arbeitslast des IT-Teams erhöhen, macht sie aber passend für interne Projekte und Beratungsprojekte.

Deployment und Updates

Managed Packages
- Sie lassen sich schnell deployen, da sie vorkonfiguriert sind. Updates werden vom Anbieter betreut und nahtlos in die Kunden- oder Nutzerumgebung ausgerollt.
Unmanaged Packages
- Sie erfordern sorgfältige Integration und Tests, besonders während Updates, damit sie nicht mit bestehenden Anpassungen kollidieren.

Das richtige Package für Ihre Anforderungen wählen

Beachten Sie bei der Entscheidung zwischen Managed und Unmanaged Packages:

Projektkomplexität und Anpassungsbedarf: Wenn Ihr Projekt umfangreiche Anpassung erfordert, kann unmanaged die bessere Wahl sein. Für eigenständige Projekte können Managed Packages Zeit und Aufwand sparen.
Verfügbarkeit von Ressourcen: Haben Sie qualifizierte Mitarbeitende, um mögliche Komplexität rund um Unmanaged Packages zu verwalten?
Budgetgrenzen: Managed Packages wirken anfangs möglicherweise teurer, aber betrachten Sie die Gesamtkosten inklusive Wartung und künftiger Upgrades.
Time to Market: Managed Packages ermöglichen schnelleres Deployment, was für zeitkritische Projekte entscheidend sein kann.

CI/CD-Auswirkungen für Managed und Unmanaged Packages

Continuous Integration und Continuous Deployment CI/CD sind zentrale Bestandteile moderner Softwareentwicklung, besonders in dynamischen Umgebungen wie Salesforce. Die Entscheidung zwischen Managed und Unmanaged Packages kann erhebliche Auswirkungen auf Ihre CI/CD-Strategien haben.

CI/CD bei der Entwicklung von Managed Packages

Managed Packages werden typischerweise von Entwicklern erstellt, die ihre Anwendungen auf Salesforce AppExchange vertreiben möchten, oft mit Blick auf Kommerzialisierung. Wichtige CI/CD-Überlegungen sind:

Versionskontrolle und Release-Management: Managed Packages müssen den Upgrade- und Release-Management-Prozessen von Salesforce folgen. Diese sind stärker strukturiert, um Kompatibilität und Support sicherzustellen. Entwickler müssen Versionierung präzise verwalten, da Package-Versionen nach dem Release unveränderlich sind.
Namespace Prefix: Jedes Managed Package besitzt einen Namespace Prefix, der es über alle Salesforce-Orgs hinweg eindeutig identifiziert. Dieser Namespace muss im Source Control sorgfältig verwaltet werden, um Konsistenz zwischen Entwicklungs- und Produktionsumgebungen sicherzustellen.
Beta-Tests und Patch-Versionen: CI/CD-Pipelines für Managed Packages beinhalten häufig das Erstellen von Beta-Versionen für Tests und Patch-Versionen zur Behebung von Problemen nach dem Release. Automatisierung dieser Prozesse hilft, die Stabilität des Packages zu erhalten.
Lizenzmanagement: Die Integration von Lizenzframeworks ist für Managed Packages essenziell, besonders wenn sie kommerziell sind. Ihr CI/CD-Prozess muss möglicherweise Schritte zur Aktualisierung von Lizenzmechanismen als Teil der Deployment-Pipeline enthalten.

CI/CD bei der Entwicklung von Unmanaged Packages

Unmanaged Packages sind flexibler und werden häufig für individuelle Projekte innerhalb einer bestimmten Org oder zur Verteilung von Open-Source-Projekten verwendet, bei denen der Entwickler keine proprietäre Kontrolle behält. CI/CD-Aspekte umfassen:

Volle Kontrolle über Code: Entwickler haben volle Kontrolle über den Quellcode. Dadurch lassen sich CI/CD-Praktiken wie automatisierte Tests, Style-Checks und Codequalitätsprüfungen ohne Einschränkungen leichter umsetzen.
Flexibilität bei Updates: Unmanaged Packages erlauben Entwicklern, Updates und Änderungen jederzeit direkt anzuwenden und agile Entwicklungspraktiken zu unterstützen. Automatisierungstools können das Deployment neuer Features und Fixes straffen.
Kein Namespace-Management: Das Fehlen eines Namespace in Unmanaged Packages vereinfacht einige Aspekte von Versionskontrolle und Source-Code-Management und reduziert den Aufwand für diese Elemente in CI/CD-Pipelines.
Individuelle Deployment-Skripte: Entwickler können eigene Skripte erstellen und CI/CD-Tools wie Jenkins, CircleCI oder GitHub Actions nutzen, um Build- und Deployment-Prozesse passend zu den Anforderungen ihrer Organisation zu automatisieren.

Die richtige Strategie wählen

Die Entscheidung zwischen der Entwicklung eines Managed oder Unmanaged Package hängt oft vom geplanten Anwendungsfall und der Vertriebsstrategie ab:

Kommerzielle Verteilung: Wenn Sie Ihre Anwendung auf AppExchange verkaufen möchten, ist ein Managed Package erforderlich. Ihre CI/CD-Pipelines sollten strenge Tests und Compliance-Prüfungen unterstützen, um Salesforce-Standards zu erfüllen.
Interne Nutzung oder Open Source: Für Packages, die intern oder als Open Source ohne kommerzielle Absicht genutzt werden, bieten Unmanaged Packages mehr Flexibilität und lassen sich einfacher in personalisierte CI/CD-Workflows integrieren.
Komplexität bewerten: Berücksichtigen Sie die Komplexität Ihrer Salesforce-Umgebung. Eine einfache Umgebung kommt möglicherweise gut mit Managed Packages zurecht, während eine komplexe, stark angepasste Umgebung stärker von Unmanaged Packages profitieren kann.
Teamfähigkeiten bewerten: Stellen Sie sicher, dass Ihr Team die Fähigkeiten besitzt, den gewählten Package-Typ innerhalb von CI/CD-Pipelines zu verwalten. Unmanaged Packages erfordern robuste DevOps-Fähigkeiten, um ihre Flexibilität voll auszuschöpfen.
Langfristige Wartung berücksichtigen: Bewerten Sie, wie sich jede Option auf langfristige Wartung und Skalierbarkeit auswirkt. Managed Packages reduzieren den Wartungsaufwand zulasten der Flexibilität, während Unmanaged Packages Flexibilität bieten, aber kontinuierliche Wartung erfordern.

Fazit

Managed und Unmanaged Packages bieten Salesforce-Admins und Entwicklern jeweils eigene Vorteile. Wenn Sie organisatorische Anforderungen, verfügbare Ressourcen und langfristige Strategie sorgfältig bewerten, können Sie ein Package wählen, das Ihre aktuellen Anforderungen erfüllt und zugleich Wachstum und Entwicklung Ihrer Salesforce-Umgebung unterstützt.

Eine fundierte Entscheidung hilft Ihrem Team, Salesforce wirksamer zu nutzen, die Vorteile der Plattform auszuschöpfen und sie mit Ihren Geschäftszielen abzustimmen.

FAQ

Was unterscheidet Managed und Unmanaged Packages?

Ein Managed Package trägt einen Namespace, der es vom Rest der Org isoliert, und seine Kernkomponenten sind gesperrt. Ein Unmanaged Package hat keinen Namespace, bleibt nach der Installation voll editierbar und kann Namenskonflikte auslösen.

Kann man den Code eines Managed Package ändern?

Nein. Genau diese Sperre erlaubt dem Anbieter, Integrität zu garantieren und Upgrades sicher auszuliefern. Wenn Sie jeden Teil des Codes anpassen müssen, ist ein Unmanaged Package die richtige Wahl.

Welchen Package-Typ braucht man für AppExchange?

Ein Managed Package. Kommerzieller Vertrieb stützt sich auf den Namespace und auf den Release-Prozess von Salesforce, also richten Sie Ihre CI/CD auf strengere Tests und Compliance-Prüfungen aus.

Wann ist ein Unmanaged Package die bessere Wahl?

Für Arbeit, die in einer Org bleibt, für Beratungsergebnisse und für Vorlagen oder Open-Source-Projekte, die der Empfänger anpassen soll. Sie behalten die vollständige Source und damit auch die Wartung.