Organisieren Ihrer Metadaten

Nachdem Sie diese Lektion abgeschlossen haben, sind Sie in der Lage, die folgenden Aufgaben auszuführen:

• Nennen der wichtigsten Strategien für die Organisation nicht gepackter Metadaten in Paketen
• Erkennen, wie freigeschaltete Pakete voneinander abhängen können
• Beschreiben der drei Paketentwicklungsmodelle und Nennen von Kriterien für ihre Verwendung

Herzlichen Glückwunsch! In der vorherigen Einheit haben Sie ein Paket erstellt und die DreamHouse-Anwendung in Ihrem Trailhead Playground installiert. Jetzt zeigen wir Ihnen, wie Sie einige der wichtigsten Prinzipien der Paketentwicklung in die Praxis umsetzen. Denken Sie daran, es ist in Ordnung, klein anzufangen und auf den Erfolgen aufzubauen.

Das Organisieren Ihrer Metadaten in Paketen:

• Ist oft ein iterativer Prozess.
• Ist kein Alles-oder-nichts-Ansatz.

DreamHouse LWC ist ein großartiges Beispiel dafür, wie Sie eine neue Anwendung von Grund auf neu erstellen und in einem nicht gesperrten Paket packen, damit Sie sie in Ihrer Organisation einführen und künftige Anpassungen verwalten können. Sie können diesem Prozess aber auch bei der Aktualisierung neuer Merkmale oder Funktionen für eine bestehende benutzerdefinierte Anwendung folgen.

Alles in allem haben wir DreamHouse entwickelt, um Ihnen Folgendes zu zeigen:

• Integrieren der Salesforce CLI, Projekte und nicht gesperrten Pakete in Ihren Anwendungslebenszyklus
• Umsetzen bewährter Vorgehensweisen beim Organisieren von Metadaten und Erstellen von Paketgrenzen
• Implementieren freigeschalteter Pakete beim Erstellen einer neuen Anwendung

Was können Sie tun, nachdem Sie ein nicht gesperrtes Paket für DreamHouse LWC erstellt haben?

• Quellcode für die Anwendung unabhängig testen und verteilen
• Das Anwendungsschema (benutzerdefinierte Objekte) von anderen Metadaten isolieren
• Weitere Verbesserungen an der Anwendung vornehmen, indem Sie den Prozess wiederholen und neue Funktionen hinzufügen
• Die Anwendung versionieren
• Eine zweite Version als Upgrade einer vorhandenen Version installieren

DreamHouse-Metadaten

Wie Sie sehen, ist es sehr sinnvoll, den Paketentwicklungs-Lebenszyklus für neue Projekte zu nutzen. Wir wissen jedoch, dass Bestandskunden, die die Entwicklung mit Änderungssets über mehrere Versionen oder sogar Jahre hinweg genutzt haben, nach Anleitung und Ratschlägen dazu fragen, wo sie anfangen sollen. Wie schlüsseln Sie den Inhalt Ihrer Organisation in separate Projekte auf und packen letztendlich Verzeichnisse?

Wir würden Ihnen wirklich gerne ein Patentrezept dafür geben, aber es gibt keinen vorgeschriebenen Aktionsplan. Der Ansatz beim Aufgliedern der nicht gepackten Metadaten ist eine Kombination aus Wissenschaft und Kunst. Sie können am besten beurteilen, welche Metadaten in welche Salesforce DX-Projekte passen.

Stellen Sie sich zu Beginn folgende Fragen:

• Möchten Sie, dass Ihre Entwicklungsteams Anwendungen, neue Funktionen und Anpassungen selbstständig veröffentlichen können?
• Können Sie Metadaten identifizieren, die eine Anwendung darstellen?
• Können Sie Ihre Metadaten in Module für verschiedene Funktionen organisieren?
• Wenn Sie ein nicht verwaltetes Paket für diese Funktion oder Anwendung erstellen, welche Abhängigkeiten liegen vor?

Wenn Sie mehrere Anwendungen und Anpassungen in Ihrer Organisation haben, sollten Sie mit einigen Abhängigkeiten zwischen Salesforce DX-Projekten rechnen.

Drei Modelle zum Aufschlüsseln Ihrer Metadaten

In realen Szenarien werden Sie wahrscheinlich eine Kombination dieser Strategien anwenden und sie so anpassen, dass sie Ihren Geschäftsanforderungen am besten entsprechen.

Verwenden eines nicht verwalteten Pakets als Ausgangspunkt

Der folgende Workflow eignet sich gut als Ausgangspunkt, um Ihre nicht verwalteten Metadaten in mehreren Paketen zu organisieren:

1. Wählen Sie eine kleine Menge nicht gepackter, eigenständiger Metadaten aus Ihrer Produktionsorganisation aus. Wählen Sie Metadaten aus, die eine Anwendung, eine Anpassung einer bestehenden Anwendung, eine Funktion oder Funktionseinheit oder Anpassungen von Standardobjekten darstellen.
2. Erstellen Sie ein nicht verwaltetes Paket, um die von Ihnen identifizierten Metadaten von der Gesamtmenge der Metadaten in Ihrer Organisation zu isolieren. Wenn Sie Metadaten zum Paket hinzufügen, sehen Sie, welche abhängigen Metadaten automatisch vom System geladen werden. Dieser Schritt hilft Ihnen, einige nicht so offensichtliche Abhängigkeiten zwischen Ihren Metadaten aufzudecken.
3. Rufen Sie mit dem Befehl project retrieve start die Quelle aus Ihrem nicht verwalteten Paket ab.
4. Richten Sie ein Salesforce DX-Projekt und ein Git-Repository zur Verwaltung der Paket-Metadaten ein.
5. Übertragen Sie diese Metadaten mit project deploy start in eine Testorganisation und überprüfen Sie, dass dies die Metadaten sind, die Teil eines freigeschalteten Pakets sein sollen.
6. Erstellen Sie ein freigeschaltetes Paket unter Verwendung des Flags --no-namespace.
7. Testen und verteilen Sie das freigeschaltete Paket.
8. Wenn das freigeschaltete Paket alle CI-Läufe und Benutzerakzeptanztests in Sandbox-Organisationen bestanden hat, stufen Sie die Paketversion hoch.
9. Installieren das freigeschaltete Paket in der Produktionsorganisation.

Wenn Sie ein Paket für diese Metadaten erstellen, werden diese automatisch in das Paket verschoben. Da der vollständige Name der Entität die Metadaten in der Organisation und im Paket bezeichnet, überschreiben wir die bereits in der Organisation vorhandenen Metadaten und aktualisieren interne Referenzen, um zu zeigen, dass sie nun im Paket enthalten sind.

Paketabhängigkeiten

Ein wichtiger Vorteil freigeschalteter Pakete ist, dass Sie einen Satz voneinander abhängiger Paketen entwickeln und pflegen können.

• Ein freigeschaltetes Paket kann von einem AppExchange-Paket abhängen. Wenn Sie ein AppExchange-Paket verwenden, können Sie eine eigene Anpassung für dieses in einem freigegebenen Paket platzieren. Wenn Sie das freigegebene Paket installieren, muss das AppExchange-Paket vorhanden sein.
• Ein freigeschaltetes Paket kann von einem anderen freigeschalteten Paket abhängen. Angenommen, Sie erstellen eine neue Anwendung, mit der Mitarbeiter Spesenabrechnungen einreichen können. Diese Anwendung teilt sich einige Backend-Integrationsfunktionen mit Ihrer bestehenden Gehaltsabrechnungsanwendung. In diesem Szenario hängt das freigeschaltete Spesenabrechnungs-Paket vom freigeschalteten Gehaltsabrechnungs-Pakets ab.
• Ein freigeschaltetes Paket kann von einem anderen freigeschalteten Paket abhängen, das wiederum von einem anderen freigeschalteten Paket abhängt. Es werden mehrere Abhängigkeitsebenen unterstützt.

Sie geben die Abhängigkeiten im Abschnitt "packageDirectories" der Datei sfdx-project.json an. Durch die Unterstützung von Abhängigkeiten fördern freigeschaltete Pakete die modulare Entwicklung mit einem umfassenden Abhängigkeiten-Framework. Informationen zur Projektkonfigurationsdatei finden Sie im Salesforce DX Developer Guide.