Verpackungsmigration der zweiten Generation und Version Winter 21
Es gibt ein YouTube-Video von Salesforce Developers vom 13. Dezember 2019:
- Einführung verwalteter Pakete der zweiten Generation
Was darauf hindeutete, dass die Veröffentlichung von Winter 21 Folgendes beinhalten würde:
- Aktivierte Migration von Paketen der ersten Generation zu Paketen der zweiten Generation (GA)
- Entfernen Sie alle Metadatentypen aus dem verwalteten Paket (Pilot).
Aber schauen Sie sich die Versionshinweise für Pakete an:
- Versionshinweise zu Salesforce Winter '21: Verpackung: Visualisierungen von Paketvorfahren, unerwünschte Paketversionen können gelöscht werden, Push-Upgrades sind allgemein verfügbar
Es scheint, als hätten sie es nicht in die Veröffentlichung geschafft.
- Hat jemand einen Einblick in den Status dieser Funktionen?
- Was ist der aktuelle Prozess für die Migration eines Pakets der ersten Generation zur zweiten Generation?
- Ist es zu spät, auf die zweite Generation zu migrieren, wenn ich mit dem Erstellen des Pakets in einer Entwicklungsorganisation mit einem Namespace begonnen habe, aber noch nichts hochgeladen habe? (nicht einmal eine Beta)
Antworten
Für den 1. und 2. Artikel sind die Arbeiten im Gange und können die Daten nicht öffentlich bekannt geben.
Ich empfehle Ihnen, sich an Ihren Partner Account Manager zu wenden, oder wenn Sie ein ISV sind, wenden Sie sich an Ihren ISV Technical Evangelist, um eine Vorstellung davon zu bekommen, wann es veröffentlicht und verarbeitet wird.
Für Ihre dritte Frage unten,
Ist es zu spät, auf die zweite Generation zu migrieren, wenn ich mit dem Erstellen des Pakets in einer Entwicklungsorganisation mit einem Namespace begonnen habe, aber noch nichts hochgeladen habe? (nicht einmal eine Beta)
Nein, es ist noch nicht spät, es ist der perfekte Zeitpunkt, um auf 2GP-Pakete umzusteigen.
Solange Sie keine Metadatenkategorie haben , die in 2GP niemals unterstützt wird, sollten Sie wegen verschiedener Vorteile zu 2GP wechseln. Es macht keinen Sinn, 1GP-Verpackungen zu verwenden.
Der Prozess, um mit 2GP für Sie zu beginnen, ist wirklich einfach.
Aktivieren Sie
Dev Hubin Ihrer Partner Business Org (vorausgesetzt, Sie haben dies, da Sie ein ISV sind)Verknüpfen Sie Ihre Entwicklungsorganisation, in der Sie Namespaced haben, mit Ihrer
Dev HubOrganisationErstellen Sie in Ihrer Entwicklungsorganisation ein nicht verwaltetes Paket und fügen Sie alle Metadaten hinzu, die Sie verpacken möchten.
Rufen Sie alle Metadaten aus dem Paket in Ihren lokalen Projektarbeitsbereich ab (verwenden
sfdx force:project:createSie diese Option, um ein Salesforce DX-Projekt zu erstellen und die Salesforce-CLI mit Ihrem DevHub und Ihrer Dev-Organisation zu autorisieren)sfdx force: source: retrieve -n ""
Erstellen Sie ein 2GP-verwaltetes Paket und Paketversionen mithilfe von Paketierungsbefehlen
sfdx force:package:createsfdx force:package:version:create
Wichtige Punkte, die in 2GP-Paketen zu beachten sind, die im Vergleich zu 1GP neu sind
Sie können keine 2GP-Pakete über die Benutzeroberfläche des Paketmanagers erstellen. Es ist CLI-gesteuert und Sie müssen mit Salesforce CLI vertraut sein
2GP-Pakete sind quellengesteuert, dh die Quelle, die Sie in local haben, ist gepackt und die Quelle befindet sich nicht in org. Ich empfehle Ihnen, Ihre Quelle mit Git oder einem anderen VCS zu versionieren. Lesen Sie hier mehr
2GP-Pakete können modular aufgebaut sein und sie in mehrere Pakete aufteilen und in Beziehung setzen. Denken Sie also einige Zeit über die Architektur Ihres Pakets nach.
2GP Managed-Pakete haben das Konzept von Package Ancestors . Dies hilft bei Bedarf, Ihren Code zu verzweigen. Daher ist es wichtig, dass Sie einen Vorfahren markiert haben, bevor Sie das Paket freigeben.
Sie können Scratch Orgs und Nutzung verwenden Quelle - Tracking - Fähigkeit, Push - und Pull - Metadaten.
Hat jemand einen Einblick in den Status dieser Funktionen?
Ich glaube nicht, dass irgendjemand etwas öffentlich sagen kann (#SafeHarbor und all das), aber ich bin sicher, dass sie daran arbeiten.
Was ist der aktuelle Prozess für die Migration eines Pakets der ersten Generation zur zweiten Generation?
Bis in den Versionshinweisen etwas anderes angegeben ist, gibt es keinen Pfad. Abonnenten von Paketen der ersten Generation müssten das alte deinstallieren und dann das neue installieren. Glücklicherweise muss diese Migration nach dem Paket der zweiten Generation nicht erneut durchgeführt werden. Oder warten Sie, bis ein Migrationspfad verfügbar ist.
Ist es zu spät, auf die zweite Generation zu migrieren, wenn ich mit dem Erstellen des Pakets in einer Entwicklungsorganisation mit einem Namespace begonnen habe, aber noch nichts hochgeladen habe? (nicht einmal eine Beta)
Überhaupt nicht! Sie können Ihren Namespace mit Ihrer Dev Hub-Organisation verknüpfen und von dort aus Pakete der zweiten Generation erstellen, nachdem Sie das MDAPI-Format (Metadata API) in das Quellformat konvertiert haben. Dies ist normalerweise so einfach wie force: source: retrieve -x oder force : mdpai: konvertieren. Beachten Sie, dass Sie dies auch dann tun können, wenn Sie Metadaten hochgeladen haben. Diese sind jedoch nicht konvertierbar. Ich würde jedoch nicht empfehlen, zwei Pakete beizubehalten. Wenn Sie neu anfangen, ist es jetzt an der Zeit, mit dem Packaging der zweiten Generation zu beginnen (es sei denn, ein oder mehrere Metadatentypen werden noch nicht unterstützt ). Auf diese Weise können Sie eine unbegrenzte Anzahl von Paketen erstellen, die alle denselben Namespace verwenden können (denken Sie jedoch daran, @NamespaceAccessible zu verwenden, wenn Sie Code für mehrere Pakete freigeben möchten).