DE
EnglishENNederlandsNLالعربيةARFrançaisFRDeutschDE
Kostenlos starten
← Salesforce-DevOps-Glossar

package.xml

Die Manifestdatei, die der Metadata API genau mitteilt, welche Komponenten in einem Release abgerufen oder deployt werden sollen.

Definition

package.xml ist die Manifestdatei, die die Metadata API liest, um zu wissen, welche Komponenten nach Typ und Name in einen Retrieve- oder Deploy-Vorgang aufgenommen werden sollen. Alles, was nicht aufgeführt ist, wird schlicht nicht angefasst; deployte Metadaten, die außerhalb des Manifests liegen, werden unangetastet gelassen statt entfernt, da destruktive Änderungen ihr eigenes, separates Manifest benötigen.

Das manuelle Pflegen von package.xml für ein Release ist eine häufige Ursache für „Bei mir hat's funktioniert“-Bugs: Ein Entwickler fügt lokal ein neues benutzerdefiniertes Feld oder eine Apex-Klasse hinzu, vergisst, den entsprechenden Eintrag zum Manifest hinzuzufügen, und das Deployment gelingt ohne Fehler, während stillschweigend eine Komponente fehlt, von der das Release abhing.

Source-getrackte Orgs und CLI-Tooling können eine package.xml automatisch aus einem Diff generieren, weshalb sich die meisten Salesforce-DevOps-Pipelines von manuell bearbeiteten Manifesten hin zu Tooling bewegt haben, das die Liste aus dem tatsächlich Geänderten aufbaut. Unser Salesforce-DevOps-Guide behandelt die Manifestgenerierung als Teil eines Builds.

In der Praxis

So funktioniert es in Serpent

Serpent baut sein Deployment-Manifest automatisch aus den Metadaten auf, die ein Work Item tatsächlich berührt hat, source-getrackt statt von Hand gepflegt, sodass eine Komponente nicht stillschweigend aus einem Release herausfallen kann, wie es bei einer manuell bearbeiteten package.xml passieren kann. Die Komponentenliste jedes Work Items bleibt vor dem Deployment sichtbar, sodass Reviewer genau bestätigen können, was enthalten ist, ohne ein Manifest von Hand gegenzuprüfen. Siehe Release-Management in Serpent dafür, wie Delta-Deployments abgegrenzt werden.

Serpent generiert ein package.xml-Manifest der abzurufenden oder zu deployenden Komponenten
Häufige Fragen

package.xml, beantwortet

Warum ist mein Deployment erfolgreich, obwohl eine Komponente in der Ziel-Org fehlt?
Die Komponente war fast sicher nicht in package.xml aufgeführt. Die Metadata API berührt nur, was im Manifest steht, daher wirft ein ausgelassener Eintrag keinen Fehler, sondern wird einfach stillschweigend übersprungen.
Kann ich eine einzige package.xml verwenden, um Metadaten sowohl zu deployen als auch zu löschen?
Nein. Deployments und Löschungen verwenden getrennte Manifeste: package.xml für das, was deployt werden soll, und destructiveChanges.xml für das, was entfernt werden soll. Beides in einer Datei zu mischen wird nicht unterstützt.
Wie generiere ich package.xml automatisch, statt sie von Hand zu schreiben?
Source-getrackte Orgs und die Salesforce CLI können ein Manifest aus einem Diff gegenüber dem Geänderten generieren. Tools, die auf Source Tracking aufbauen, einschließlich Serpent, bauen das Manifest automatisch aus den Komponenten auf, die eine Änderung tatsächlich berührt hat.

Kostenlos starten. Keine Kreditkarte, keine Installation, keine Verpflichtung.

Einrichtung in unter 15 Minuten. Keine DevOps-Einstellung nötig.

Kostenlos startenDemo buchen

Neugierig auf schnelleres Shipping, bevor Sie einsteigen? Sprechen wir

Unverbindlich.