Erfassen Sie Ihre Fortschritte
Trailhead-Startseite
Trailhead-Startseite

Verwenden der Paketentwicklung für flexiblere Freigaben

Lernziele

Nachdem Sie diese Lektion abgeschlossen haben, sind Sie in der Lage, die folgenden Aufgaben auszuführen:
  • Identifizieren der Hauptunterschiede zwischen der Paketentwicklung und der Änderungssetentwicklung
  • Beschreiben, was eine Paketversion ist und wie sie Sie bei der Verwaltung der Änderungen in Ihrer Organisation unterstützt
  • Zusammenfassen, warum Sie Setup-Änderungen nicht manuell nachverfolgen müssen, wenn Sie mit dem Paketentwicklungsmodell arbeiten

In dieser Einheit wird beschrieben, warum Calvin und seine Kollegen sich entschließen, von Änderungssetentwicklungs-Modellen zur Paketentwicklung zu wechseln. Andere Teams finden ggf. andere Aspekte der Paketentwicklung überzeugend. Überlegen Sie, während Sie sich diese Einheit durchlesen, welche Entscheidungen Sie für Ihr Team treffen würden und welchen Aspekt der Paketentwicklung Sie am überzeugendsten finden. Machen Sie den Praxistest, indem Sie das am Ende dieses Moduls aufgeführte Modul durcharbeiten, um den Prozess kennenzulernen und die informiertesten Entscheidungen darüber zu treffen, was für Sie das Richtige ist.

Herausforderungen von Änderungssets an die Änderungsverwaltung

Im Laufe der Zeit nimmt die Zahl der Projekte und Beteiligten bei jeder Freigabe an die Produktionsorganisation bei Zephyrus zu. Das ist gut für die Benutzer. Die konsequente Anwendung der ALM-Schritte in dem Unternehmen unterstützt eine gute Verarbeitungszeit bei den Erweiterungsanforderungen, während gleichzeitig die Störungen auf einem Mindestmaß gehalten werden.

Die Koordination dieser Änderungen, insbesondere solch vieler nicht miteinander verbundener Änderungen mehrerer Teams, bereitet Calvin jedoch ganz schönes Kopfzerbrechen. Die Versionen werden immer größer und komplexer. Er macht sich Gedanken darum, dass die Funktionen, auf die sich die Zephyrus-Mitarbeiter verlassen, angesichts des schwierigen Aggregierens und Testens der Änderungen an allen Projekten in einer Version leiden können.

Bei so vielen Änderungen, die es in jeder Version zu koordinieren und nachzuverfolgen gilt, stellt Calvin fest, dass er diese Zeit lieber darauf verwenden würde, Änderungen vorzunehmen. Er überlegt sich auch, dass die Teams, die Salesforce bei Zephyrus anpassen, produktiver sein könnten, wenn sie weniger Zeit darauf verwenden müssten, ihre Änderungen mit denjenigen aus anderen Projekten zu koordinieren.

Einzelner Container oder mehrere Container?

Calvin fragt die anderen Mitglieder in der Salesforce Trailblazer Community um Rat dazu, wie sich in jeder Version so viele Projekte verwalten lassen. Sie erzählen ihm von einem neuen Salesforce-Entwicklungsmodell, durch das die Versionsverwaltung flexibler wird. Es nennt sich Paketentwicklung.

In der Paketentwicklung verwalten Sie verschiedene Anpassungen als separate Pakete und nicht als eine große Version mit Änderungen für die Organisation. Wissen Sie noch, wie Sie in der Änderungssetentwicklung ein Änderungsset aus mehreren Projekten verwalten, als würden sie Teil ein und desselben Containers? Wenn Versionen so komplex werden, dass es sinnvoll ist, die Organisation in Form mehrerer Container zu verwalten, ist die Zeit für einen Wechsel zum Paketentwicklungsmodell gekommen. Wenn Ihr Team bereits modulare Versionsartefakte auf anderen Plattformen erstellt, wird es einige Ähnlichkeiten bei der Arbeit mit der Paketentwicklung feststellen.

Ein Paket bei Zephyrus kann beispielsweise alle folgenden Anpassungen enthalten.

  • Benutzerdefinierte in-house erstellte Force-com-Anwendungen
  • Erweiterungen von Sales Cloud, Service Cloud etc.
  • Erweiterungen einer AppExchange-Anwendung
  • Updates zu freigegebenen Bibliotheken und Funktionen

Wenn Sie in einem Paketentwicklungsmodell arbeiten, erstellen Sie ein Versionsartefakt, das Sie unabhängig von Artefakten für andere Projekte testen und veröffentlichen können. Anstelle eines Änderungssets bezüglich der Produktion erstellt Ihr Team ein Paket, das alle relevanten Metadaten enthält. Die Metadaten in dem Paket enthalten sowohl veränderte als auch unveränderte Komponenten.

Das Organisieren von Metadatenaktualisierungen nach Paketen unterstützt Sie außerdem dabei, vor Ihrem geistigen Auge ein besseres Modell davon zu erstellen, wie die Metadaten in Ihrer Organisation strukturiert sind. Wenn Sie Ihre Organisation in Form mehrerer Container verwalten möchten, steht jedes Paket für einen dieser Container.

Eine Paketversion ist ein a fester Snapshot des Paketinhalts und der verbundenen Metadaten. Mit der Paketversion können Sie jedes Mal, wenn Sie ein spezielles, einem Paket hinzugefügtes Änderungsset freigeben oder bereitstellen, verwalten, was sich verändert hat. Wenn Sie Metadatenänderungen in ein bereits bereitgestelltes Paket einführen, führen Sie ein Upgrade von der aktuellen Paketversion auf die neuere Paketversion durch.

Calvin erhält Auftrieb von den potenziellen Produktivitätsgewinnen, die der Wechsel zur Paketentwicklung birgt. Er stellt den Fall Ernesto, dem CEO, und drei Leitern anderer Abteilungen vor, die Salesforce-Anpassungen erstellen. Dabei konzentriert er sich auf drei Hauptpunkte.

  • Erstellen eines eindeutigen Aktivierungsprotokolls darüber, wie sich die Metadaten der Organisation im Laufe der Zeit verändert haben
  • Erhöhen der Produktivität durch Freisetzung der Zeit, die aktuell auf die Nachverfolgung der Setup-Änderungen verwendet wird
  • Gewinnen größerer Versionsflexibilität, da jedes Paket unabhängig von Paketen für andere Projekte entwickelt, getestet und freigegeben werden kann

Ihre Quelle der Wahrheit sind die Metadaten im Quellcode

In der Paketentwicklung besteht Ihre Quelle der Wahrheit in den Metadaten in Ihrem Paketprojekt. Dadurch wird die Integration in ein VCS vereinfacht, das Ihr Team bei der Verwaltung seiner Projektänderungen unterstützen kann.

In der Änderungssetentwicklung ist die Quelle der Wahrheit eine Kombination aus den bereits in der Umgebung vorhandenen Metadaten und dem letzten Build des Änderungssets. Eigenständig kann ein Änderungsset kein vollständiges Bild darstellen, da es wie eine Diff nur enthält, was geändert wurde.

Verabschieden Sie sich von der manuellen Nachverfolgung von Setup-Änderungen

Es gibt eine Entwicklungsumgebung in der Paketentwicklung, die Testorganisationen heißt. Testorganisationen spielen eine wichtige Rolle, wenn es darum geht, die Änderungen, die Calvin und sein Team zu jeder Version nachverfolgen müssen, beträchtlich zu reduzieren.

Testorganisationen sind leere Organisationen (ohne Metadaten oder Daten), die sich nach Bedarf leicht erstellen und löschen lassen. Sie können Testorganisationen so konfigurieren, dass sie andere Salesforce-Editionen mit anderen Funktionen und Voreinstellungen sind. Hinzu kommt, dass Sie die Testorganisations-Definitionsdatei wiederverwenden und mit anderen Teammitgliedern teilen können, da sie Teil des in das VCS integrierten Projekts ist. Auf diese Weise ist es viel einfacher für Sie alle, an derselben Organisationskonfiguration zu arbeiten, während jeder seine eigene Entwicklungsumgebung hat.

Wenn Sie Testorganisationen zur Entwicklung verwenden, verschieben Sie zuerst den Quellcode von Ihrem Projekt in das VCS, um die Testorganisation mit denselben Metadaten zu synchronisieren. Wenn Sie vorhaben, das Setup für die Entwicklung zu verwenden, werden die Änderungen, die Sie vornehmen, automatisch nachverfolgt. Sie können die Änderungen, die Sie vorgenommen haben, nach unten ziehen, um sie in Ihr Projekt einzubeziehen und Ihr VCS verwenden, um alle Änderungen zu übernehmen.

Tipp

Tipp

Woher weiß Calvin, welche Komponenten in der Quellverfolgung unterstützt werden? Im "Metadata Coverage"-Bericht können Sie sehen, ob Metadatentypen in der Quellverfolgung, der Metadaten-API und anderen Metadatenkanälen unterstützt werden. Dieser dynamisch generierte Bericht ist Ihre beste Quelle für Informationen über die Metadaten-Abdeckung. Für den Zugriff auf den "Metadata Coverage"-Bericht wechseln Sie zu https://developer.salesforce.com/docs/metadata-coverage.

Jedes Paket fährt sein eigenes Rennen

In der Paketentwicklung können Sie für jedes Paket separate Versionszeitpläne führen. Pakete werden verwendet, um das Eigentum der Organisationsmetadaten zu segmentieren, sodass jedes Projekt sein eigenes Paket zuzüglich etwaiger abhängiger Pakete hat. Sie können das Upgrade einzelner Segmente unabhängig voneinander von einer Paketversion zur nächsten verwalten, sodass Sie separate Versionszeitpläne führen können.

Was versteht man unter Paketabhängigkeit? Eine Metadatenkomponente kann immer nur in jeweils einem Paket enthalten sein. Wenn mehr als ein Paket dieselbe Komponente benötigt, können Sie für diese Komponente eine modulare Paketstrategie erstellen. Ein Paket, das eine oder mehrere Metadatenkomponenten enthält, die auf mehrere Pakete aufgeteilt sind, ist eine Paketabhängigkeit.

Jedes Paket (und jede Paketabhängigkeit) kann isoliert von allen anderen Metadaten in der Organisation getestet werden. Diese Isolation von Metadaten in Pakete gibt Ihnen die Flexibilität, die Sie benötigen, um diese Metadatensets (Pakete) unabhängig voneinander zu versionieren. So erhalten Sie zudem die Flexibilität, die Sie benötigen, um die Pakete unabhängig voneinander freizugeben.

Was kommt jetzt?

Jedes der drei Entwicklungsmodelle hat sein eigenes Modul in Trailhead. Indem Sie jedes Modul durcharbeiten, lernen Sie, wie Sie mithilfe des jeweiligen Entwicklungsmodells Anpassungen für Salesforce erstellen: