Skip to main content
Build the future with Agentforce at TDX in San Francisco or on Salesforce+ on March 5–6. Register now.

Aufgliedern Ihrer Metadaten

Lernziele

Nachdem Sie diese Lektion abgeschlossen haben, sind Sie in der Lage, die folgenden Aufgaben auszuführen:
  • Beschreiben, wie Unternehmenskunden nicht gesperrte Pakete verwenden
  • Erklären, wie sich die Paketentwicklung von der Entwicklung von Änderungssets unterscheidet
  • Erläutern, wie Metadaten mit Paketen verteilt werden

Darum ist Paketentwicklung die Zukunft

Wenn Sie das Modul Package Development Model abgeschlossen haben, wissen Sie, dass die modulare, paketbasierte Entwicklung bahnbrechend ist. Vielleicht fragen Sie sich jedoch, wie Sie diese Konzepte in die Praxis umsetzen sollen? Wie macht mir dieses modulare Modell das Leben leichter?

Ganz gleich, ob Sie Neuling oder erfahrener Veteran in der Entwicklung auf der Plattform sind – die Paketerstellung steht Ihnen zur Verfügung. Als langjähriger Kunde wissen Sie: Je mehr Sie die Plattform anpassen und darauf entwickeln, desto größer die Komplexität in Ihrer Organisation. Ihre Salesforce-Organisation wurde zu einem riesigen Behälter für alle Metadaten, die Sie verwalten und mit denen Sie interagieren. Wir bezeichnen dieses Füllhorn als Ihre "glückbringende Suppe".

Ein Karton voller glückbringender Suppe mit unterschiedlichen geometrischen Formen, die verschiedene Metadaten darstellen. Darunter befinden sich drei Kartons mit jeweils einer bestimmten geometrischen Form, die zeigen, wie Sie Ihre Metadaten in Paketen organisieren.

Wenn Sie kürzlich Salesforce-Anpassungen eingeführt haben, haben Sie Metadaten mithilfe von Änderungssets oder sogar nicht verwalteten Paketen an Produktionsorganisationen verteilt. Dieses herkömmliche Entwicklungsmodell wird als Entwicklung mit Änderungssets bezeichnet. Ihre Entwicklung fand bis jetzt weitgehend innerhalb der Grenzen einer Sandbox- oder einer Produktionsorganisation statt.

Der Anwendungslebenszyklus bei der Entwicklung mit Änderungssets umfasst das Verschieben von Organisationsänderungen zwischen Entwicklungs- und Testumgebungen, bis diese Änderungen in Ihrer Produktionsorganisation freigegeben werden. Letztendlich ist jedoch die Produktionsorganisation die "Quelle der Wahrheit". Selbst wenn Sie Änderungen extern in einem Versionskontrollsystem verfolgen, können Sie sicher sein, dass sich alles in Ihrer Organisation befindet.

Jetzt haben Sie jedoch mehr Auswahlmöglichkeiten! Im Paketentwicklungsmodell ist die neue, verbesserte Quelle der Wahrheit Ihr Versionskontrollsystem. Sie verwenden Salesforce DX-Projekte dazu, Ihre Quelle in Paketverzeichnissen zu organisieren. Ihr letztendliches Ziel besteht darin, Pakete mit diesen Verzeichnissen zu erstellen, die versionierbar sowie leicht zu pflegen, zu aktualisieren, zu installieren und upgraden sind.

Trotz allem ist der Wechsel zur Paketentwicklung kein Alles-oder-nichts-Ansatz. Wir beseitigen die Fragezeigen und erklären Ihnen den Einstieg.

Was ist ein Paket?

Wenn die Paketentwicklung neu für Sie ist, stellen Sie sich ein Paket am besten als Behälter vor, den Sie mit Metadaten füllen. Es ist eine verteilbare Funktionseinheit.

Angenommen, Sie haben eine benutzerdefinierte Anwendung für Ihre Mitarbeiter entwickelt, mit denen Spesen nachverfolgt werden können. Sie haben benutzerdefinierte Objekte, Apex-Klassen, Lightning-Komponenten und mehr in die Anwendung eingebunden. Im Änderungsset-Entwicklungsmodell sind alle Metadaten, die zu dieser benutzerdefinierten Anwendung gehören, in Ihrer Salesforce-Organisation enthalten. Sie sind aber sind nicht isoliert oder so organisiert, dass sie leicht aktualisiert und gepflegt werden können. Im Paketentwicklungsmodell organisieren Sie diese Metadaten in klar definierten Containern, die als Pakete bezeichnet werden.

Es wird Sie inzwischen nicht mehr überraschen zu hören, dass die zwingendsten Gründe für die Verwendung von Paketen mit Metadaten bzw. der Organisation Ihrer Metadaten zusammenhängen. Ohne Pakete könnten Ihre Salesforce-Metadaten unübersichtlich werden.

Freigeschaltete Pakete sind die Rettung

Salesforce bietet verschiedene Arten von Paketen mit jeweils spezifischen Eigenschaften. Zunächst verwenden wir einen speziellen Pakettyp, die so genannten freigeschalteten Pakete, die sich besonders für interne Geschäftsanwendungen eignen.

Freigeschaltete Pakete machen Ihnen leichter, Metadaten in Ihrer Organisation auf nachverfolgbare Weise hinzuzufügen, zu bearbeiten und zu entfernen, sodass Sie Komponenten wiederverwenden und Ihre Salesforce-Anwendungen einfacher und schneller aktualisieren können. Sie beinhalten alle Metadatenänderungen und -aktualisierungen, die Sie vorhaben.

Natürlich ändern sich Ihre Anwendung und damit der Inhalt des Pakets mit der Zeit. Um Änderungen nachzuverfolgen, erstellen Sie Versionen Ihres Pakets. Jede Version ist ein unveränderliches Artefakt, eine Momentaufnahme des Paketinhalts.

In Ihrer Produktionsorganisation können Sie prüfen, welche Metadaten aus welcher Paketversion stammen, und den Satz mit allen Metadaten feststellen, die mit der Paketversion verknüpft sind. Dieser Prüfprozess ist derselbe bei Paketen, die Sie von AppExchange aus installiert haben.

Schluss mit Tabellenblättern zum Erfassen von Metadatenänderungen. Schluss mit Klebezetteln!

Was ist ein freigeschaltetes Paket?

Ein freigeschaltetes Paket gibt Ihnen große Flexibilität. Ihre Administratoren können Änderungen in Reaktion auf dringende Änderungsanforderungen direkt in der Produktionsorganisation vornehmen, da Metadaten in freigeschalteten Paketen in einer Produktionsorganisation geändert werden können.

Freigeschaltete Pakete geben Ihnen zwar die Flexibilität, Änderungen direkt in der Produktionsorganisation vorzunehmen, doch Sie sollten daran denken, dass mit großer Macht auch große Verantwortung einhergeht. Spüren Sie, wie Ihre Superheldensinne zu kribbeln beginnen?

Entwickler haben die Kontrolle über freigeschaltete Pakete. Die Installation einer neuen Paketversion überschreibt die Änderungen, die direkt in der Produktionsorganisation vorgenommen wurden. Es ist daher enorm wichtig, dass Administratoren alle Änderungen, die direkt in der Produktionsorganisation vorgenommen werden, dem Entwicklungsteam mitteilen, damit das Paket entsprechend geändert wird.

Was können Sie also in ein freigeschaltetes Paket packen? Nicht erschrecken! Sie können fast alle Arten von Salesforce-Metadaten und -Komponenten in ein freigeschaltetes Paket packen.

Der Bericht "Metadata Coverage" ist die Quelle für Informationen über die Metadaten-Abdeckung über verschiedene Kanäle. Zu diesen Kanälen gehören Metadaten-API, Quellverfolgung, nicht gesperrte Pakete, verwaltete Pakete der ersten und zweiten Generation und mehr. Für den Zugriff auf den Bericht "Metadata Coverage" wechseln Sie zu https://developer.salesforce.com/docs/metadata-coverage.

Wie sieht der Einstieg aus?

Bevor wir zu den Bonbons kommen, möchten wir noch auf etwas hinweisen, das wirklich wichtig ist: Die Umstellung auf Salesforce DX-Tools und Entwicklungsprinzipien ist kein Alles-oder-Nichts-Vorgang. Sie können die Einführung in winzigen Schritten vornehmen oder gleich in die Vollen gehen. Das bleibt Ihnen überlassen.

Also, wenn Sie bereits sind, Ihr Repertoire zu erweitern, wo fangen Sie am besten an?

  • Wenn Sie Salesforce-Einsteiger sind oder ein neues Projekt beginnen, können Sie sich von Anfang an das Paketentwicklungsmodell halten.
  • Wenn Sie mit einem riesigen Berg undifferenzierter Quellen beginnen, können Sie die Paketentwicklung schrittweise umsetzen, indem Sie beginnen, Ihre Metadaten aufzugliedern und in logischen Containern zu organisieren.

Sie können ganz klein anfangen, indem Sie Komponenten und Schemata packen, die Sie später in mehreren Anwendungen wiederverwenden. Mit der Zeit definieren Sie dann Abhängigkeiten zwischen den Paketen. Sie entscheiden, welches Tempo und welche Komplexität Sie bewältigen können.

Diese Flexibilität ist der Vorteil freigeschalteter Pakete.

Paketentwicklung mit Salesforce DX

Nun, da Sie einige Kernkonzepte der Paketentwicklung verstehen, werfen wir einen Blick auf den Paketentwicklungs-Workflow. Der Einfachheit halber nehmen wir an, Sie sind der einzige Entwickler und Release-Manager, doch ein anderer Teamkollege kümmert sich um die Qualitätssicherung (QS).

Erstellen Sie zunächst ein Paket, das mit einem Verzeichnis in Ihrem Salesforce DX-Projekt verknüpft ist. Als Entwickler ändern Sie die Metadaten in Ihrem Projekt, und die Änderungen werden immer mehr. Sie verwenden Testorganisationen, um diese Änderungen zu entwickeln und zu testen (1).

Wenn Sie als Release-Manager bereits sind, Ihr Projekt an die QS zu übergeben, erstellen Sie eine Paketversion. Die QS installiert das Paket und macht sich an die Arbeit. Sie verwenden dieses Paket auch für Einheitentests und CI (2). Während dieses Prozesses beheben Sie Fehler, fügen neue Funktionen hinzufügen oder ändern bestehende Funktionen. Sie erstellen eine neue Paketversion und beginnen den Einheitentestprozess erneut (1).

Hier zeigt sich der iterative Charakter des Paketentwicklungsmodells.

Sie wiederholen diesen Prozess mit der QS, bis Sie eine gut funktionierende Version vorliegen haben. Diese Version installieren Sie dann für Benutzerakzeptanztests (User Acceptance Testing, UAT) in Ihrer Sandbox und schließlich in der Produktionsorganisation (3).

Der Paket-Workflow von links nach rechts Beim Codieren werden Testorganisationen für Entwicklung und Tests verwendet. Bei der Continuous Integration werden Testorganisationen für Einheitentests genutzt. Continuous Delivery setzt auf Entwicklungs- und teilweise Sandboxes für die Erstellung und das UAT. Vollständige Sandboxes werden für abschließende Tests vor der Freigabe für die Produktionsorganisation genutzt.

Die Installation der Paketversion ähnelt der Verteilung von Metadaten. Sie können eine Paketversion in einer beliebigen Version installieren: einer Testorganisation, einer Sandbox-Organisation oder einer Produktionsorganisation – ähnlich wie bei der Verteilung von Metadaten.

Und das war's! Sie kennen jetzt den grundlegenden Anwendungslebenszyklus des Paketentwicklungsmodells.

Nach der Freigabe des ersten Pakets

In der Welt der Hightech- und Softwareentwicklung bleibt nie viel Zeit, um sich auf seinen Lorbeeren auszuruhen. Die nächste Version wirft meist schon ihre Schatten voraus. Jetzt ist es wieder an der Zeit, die Superheldenkluft anzuziehen, sich an die Arbeit zu machen und neue Funktionen und Anpassungen zu entwickeln. Und natürlich auch eine neue Paketversion.

Sie können so viele neue Versionen erstellen, wie Sie benötigen, wenn Sie Paket-Metadaten ändern, hinzufügen oder entfernen. Jede Paketversion hat eine Versionsnummer (z. B. 1.3.0.2), und Sie können ein Paket-Upgrade verwenden, um diese Änderungen auf eine installierte Paketversion anzuwenden.

Dieser Prozess aus Metadaten ändern → Paketversion erstellen → Paketversion testen → Version in Produktion verteilen kann beliebig oft wiederholt werden.

Sind Sie bereit, es auszuprobieren? Lassen Sie uns Ihr erstes freigeschaltetes Paket erstellen.

Teilen Sie Ihr Trailhead-Feedback über die Salesforce-Hilfe.

Wir würden uns sehr freuen, von Ihren Erfahrungen mit Trailhead zu hören: Sie können jetzt jederzeit über die Salesforce-Hilfe auf das neue Feedback-Formular zugreifen.

Weitere Infos Weiter zu "Feedback teilen"