Freigeben über

Application Lifecycle Management (ALM) für Codekomponenten

  • Artikel

ALM ist ein Begriff, der verwendet wird, um das Lebenszyklusmanagement von Softwareanwendungen zu beschreiben, das Entwicklung, Wartung und Governance umfasst. Mehr Informationen: Application Lifecycle Management (ALM) mit Microsoft Power Platform.

In diesem Artikel werden Überlegungen und Strategien für die Arbeit mit bestimmten Aspekten der Lebenszyklusverwaltung aus der Sicht von Codekomponenten in Microsoft Dataverse beschrieben.

  1. Überlegungen zur Entwicklung und zum Debuggen von ALM

  2. Lösungsstrategien für Codekomponenten

  3. Versions- und Bereitstellungsaktualisierungen

  4. ALM-Überlegungen für Canvas-Apps

Überlegungen zur Entwicklung und zum Debuggen von ALM

Bei der Entwicklung von Codekomponenten gehen Sie wie folgt vor:

  1. Erstellen Sie ein Codekomponenten-Projekt (pcfproj) aus einer Vorlage mithilfe von pac pcf init. Mehr Informationen: Erstellen einer Codekomponente.
  2. Implementieren Sie die Codekomponentenlogik. Mehr Informationen: Komponentenimplementierung.
  3. Debuggen Sie die Codekomponente mithilfe der lokalen Testumgebung. Mehr Informationen: Debugging von Codekomponenten.
  4. Erstellen Sie ein Lösungsprojekt (cdsproj) und fügen Sie das Codekomponenten-Projekt als Referenz hinzu. Weitere Informationen: Bündeln einer Code-Komponente.
  5. Erstellen Sie die Codekomponente im Release-Modus für die Verteilung und Bereitstellung.

Wenn Ihre Codekomponente zum Testen in einer modellgesteuerten App, Canvas-App oder einem Portal bereit ist, gibt es zwei Möglichkeiten, eine Codekomponente in Dataverse bereitzustellen:

  1. pac pcf Push: Dadurch wird jeweils eine einzelne Codekomponente für eine durch den Parameter --solution-unique-name angegebene Lösung oder eine temporäre PowerAppsTools Lösung bereitgestellt, wenn keine Lösung angegeben ist.

  2. Verwenden Sie pac solution init und msbuild, um ein cdsproj-Lösungsprojekt zu erstellen, das Verweise auf eine oder mehrere Codekomponenten enthält. Jede Codekomponente wird dem cdsproj mithilfe von pac solution add-reference hinzugefügt. Ein Lösungsprojekt kann Verweise auf mehrere Codekomponenten enthalten, während Codekomponenten-Pprojekte nur eine einzelne Codekomponente enthalten dürfen.

    Das folgende Diagramm zeigt die Eins-zu-viele-Beziehung zwischen cdsproj- und pcfproj-Projekten:

    Eins-zu-viele-Beziehung zwischen cdsproj- und pcfproj-Projekten.

Weitere Informationen: Bündeln einer Code-Komponente.

Erstellen von „pcfproj“-Codekomponenten-Projekten

Beim Erstellen von pcfproj-Projekten hängt das generierte JavaScript von dem zum Erstellen verwendeten Befehl und dem PcfBuildMode in der pcfproj-Datei ab.

Normalerweise implementieren Sie keine Codekomponente in Microsoft Dataverse, die im Entwicklungsmodus erstellt wurde, da sie für den Import oft zu groß ist und zu einer geringeren Runtime-Leistung führt. Mehr Informationen: Debuggen nach der Bereitstellung in Microsoft Dataverse.

Damit pac pcf push zu einem Release-Build wird, wird PcfBuildMode innerhalb von pcfproj festgelegt, indem ein neues Element unter dem OutputPath-Element wie folgt hinzugefügt wird:

<PropertyGroup>
   <Name>my-control</Name>
   <ProjectGuid>6aaf0d27-ec8b-471e-9ed4-7b3bbc35bbab</ProjectGuid>
   <OutputPath>$(MSBuildThisFileDirectory)out\controls</OutputPath>
   <PcfBuildMode>production</PcfBuildMode>
</PropertyGroup>

Die folgende Tabelle zeigt, welche Befehle zu Entwicklungs- bzw. Release-Builds führen:

Build-Befehl, der bei pcfproj verwendet wird Entwicklungs-Build
(nur zu Debugging-Zwecken)		 Release-Build
npm start watch Immer
pac pcf push Standardverhalten oder wenn PcfBuildMode auf Entwicklung in der pcfproj-Datei eingestellt ist PcfBuildMode ist auf Produktion in der pcfproj-Datei eingestellt
npm run build Standardverhalten npm run build -- --buildMode production

Weitere Informationen: Bündeln einer Code-Komponente.

Erstellen von .cdsproj-Lösungsprojekten

Beim Erstellen eines Lösungsprojekts (.cdsproj) haben Sie die Möglichkeit, die Ausgabe als verwaltete oder als nicht verwaltete Lösung zu generieren. Verwaltete Lösungen werden zur Bereitstellung in jeder Umgebung verwendet, die für diese Lösung keine Entwicklungsumgebung ist. Dies umfasst Test-, UAT-, SIT- und Produktionsumgebungen. Weitere Informationen: Verwaltete und nicht verwaltete Lösungen.

SolutionPackagerType ist in der .cdsproj-Datei enthalten, die von pac solution init erstellt, aber zunächst auskommentiert wird. Kommentieren Sie den Abschnitt aus und setzen Sie ihn auf Verwaltet, Nicht verwaltet, oder Beides.

 <!-- Solution Packager overrides, un-comment to use: SolutionPackagerType (Managed, Unmanaged, Both) -->
 <PropertyGroup>
    <SolutionPackageType>Managed</SolutionPackageType>
 </PropertyGroup>

Die folgende Tabelle zeigt, welcher Befehle und welche Konfigurationsergebnisse zu Entwicklungs- bzw. Release-Builds führen:

Build-Befehl, der bei cdsproj verwendet wird SolutionPackageType Ausgabe
msbuild Verwaltet Entwicklungs-Build innerhalb der verwalteten Lösung
msbuild /p:configuration=Release Verwaltet Release-Build innerhalb der verwalteten Lösung
msbuild Nicht verwaltet Entwicklungs-Build innerhalb der nicht verwalteten Lösung
msbuild /p:configuration=Release Nicht verwaltet Release-Build innerhalb der nicht verwalteten Lösung

Weitere Informationen: Bündeln einer Code-Komponente.

Quellcodeverwaltung mit Codekomponenten

Beim Entwickeln von Codekomponenten wird empfohlen, einen Quellcode-Kontrollanbieter wie z. B. Azure DevOps oder GitHub zu verwenden. Wenn Sie Änderungen mit der Git-Quellcodeverwaltung festschreiben, stellt die .gitignore-Datei, die von der pac pcf init-Vorlage bereitgestellt wird, sicher, dass einige Dateien nicht der Quellcodeverwaltung hinzugefügt werden, da sie entweder von npm wiederhergestellt oder im Rahmen des Build-Prozesses generiert werden:

# <a name="dependencies"></a>dependencies
/node_modules

# <a name="generated-directory"></a>generated directory
**/generated

# <a name="output-directory"></a>output directory
/out

# <a name="msbuild-output-directories"></a>msbuild output directories
/bin
/obj

Da der /out-Ordner ausgeschlossen ist, wird die resultierende bundle.js-Datei (und zugehörige Ressourcen) nicht der Quellcodeverwaltung hinzugefügt. Wenn Ihre Codekomponenten manuell oder als Teil einer automatisierten Buildpipeline erstellt werden, würde bundle.js mit dem neuesten Code erstellt werden, um sicherzustellen, dass alle Änderungen enthalten sind.

Wenn eine Lösung erstellt wird, werden außerdem ZIP-Dateien der Zuordnungslösung nicht an die Quellcodeverwaltung übergeben. Stattdessen würde die Ausgabe als binäre Release-Artefakte veröffentlicht.

Verwenden von SolutionPackager mit Codekomponenten

Neben der Quellcodeverwaltung von pcfproj und cdsproj, kann SolutionPackager verwendet werden, um eine Lösung inkrementell in ihre jeweiligen Teile als eine Reihe von XML-Dateien zu entpacken, die in die Quellcodeverwaltung übernommen werden können. Dies hat den Vorteil, dass Sie ein vollständiges Bild Ihrer Metadaten im lesbaren Format erstellen, sodass Sie Änderungen beispielsweise mithilfe von Abrufanforderungen nachverfolgen können. Jedes Mal, wenn eine Änderung an den Lösungsmetadaten der Umgebung vorgenommen wird, wird Solution Packager zum Entpacken verwendet und die Änderungen können als Änderungssatz angezeigt werden.

Hinweis

Zu diesem Zeitpunkt unterscheidet sich SolutionPackager von der Verwendung von pac solution clone in dem Sinne, dass es inkrementell zum Exportieren von Änderungen einer Dataverse-Lösung verwendet werden kann.

Wenn Sie Codekomponenten mit anderen Lösungselementen wie Tabellen, modellgesteuerten Apps und Canvas-Apps kombinieren, benötigen Sie normalerweise keinen cdsproj Projektbuild. Stattdessen würden Sie die gebauten Artefakte aus dem pcfproj in den Lösungspaketordner verschieben, bevor Sie es für den Import neu packen.

Sobald eine Lösung, die eine Codekomponente enthält, mit SolutionPackager /action: Extract entpackt wird, wird sie so ähnlich aussehen:

.
├── Controls
│   └── prefix_namespace.ControlName
│       ├── bundle.js *
│       └── css
│          └── ControlName.css *
│       ├── ControlManifest.xml *
│       └── ControlManifest.xml.data.xml
├── Entities
│   └── Contact
│       ├── FormXml
│       │   └── main
│       │       └── {3d60f361-84c5-eb11-bacc-000d3a9d0f1d}.xml
│       ├── Entity.xml
│       └── RibbonDiff.xml
└── Other
    ├── Customizations.xml
    └── Solution.xml

Sie können unter dem Controls-Ordner sehen, dass es Unterordner für jede Codekomponente gibt, die in der Lösung enthalten ist. Die anderen Ordner enthalten zusätzliche Lösungskomponenten, die der Lösung hinzugefügt wurden.

Wenn Sie diese Ordnerstruktur an die Quellcodeverwaltung übergeben, würden Sie die oben mit einem Stern (*) markierten Dateien ausschließen, da sie ausgegeben werden, wenn das pcfproj-Projekt für die entsprechende Komponente erstellt wird.

Die einzigen benötigten Dateien sind die *.data.xml-Dateien, da sie Metadaten enthalten, die die für den Paketprozess erforderlichen Ressourcen beschreiben. Nachdem jede Codekomponente erstellt wurde, werden die Dateien im out-Ordner in den jeweiligen Verwaltungsordner in den SolutionPackager-Ordnern kopiert. Nachdem die Build-Ausgaben hinzugefügt wurden, enthalten die Paketordner alle Daten, die zum erneuten Packen in eine Dataverse-Lösung mithilfe von SolutionPackager /action: Pack erforderlich sind.

Mehr Informationen: SolutionPackager-Befehlszeilenargumente.

Lösungsstrategien für Codekomponenten

Codekomponenten werden mithilfe von Dataverse-Lösungen in Downstream-Umgebungen bereitgestellt. Nach der Bereitstellung in Ihrer Entwicklungsumgebung können sie auf die gleiche Weise wie andere Lösungskomponenten bereitgestellt werden. Mehr Informationen: Lösungskonzepte – Power Platform.

Es gibt zwei Strategien für die Bereitstellung von Codekomponenten in Lösungen:

  1. Segmentierte Lösungen – Ein Lösungsprojekt wird mit pac solution init erstellt und dann wird pac solution add-reference verwendet, um eine oder mehrere Codekomponenten hinzuzufügen. Diese Lösung kann dann in Downstream-Umgebungen exportiert und importiert werden, und andere segmentierte Lösungen werden von der Codekomponentenlösung abhängig, sodass sie zuerst in dieser Umgebung bereitgestellt werden muss. Dies wird als Lösungssegmentierung bezeichnet, da die Gesamtfunktionalität auf verschiedene Lösungssegmente und -schichten aufgeteilt wird, wobei gegenseitige Abhängigkeiten durch das Lösungsframework verfolgt werden. Wenn Sie diesen Ansatz verwenden, benötigen Sie wahrscheinlich mehrere Entwicklungsumgebungen – eine für jede segmentierte Lösung. Mehr Informationen: Verwenden von segmentierten Lösungen in Power Apps.

  2. Einzellösung – Eine einzelne Lösung wird in einer Dataverse-Umgebung erstellt und dann werden Codekomponenten zusammen mit anderen Lösungskomponenten (z. B. Tabellen, modellgesteuerten Apps oder Canvas-Apps) hinzugefügt, die wiederum auf diese Codekomponenten verweisen. Diese Lösung kann ohne Abhängigkeiten zwischen den Lösungen in Downstream-Umgebungen exportiert und importiert werden. Bei diesem Ansatz werden Code- und Umgebungsverzweigungen wichtig, damit Sie ein Update für einen Teil der Lösung bereitstellen können, ohne Änderungen vorzunehmen, die in einem anderen Bereich vorgenommen werden. Mehr Informationen: Verzweigungs- und Zusammenführungsstrategie mit Microsoft Power Platform.

Gründe für die Anwendung eines segmentierten Lösungsansatzes gegenüber einem gemischten Einzellösungsansatz können folgende sein:

  1. Versionslebenszyklus – Sie möchten Ihre Codekomponenten in einem separaten Lebenszyklus zu den anderen Teilen Ihrer Lösung entwickeln, bereitstellen und eine Versionskontrolle durchführen. Dies ist ein häufiges Szenario, bei dem Sie ein „Zusammenführungsteam“ haben, in dem von Entwicklern erstellte Codekomponenten von App-Erstellern verwendet werden. In der Regel würde dies auch bedeuten, dass Ihre Codekomponenten in einem anderen Code-Repository vorhanden sind als andere Lösungskomponenten.

  2. Gemeinsame Nutzung – Sie möchten Ihre Codekomponenten für mehrere Umgebungen freigeben und möchten daher Ihre Codekomponenten nicht mit anderen Lösungskomponenten koppeln. Dies kann der Fall sein, wenn Sie ein ISV sind oder eine Codekomponente für die Verwendung durch verschiedene Teile Ihrer Organisation entwickeln, die jeweils über eine eigene Umgebung verfügen.

Das folgende Diagramm zeigt einen Überblick über den Lösungslebenszyklus für diese beiden Ansätze:

Lösungsstrategien.

Im Diagramm werden die folgenden Punkte beschrieben:

  1. Push mithilfe von PAC CLI – Wenn die Codekomponente zum Testen innerhalb von Dataverse bereit ist, wird pac pcf push verwendet, um eine Bereitstellung in einer Entwicklungsumgebung vorzunehmen. Dadurch wird eine nicht verwaltete Lösung namens PowerAppsTools_namespace erstellt, bei der Namespace das Namespace-Präfix des Lösungsanbieters ist, unter dem Sie Ihre Codekomponente bereitstellen möchten. Der Lösungsanbieter sollte bereits in der Zielumgebung vorhanden sein und muss dasselbe Namespace-Präfix aufweisen wie das, das Sie für nachgelagerte Umgebungen verwenden möchten. Nach der Bereitstellung können Sie Ihre Codekomponente zu Testzwecken zu modellgesteuerten oder Canvas-Apps hinzufügen.

    Hinweis

    Wie oben beschrieben ist es wichtig, die Codekomponente cdsproj für den Produktions-Build zu konfigurieren, sodass Sie den Code bereitstellen, der für die Produktion und nicht für die Entwicklung optimiert ist.

  2. Hinzufügen vorhandener Codekomponenten (nach der PAC CLI-Bereitstellung) – Wenn Sie den Einzellösungsansatz verwenden, kann die Codekomponente nach der Bereitstellung einer anderen Lösung hinzugefügt werden. (Diese Lösung muss den gleichen Lösungsherausgeber haben, der von der PowerAppsTools-Lösung verwendet wird.)

    Vorh. hinzufügen.

  3. Nicht verwaltetes Lösungsprojekt erstellen – Wenn Sie eine Lösungs-cdsproj-Projekte verwenden, kann eine nicht verwaltete Lösung mithilfe von msbuild erstellt, und dann in Ihre Entwicklungsumgebung importiert werden.

  4. Vorhandene Codekomponenten hinzufügen (nach Bereitstellung des Lösungsprojekts)  – Ähnlich wie nach pac pcf push, können Codekomponenten, die aus einem Lösungsprojekt-Build importiert werden, einer gemischten Lösung hinzugefügt werden, vorausgesetzt, dass das gleiche Lösungsherausgeber-Präfix verwendet wurde.

  5. Einzellösung als verwaltet exportieren – Die Einzellösung mit gemischten Komponenten kann dann als verwaltet exportiert und in die Downstream-Umgebungen importiert werden. Da die Codekomponenten und andere Lösungskomponenten in derselben Lösung bereitgestellt werden, teilen sie alle dieselbe Lösungs- und Versionsstrategie.

  6. Segmentierte Lösung für Codekomponenten als verwaltet exportieren – Wenn Sie den segmentierten Lösungsansatz verwenden, können Sie Ihr Codekomponenten-Lösungsprojekt als verwaltet in Downstream-Umgebungen exportieren.

  7. Segmentierte Lösung für Codekomponenten als verwaltet erstellen – Wenn Sie segmentierte Lösungen verwenden und keine nicht verwaltete Lösung benötigen, können Sie das Lösungsprojekt mithilfe von msbuild /p:configuration=Release direkt als verwaltete Lösung erstellen. Diese kann dann in Umgebungen importiert werden, die eine Abhängigkeit von ihren Codekomponenten annehmen müssen.

  8. Segmentierte Lösung für Codekomponenten verwenden – Nachdem Codekomponenten über eine verwaltete segmentierte Lösung bereitgestellt wurden, können andere Lösungen erstellt werden, die von der Codekomponentenlösung abhängig sind. Die Abhängigkeiten von Codekomponenten werden im MissingDependencies-Abschnitt des Typs 66 der Lösung aufgeführt. Weitere Informationen: Abhängigkeitsnachverfolgung für Lösungskomponenten.

  9. Segmentierte Lösung für Codekomponenten vor Lösungen bereitstellen, die sie verwenden – Beim Importieren von Lösungen, die Abhängigkeiten von einer segmentierten Codekomponentenlösung annehmen, muss die Codekomponentenlösung in der Zielumgebung installiert werden, bevor sie importiert werden kann.

Weitere Informationen: Verpacken und Bereitstellen von Erweiterungen mithilfe von Lösungen.

Codekomponenten und automatisierte Buildpipelines

Zusätzlich zum manuellen Erstellen und Bereitstellen Ihrer Codekomponentenlösungen können Sie Ihre Codekomponenten auch mithilfe von automatisierten Buildpipelines erstellen und packen.

Einige der Vorteile der Verwendung automatisierter Buildpipelines sind:

  • Sie sind zeitsparend – Das Entfernen der manuellen Aufgaben macht das Erstellen und Verpacken Ihrer Komponente schneller, sodass sie regelmäßiger durchgeführt werden kann, z. B. jedes Mal, wenn eine Änderung eingecheckt wird.
  • Sie sind wiederholbar – Sobald der Build-Prozess automatisiert ist, wird er jedes Mal gleich ausgeführt und ist daher nicht von dem Mitglied des Teams abhängig, das den Build durchführt.
  • Sie bieten Versionskonsistenz – Wenn die Buildpipeline automatisch die Version Ihrer Codekomponente und der Lösung festlegt, können Sie sicher sein, dass beim Erstellen eines neuen Builds dieser im Vergleich zu früheren Versionen konsistent versioniert wird. Dies erleichtert die Verfolgung von Funktionen, Fehlerbehebungen und Bereitstellungen.
  • Sie sind wartbar – Da alles, was Sie zum Erstellen Ihrer Lösung benötigen, in der Quellcodeverwaltung enthalten ist, können Sie jederzeit neue Verzweigungen und Entwicklungsumgebungen erstellen, indem Sie den Code auschecken. Wenn Sie ein Update bereitstellen möchten, können Abrufanforderungen in Downstream-Verzweigungen zusammengeführt werden. Mehr Informationen: Verzweigungs- und Zusammenführungsstrategie mit Microsoft Power Platform.

Wie oben beschrieben gibt es zwei Ansätze für die Lösungsverwaltung von Codekomponenten, ein segmentiertes Lösungsprojekt oder eine einzelne gemischte Lösung mit anderen Artefakten wie modellgesteuerten Apps, Canvas-Apps und Tabellen, denen die Codekomponenten hinzugefügt werden.

Wenn Sie das segmentierte Lösungsprojekt für Codekomponenten verwenden, können Sie das Projekt in einer Azure DevOps-Pipeline (mithilfe von Microsoft Power Platform Build Tools) oder einer GitHub-Pipeline (mithilfe von GitHub Actions für Microsoft Power Platform) erstellen. Jeder pcfproj-Ordner einer Codekomponente wird der Quellcodeverwaltung hinzugefügt (mit Ausnahme der Ordner generated, out und node_modules), ein cdsproj-Projekt wird erstellt und auf jede Codekomponente wird mithilfe von pac solution add-reference verwiesen, bevor sie auch der Quellcodeverwaltung hinzugefügt wird. Die Pipeline würde dann Folgendes ausführen:

  1. Aktualisieren Sie die Lösungsversion in der Solution.xml-Datei entsprechend der Version Ihres Builds. Die Lösungsversion befindet sich im ImportExportXml/Version-Attribut. Weitere Informationen zu Versionsstrategien finden Sie weiter unten.
  2. Aktualisieren Sie die Codekomponentenversion in der ControlManifest.Input.xml-Datei. Die Version wird im manifest-/control-/version-Attribut gespeichert. Dies sollte für alle erstellten pcfproj-Projekte getan werden.
  3. Führen Sie eine MSBuild-Aufgabe mit dem Argument /restore /p:configuration=Release unter Verwendung eines Platzhalter-*.cdsproj aus. Dadurch werden alle cdsproj-Projekte und die pcfproj-Projekte erstellt, auf die verwiesen wird.
  4. Erfassen Sie die erstellte Lösungs-ZIP-Datei in den Pipeline-Release-Artefakten. Diese Lösung enthält alle Codekomponenten, die als Referenzen in cdsproj enthalten sind.

Wenn Sie eine gemischte Lösung verwenden, die neben Codekomponenten auch andere Komponenten enthält, wird diese mithilfe von SolutionPackager wie oben beschrieben in die Quellcodeverwaltung extrahiert. Ihre Pipeline würde dann Folgendes ausführen:

  1. Aktualisieren Sie die Lösungs- und Codekomponentenversionen wie in den Schritten 1 und 2 beschrieben.
  2. Installieren Sie die Microsoft Power Platform Build Tools in der Buildpipeline mithilfe der PowerPlatformToolInstaller-Aufgabe.
  3. Stellen Sie node_modules wieder her, indem Sie die Npm-Aufgabe mit dem Befehl ci verwenden.
  4. Erstellen Sie Codekomponenten im Produktionsfreigabemodus mit einer Npm-Aufgabe sowie einem customCommand-Parameter von run build -- --buildMode release.
  5. Kopieren Sie die Ausgabe des Builds in den Solution Packager-Ordner für das entsprechende Steuerelement.
  6. Verpacken Sie die Lösung mithilfe der PowerPlatformPackSolution-Aufgabe der Power Platform Build Tools.
  7. Erfassen Sie die erstellte Lösungs-ZIP-Datei in den Pipeline-Release-Artefakten.

Es wird empfohlen, dass Sie Ihre entpackten Lösungsmetadaten in ihrer nicht verwalteten Form an die Quellcodeverwaltung übergeben, um die Erstellung einer Entwicklungsumgebung zu einem späteren Zeitpunkt zu ermöglichen. Wenn nur verwaltete Lösungsmetadaten festgeschrieben würden, wird es schwierig, neue Entwicklungsumgebungen zu erstellen. Sie haben dafür zwei Optionen:

  1. Übergeben Sie sowohl verwaltete als auch nicht verwaltete mithilfe der /packagetype:Both-Option von Solution Packager. Dies ermöglicht das Verpacken entweder im verwalteten oder im nicht verwalteten Modus, hat jedoch den Nachteil der Duplizierung innerhalb des Quellcodes, sodass Änderungen oft in mehreren XML-Dateien erscheinen – sowohl in der verwalteten als auch in der nicht verwalteten Version.
  2. Übergeben Sie nicht verwaltete Dateien nur an die Quellcodeverwaltung (was zu saubereren Änderungssätzen führt), und importieren Sie dann die gepackte Lösung innerhalb der Buildpipeline in eine Buildumgebung, damit sie dann als verwaltet exportiert werden kann, um sie in ein verwaltetes Bereitstellungsartefakt zu konvertieren.

Versions- und Bereitstellungsaktualisierungen

Beim Bereitstellen und Aktualisieren Ihrer Codekomponenten ist eine konsistente Versionsverwaltungsstrategie wichtig, damit Sie folgende Optionen haben:

  • Sie können nachverfolgen, welche Version mit welchen Funktionen/Fehlerbehebungen bereitgestellt wird.
  • Sie können sicherstellen, dass Canvas-Apps erkennen können, dass sie auf die neueste Version aktualisiert werden müssen.
  • Sicherstellen, dass modellgesteuerte Apps ihren Cache ungültig machen und die neue Version laden.

Eine gängige Strategie zur Versionsverwaltung ist die semantische Versionsverwaltung mit dem Format: MAJOR.MINOR.PATCH.

Inkrementierung der PATCH-Version

ControlManifest.Input.xml speichert die Codekomponentenversion im Steuerelement:

<control namespace="..." constructor="..." version="1.0.0" display-name-key="..." description-key="..." control-type="...">

Beim Bereitstellen eines Updates für eine Codekomponente muss die Version in der ControlManifest.Input.xml mindestens einen inkrementierten PATCH (das ist der letzte Teil der Version) aufweisen, damit die Änderung erkannt wird. Dies kann entweder manuell erfolgen, indem das Versionsattribut direkt bearbeitet wird, oder indem Sie den folgenden Befehl verwenden, um die PATCH-Version um eins zu erhöhen:

pac pcf version --strategy manifest

Um einen genauen Wert für den PATCH-Teil anzugeben (z. B. als Teil einer automatisierten Buildpipeline), können Sie alternativ Folgendes verwenden:

pac pcf version --patchversion <PATCH VERSION>

Mehr Informationen: PAC-PCF-Version.

Wann sollte die Haupt- und Nebenversion erhöht werden?

Es wird empfohlen, die Haupt- und Nebenversion der Codekomponentenversion mit der Dataverse-Lösung synchron zu halten, mit der sie verteilt wird. Beispiel: ''

  1. Ihre bereitgestellte Codekomponentenversion ist 1.0.0 und Ihre Lösungsversion ist 1.0.0.0.
  2. Sie nehmen ein kleines Update an Ihrer Codekomponente vor und erhöhen die Patch-Version der Codekomponente mithilfe von pac pcf version --strategy manifest auf 1.0.1.
  3. Beim Verpacken der Codekomponente für die Bereitstellung wird die Lösungsversion in Solution.xml auf 1.0.0.1 aktualisiert, oder die Version wird automatisch erhöht, indem die Lösung manuell exportiert wird.
  4. Sie nehmen wesentliche Änderungen an Ihrer Lösung vor, sodass Sie unter Umständen die Haupt- und Nebenversion auf 1.1.0.0 erhöhen möchten.
  5. In diesem Fall kann die Codekomponentenversion auch auf 1.1.0 aktualisiert werden.

Eine Dataverse-Lösung besteht aus vier Teilen und Sie können sie sich als folgende Struktur vorstellen: MAJOR.MINOR.BUILD.REVISION.

Wenn Sie AzureDevOps verwenden, können Sie die Versionsverwaltung Ihrer Build-Pipeline mithilfe der Build- und Rev-Umgebungsvariablen festlegen (Ausführungs-(Build-)Nummer – Azure Pipelines). Außerdem können Sie ein PowerShell-Skript ähnlich dem im Artikel beschriebenen Ansatz verwenden Verwenden von PowerShell-Skripts zum Anpassen von Pipelines.

Teil der semantischen Version ControlManifest.Input.xml-Versionsteil
MAJOR.MINOR.PATCH		 Solution.xml-Versionsteil
MAJOR.MINOR.BUILD.REVISION		 AzureDevOps-Build-Version
HAUPTVERSION HAUPTVERSION HAUPTVERSION Sie können dies festlegen, indem Sie die Pipeline-Variable $(majorVersion) oder den Wert verwenden, der zuletzt an die Quellcodeverwaltung übergeben wurde.
NEBENVERSION NEBENVERSION NEBENVERSION Sie können dies festlegen, indem Sie die Pipeline-Variable $(minorVersion) oder den Wert verwenden, der zuletzt an die Quellcodeverwaltung übergeben wurde.
--- --- BUILD $(Build.BuildId)
PATCH PATCH REVISION $(Rev:r)

ALM-Überlegungen für Canvas-Apps

Die Verwendung von Codekomponenten in Canvas-Apps unterscheidet sich von der in modellgesteuerten Apps. Codekomponenten müssen der App explizit hinzugefügt werden, indem Sie Weitere Komponenten abrufen im Bereich Einfügen auswählen. Sobald die Codekomponente der Canvas-App hinzugefügt wurde, wird sie als Inhalt in die App-Definition aufgenommen. Um nach der Bereitstellung (und der Erhöhung der Verwaltungsversion) auf eine neue Version der Codekomponente zu aktualisieren, muss die App erstellende Person die App zuerst in Power Apps Studio öffnen und Aktualisieren auswählen, wenn sie im Dialog Codekomponenten aktualisieren dazu aufgefordert wird. Anschließend muss die App gespeichert und veröffentlicht werden, damit die neue Version beim Abspielen der App durch die Benutzer verwendet werden kann.

Aktualisieren von Codekomponenten.

Wenn die App nicht aktualisiert wird oder Überspringen verwendet wird, nutzt die App weiterhin die ältere Version der Codekomponente, obwohl diese in der Umgebung nicht vorhanden ist, da sie von der neueren Version überschrieben wurde.

Da die App eine Kopie der Codekomponente enthält, ist es daher möglich, verschiedene Versionen der Codekomponenten nebeneinander in einer einzigen Umgebung innerhalb verschiedener Canvas-Apps auszuführen. Es können jedoch nicht verschiedene Versionen einer Codekomponente nebeneinander in derselben App ausgeführt werden. Apps erstellende Personen werden ermutigt, ihre Apps auf die neueste Version der Codekomponenten zu aktualisieren, wenn eine neue Version bereitgestellt wird.

Hinweis

Obwohl Sie derzeit eine Canvas-App importieren können, ohne dass die entsprechende Codekomponente in dieser Umgebung bereitgestellt wird, wird empfohlen, dass Sie immer sicherstellen, dass die Apps aktualisiert werden, um die neueste Version der Codekomponenten zu verwenden, und dass dieselbe Version zuerst in dieser Umgebung oder als Teil derselben Lösung bereitgestellt wird.

Application Lifecycle Management (ALM) mit Microsoft Power Platform
Power Apps component framework-API-Referenz
Erstellen Sie Ihre erste Codekomponente
Debuggen von Code-Komponenten

Hinweis

Können Sie uns Ihre Präferenzen für die Dokumentationssprache mitteilen? Nehmen Sie an einer kurzen Umfrage teil. (Beachten Sie, dass diese Umfrage auf Englisch ist.)

Die Umfrage dauert etwa sieben Minuten. Es werden keine personenbezogenen Daten erhoben. (Datenschutzbestimmungen).