Show Menu
THEMEN×

Builds

Bei einem Build handelt es sich um eine Gruppe von Dateien, die sämtlichen Code enthalten, der auf dem Clientgerät ausgeführt wird.
Sie bilden eine Zusammenstellung der Änderungen, die Sie in Ihrer Bibliothek festgelegt haben, sowie aller zuvor eingereichten, genehmigten oder veröffentlichten Elemente.
Der Build besteht aus clientseitigen Codedateien, die sich gegenseitig referenzieren. Diese Dateien werden mithilfe der Umgebung und des Hosts, den Sie für Ihre Bibliothek ausgewählt haben, an Ihren Hosting-Standort übertragen. Der Code, den Sie auf Ihrer Site bereitstellen, verweist auf denselben Speicherort, damit die Dateien geladen werden können, wenn ein Benutzer auf Ihre Site oder Anwendung zugreift.

Dateiinhalt

Eine Bibliothek definiert einen speziellen Satz von Launch-Ressourcen (Erweiterungen, Regeln und Datenelemente), die darin enthalten sein sollten.
Ein Build enthält den gesamten Modulcode (von den Entwicklern der Erweiterung bereitgestellt) und die Konfiguration (von Ihnen eingegeben), die benötigt werden, um die in der Bibliothek enthaltenen Ressourcen zu generieren. Wenn eine Erweiterung beispielsweise Aktionen bereitstellt, die in Ihren Regeln nicht verwendet werden, ist der Code für die Durchführung dieser Aktionen nicht im Build enthalten.
Builds sind in die Hauptbibliotheksdatei und möglicherweise in viele kleinere Dateien unterteilt. Auf die Hauptbibliotheksdatei wird in Ihrem Einbettungscode verwiesen, und sie wird zur Laufzeit auf der Seite geladen. Sie enthält Folgendes:
  • Regel-Engine
  • Gesamte Erweiterungskonfiguration
  • Gesamten Code und gesamte Konfiguration von Datenelementen
  • Gesamten Code und gesamte Konfiguration von Regelereignissen
  • Gesamten Code und gesamte Konfiguration von Bedingungen
  • Ereigniscode und -konfiguration für sämtliche Regeln, die „Bibliothek geladen“ oder „Seitenende“ als Ereignis verwenden (da wir wissen, dass wir diese sofort benötigen).
Die kleineren Dateien enthalten den Code und die Konfiguration für einzelne Aktionen, die nach Bedarf auf der Seite geladen werden. Wenn eine Regel ausgelöst wird und ihre Bedingungen so ausgewertet werden, dass die Aktionen ausgeführt werden müssen, werden der erforderliche Code und die Konfiguration für die jeweilige Aktion aus einer der kleineren Dateien abgerufen. Das bedeutet, dass immer nur der Code auf der Seite geladen wird, der erforderlich ist, um die jeweiligen Aktionen durchzuführen. So wird die Hauptbibliothek möglichst klein gehalten.

Dateiformat

Das Standarddateiformat für Builds ist ein Paket von Dateien, die den gesamten Code enthalten, damit Ihre Erweiterungen, Datenelemente und Regeln auf die gewünschte Weise ausgeführt werden können.
In bestimmten Fällen empfiehlt sich jedoch ein ZIP-Archiv der Dateien anstelle der ausführbaren clientseitigen Codedatei. Beispiel: Ein Archiv ist sinnvoll, wenn Sie Ihren Build selbst hosten und den Build in einer anderen Implementierung verwenden möchten. Wenn Sie einen Pfad zur selbst gehosteten Bibliothek angeben, können Sie Ihre Umgebung speichern. Neben Ihrem neuen Code wird ein Link zum archivierten Download verfügbar. Launch erstellt weiterhin Ihre Bibliothek und stellt sie bereit. Anstatt jedoch eine Reihe von Codedateien bereitzustellen, können Sie Akamai eine ZIP-Datei bereitstellen und sie von assets.adobedtm.com/... herunterladen.
An diesem Ort ist nichts vorhanden, bis Sie einen Build erstellen.
Unabhängig vom Dateiformat wird der Build immer an dem vom Host angegebenen Speicherort bereitgestellt.
Um einen Build abzuschließen, wählen Sie eine Bibliothek aus und klicken Sie auf die Build-Option, die auf dieser Ebene des Veröffentlichungsvorgangs verfügbar ist (Build für die Entwicklung, Build für das Staging usw.).

Minimierung

Durch Minimierung werden Bandbreitenkosten reduziert und die Geschwindigkeit erhöht, indem Daten, die nicht für die Ausführung erforderlich sind, aus der jeweiligen Datei entfernt werden.
Um die Leistung zu steigern, minimiert Launch alle Elemente, einschließlich:
  • Launch-Hauptbibliothek
  • Modulcode, der von den Entwicklern als Teil einer Erweiterung bereitgestellt wird
  • Benutzerspezifischer Code von Launch-Benutzern
Wenn Ihr Modul- und Ihr benutzerspezifischer Code bereits minimiert wurden, minimiert Launch sie erneut. Diese zweite Minimierung bietet keine zusätzlichen Vorteile, verursacht jedoch keinen Schaden und ist weniger komplex und leichter zu verwalten.
Jeder clientseitige Code, der in Launch bereitgestellt wird, verweist auf die minimierte Version des Codes wie in den Dateinamen angegeben, die der Standard-Namenskonvention für minimierte Dateien folgen:
launch-%environment_id%.min.js
Wenn Sie den nicht minimierten Code sehen möchten, entfernen Sie „.min“ aus dem Dateinamen:
launch-%environment_id%.js
Wenn ein Erweiterungsentwickler minimierten Code mit seiner Erweiterung bereitstellt, stellt Launch im nicht minimierten Build keinen nicht minimierten Code bereit. Launch kann nur bereitstellen, was der Erweiterungsentwickler Adobe bereitstellt. Wenn ein Launch-Benutzer minimierten Code in ein Feld für benutzerspezifischen Code eingibt, wird dieser Code bei nicht minimierten Builds dennoch minimiert. Launch maximiert den Code nicht.
Weitere Informationen zur Minimierung finden Sie unter https://blog.stackpath.com/glossary/minification/ .
Beim Erstellen eines Builds generiert Launch zunächst die nicht minimierte Bibliothek. Daraufhin wird die gesamte Bibliothek gleichzeitig minimiert.