Von Change Sets zu Source Control

Als Salesforce Packaging erstmals einführte, wurde es nicht als Entwicklungsstrategie gesehen. Es war eine Möglichkeit, Komponenten für die Distribution zu bündeln, vor allem für ISVs mit AppExchange-Apps.

Die meisten internen Teams verließen sich weiterhin auf Change Sets, manuelle Deployments und Metadata Migration Tools. Das Konzept von modularer, versionierter Entwicklung war weit von der Realität entfernt.

Mit der Zeit veränderte sich jedoch das Salesforce-Ökosystem drastisch. Was als optionales Feature für eine kleine ISV-Gruppe begann, wurde zu einer zentralen Säule dafür, wie moderne Salesforce-Engineering-Teams Systeme bauen, deployen und warten.

Diese Entwicklung erklärt, warum Packaging nicht mehr nur “nice to have” ist; es ist die Grundlage skalierbarer Entwicklung.

Die frühen Tage: 1st generation managed packages

Bevor Salesforce DX existierte, fand Entwicklung direkt in Orgs statt. Teams bauten Features in Sandboxes, nutzten Change Sets oder ANT Scripts zum Deployen von Metadata und hatten oft keine einzige Source of Truth. First-generation managed packages (1GP) ermöglichten ISVs die Distribution von Anwendungen und den Schutz geistigen Eigentums, brachten aber große Einschränkungen mit.

Package-Erstellung und Versioning waren an die Packaging Org selbst gebunden. Code lebte in der Org, und Entwickler mussten Dependencies manuell verwalten. Es gab keine echte Verbindung zu Git oder CI/CD, wodurch Zusammenarbeit langsam und fehleranfällig war.

Für die meisten internen Salesforce-Teams wirkte Packaging überdimensioniert. Sie blieben bei direkten Deployments, weil das schneller war, zumindest bis Systeme groß genug wurden, dass es nicht mehr stimmte.

Der Wechsel: Salesforce DX und die CLI-Ära

Der Wendepunkt kam mit Salesforce DX (SFDX) und der Salesforce CLI. Es führte einen developer-first Ansatz ein: source-driven development, scratch orgs und externe Versionskontrolle. Zum ersten Mal war die Org nicht mehr die Source of Truth.

Dieser Wandel definierte neu, wie Packages erstellt und gewartet wurden. Metadata konnte extrahiert, in Git gespeichert und konsistent über automatisierte Pipelines deployed werden. Salesforce führte unlocked packages für Kunden und Partner ein, um große monolithische Orgs in kleinere, modulare Komponenten aufzuteilen, die unabhängig wachsen konnten.

Auf unlocked packages folgten org-dependent unlocked packages

Sie halfen Teams beim schrittweisen Wechsel aus traditioneller Org-Entwicklung, ohne alles auf einmal zu refactoren.

Wenn Sie Ihre gesamte Salesforce-Karriere direkt in Orgs gebaut haben, ergibt der Wechsel hier Sinn. Sie müssen nicht alles über Nacht verschieben. Sie können klein starten, ein einzelnes Feature, Modul oder einen Business Process packagen und in Source Control verfolgen.

Wollten Sie je eine Änderung zurückrollen, ohne Stunden Arbeit zu verlieren? Oder genau sehen, was sich zwischen Releases geändert hat? Oder mit Vertrauen deployen, weil jede Dependency berücksichtigt ist? Das ermöglichen org-dependent unlocked packages.

Sie lassen Sie Versioning, modulare Entwicklung und CI/CD-Praktiken übernehmen, ohne Ihre bestehende Struktur zu brechen. Kein massiver Refactor. Keine vollständige Metadata Migration. Nur ein praktischer Weg von org-basiertem Bauen zu moderner, source-driven Entwicklung.

Diese Schritte zeigten eine klare Richtung: Salesforce wollte jedes Team, nicht nur ISVs, zu modularer, source-controlled Delivery bewegen, in einem Tempo, das zur Realität passt.

Second-generation managed packages: für moderne Entwicklung gebaut

Die Einführung von second-generation managed packages (2GP) festigte diese Entwicklung. Statt alles in einer einzigen Packaging Org zu bauen und zu verwalten, konnten Entwickler Packages direkt aus ihrer lokalen Source erstellen, über Git versionieren und über die CLI releasen.

Das war eine große Veränderung. Packaging wurde kompatibel mit CI/CD-Tools, automatisiertem Testing und modernen Entwicklungspraktiken. 2GP verbesserte außerdem Dependency Handling, Namespace Management und Sicherheit, während es sich eng daran anlehnte, wie SaaS-Plattformen Releases verwalten.

Heute ist second-generation packaging der Standardweg für neue ISVs und zunehmend für Enterprise-Teams, die wartbare, skalierbare Entwicklungsworkflows wollen. Salesforce investiert weiter in diese Tooling-Verbesserungen, vom DevHub-Modell und scratch orgs bis zur DevOps Center-Oberfläche, die viel CLI-Arbeit für Admins abstrahiert.

Von optional zu wesentlich

Jahrelang wurde Packaging als optional betrachtet, etwas, das man erst ab einer bestimmten Org-Größe oder Komplexität übernimmt. Diese Sicht wird schnell veraltet. Die Realität ist, dass jedes Salesforce-Team, ob intern oder kommerziell, von Source Control und versionierten Packages profitiert.

Die Vorteile gehen über Deployment-Speed hinaus. Source-driven development sorgt für Reproduzierbarkeit, einfachere Audits und sicherere Releases. Es beseitigt das Problem “funktioniert in Sandbox, bricht in Produktion”, indem es konsistente Metadata-Definitionen über Umgebungen erzwingt. Es reduziert auch Maintenance Overhead, weil Teams Upgrades und Dependencies über Versionen statt manuelles Patching verwalten.

Kurz gesagt: Packaging ist von einem AppExchange-Distributionsmechanismus zum Rückgrat nachhaltiger Salesforce Delivery gereift.

Was Teams jetzt fragen sollten

Die Frage lautet nicht mehr “Sollten wir Packages nutzen?”, sondern “Wie starten wir, und wie schnell können wir migrieren?”

Einige Kernfragen:

• Deployt Ihr Team noch manuell über Change Sets oder Scripts?

• Haben Sie eine zuverlässige Source of Truth für Ihre Metadata?

• Wie schnell können Sie eine vollständige Umgebung aus Source reproduzieren?

• Sind Dependencies und Integrationen tracked, versioned und testable?

• Können Entwickler parallel arbeiten, ohne gegenseitig Arbeit zu überschreiben?

Wenn Ihre Antwort auf eine dieser Fragen “noch nicht” lautet, ist es Zeit für Modernisierung. Migration muss nicht über Nacht passieren, aber jeder Schritt Richtung source-driven, package-based Delivery zahlt sich aus.

Hier finden Sie alles zur Bedeutung und Umsetzung dieses Wechsels. "The Secrets of Salesforce Second Generation Managed Package"

Wo Tools wie Serpent passen

Die technische Grundlage ist heute solide, aber CI/CD, Version Control und Packaging Workflows aufzusetzen braucht weiterhin Zeit. Hier können Lösungen wie Serpent by Tekunda den Wechsel erleichtern. Serpent streamlinet Salesforce DevOps durch Automatisierung von Packaging, Version Management und Deployment Processes über eine einfache Oberfläche rund um Git und die Salesforce CLI.

Mit guided onboarding, automated release pipelines und native Git integration hilft Serpent Teams beim Wechsel von manueller Org-Entwicklung zu vollständig automatisierter Delivery, ohne unnötige Komplexität. Für Teams, die den nächsten Schritt in der Packaging-Evolution prüfen, ist es ein schneller Weg, die Vorteile praktisch zu sehen.

Das Fazit

Salesforce Package Development hat sich stark entwickelt. Was als Nischen-ISV-Tool begann, wurde zu einem Kernbestandteil professioneller Salesforce Engineering-Arbeit. Die Frage ist nicht mehr, ob Ihr Team Packaging nutzen sollte, sondern wie schnell Sie es übernehmen.

Der Weg zu Source Control und modularen Packages ist nicht nur eine Best Practice; es ist die Richtung, in die Salesforce selbst baut. Je früher Sie sich ausrichten, desto schneller Ihre Releases, sauberer Ihre Architektur und reibungsloser Ihre Skalierung.