D365 F&SCM CI/CD mit Build-VM

In diesem Blogpost gehen wir durch den Prozess der Konfiguration des CI/CD für D365 F&SCM durch Build VM und Azure Devops Pipelines. Wir haben auch die Möglichkeit, CI zum Erstellen und Erstellen bereitstellbarer Pakete für x++-Modelle über von Azure gehostete Agents zu erreichen, die ich hier beschreibe.

Wir werden diese Reise in den folgenden 3 Schritten durchlaufen. Stellen Sie außerdem sicher, dass Sie den in diesem Blog definierten Prozess als Voraussetzung abschließen.

Bereitstellen/Konfigurieren einer Build-VM -> CI-Setup -> Build-/Release-Pipelines konfigurieren -> CD-Setup

Bereitstellen/Konfigurieren einer Build-VM

Der Artikel Entwicklungsumgebungen bereitstellen beschreibt, wie Entwicklerumgebungen bereitgestellt werden. Verwenden Sie den gleichen Ablauf, um eine Build-Umgebung bereitzustellen. Während Sie den Bereitstellungs- oder Konfigurationsassistenten durchlaufen, wenn Sie dazu aufgefordert werden Wählen Sie eine Topologie ausauswählen DevTest Wählen Sie dann a Bauen und testen Topologie.

Als Teil des Bereitstellungsassistenten können Sie den Build-Agent-Namen und den Build-Agent-Pool konfigurieren.

Klicken Erweiterte Einstellungenauswählen Azure DevOps/Visual Studio-Teamdienste, Geben Sie die folgenden Details ein:

  1. Build-Agent-Name: Anzeigename für den Build-Agent auf Azure DevOps, Sie können diesen wie den Umgebungsnamen beibehalten.
  2. Erstellen Sie einen Agentenpool: Geben Sie den Namen des Build-Agent-Pools an, der für die Bereitstellung der Build-Maschine verwendet werden soll. Standardmäßig gibt es den Standardpool. Der Agentenpool sollte in Ihrem Devops-Projekt erstellt werden, das mit LCS verknüpft ist. Um einen Agentenpool zu erstellen, gehen Sie zu Azure DevOps > Organisationseinstellungen > Agent-Pools > Hinzufügen

3. Filialname: Geben Sie Ihren Azure DevOps-Quellcodezweig an, der der standardmäßige Quellcode-Synchronisierungsspeicherort für die Build-VM sein wird. Der Standard-Zweig ist “Main”.

Klicken Sie auf Fertig. Fahren Sie mit der Bereitstellung der VM fort.

Wenn eine Build-VM bereitgestellt wird, ist sie vorkonfiguriert und bereit, einen Build zu starten. Es erstellt/aktualisiert den Hauptordner in Repos und erstellt eine Pipeline in Devops.

Zunächst finden Sie dort eine einzelne Pipeline namens „Unified Operations platform – Build Main“. Ich würde empfehlen, diese Pipeline als Vorlage zu behalten und Ihre benutzerdefinierten Pipelines zu erstellen, indem Sie sie klonen. Um die Pipeline zu bearbeiten, siehe unten, können Sie bestimmte Schritte deaktivieren oder neue Schritte hinzufügen.

Kontinuierliche Integration einrichten:

Mit der Pipeline, die als Teil der VM-Bereitstellung bereitgestellt wurde, haben wir den Luxus, eine kontinuierliche Integration durch Bearbeiten der Pipeline zu ermöglichen.

Aktivieren Sie die unten gezeigte Option, um Continuous Integration zu aktivieren. Unmittelbar nach dem Einchecken jedes Entwicklers in den Dev-Zweig wird ein Build in die Warteschlange gestellt und der Code kompiliert. Falls ein Kompilierungsfehler auftritt, werden wir darüber benachrichtigt. Natürlich bauen wir alle die Lösungen, bevor wir sie einchecken.

Ein Gated Check-in bedeutet, dass der Build-Agent eine automatische Kompilierung startet, BEVOR er den Code eincheckt. Wenn dies fehlschlägt, wird das Changeset nicht durchgeführt, bis die Fehler behoben und erneut eingecheckt wurden.

Sie können den Pipeline-Lauf auch zusammen mit CI planen, je nachdem, was Sie für richtig halten, oder sogar beides.

Release-Pipelines konfigurieren:

Wir haben Aufgaben veröffentlicht, die die CI/CD-Geschichte vervollständigen werden. Die erste Aufgabe besteht darin, das bereitstellbare Paket in die Asset-Bibliothek in LCS hochzuladen, und die zweite Aufgabe besteht darin, das bereitstellbare Paket auf eine beliebige Nicht-Produktionsumgebung anzuwenden. Inzwischen ist uns allen bewusst, dass Produktionsumgebungen von Microsoft verwaltet werden und alle bereitstellbaren Pakete als Release Candidates markiert werden müssen, um auf die Produktion angewendet zu werden.

Der erste Schritt besteht darin, eine App-Registrierung in Azure Active Directory zu erstellen, um das generierte bereitstellbare Paket in LCS hochzuladen. Gehen Sie zum Azure-Portal und gehen Sie nach der Anmeldung zu Azure ActiveDirectory, dann zu App-Registrierungen und erstellen Sie eine neue App:

Gehen Sie als Nächstes zu „Verwalten“ und „API-Berechtigungen“, um die Dynamics Lifecycle Services-API hinzuzufügen. Wählen Sie die Berechtigung „user_impersonation“ und klicken Sie dann auf die Schaltfläche „Berechtigungen erteilen“, um die Änderungen zu übernehmen.

Gehen Sie nach der Einrichtung zu Azure devops -> Pipelines -> Releases und erstellen Sie eine neue Release-Pipeline. Wählen Sie „Neue Release-Pipeline“ und dann „Leerer Job“ aus der Liste aus.

Dann sehen Sie einen erstellten Phasentitel „Stage1“. Klicken Sie oben auf die Schaltfläche Speichern, um die Pipeline zu speichern.

Auf der Artefakt Kontrollkästchen auswählen bauen die wir mit dieser Release-Definition verknüpfen werden

Dann klicken Sie auf Job1 und Aufgabe zum Agentenjob hinzufügen.

Suchen Sie nach Dynamics und wählen Sie es aus D365 Finanz- und Betriebstools und klicken Sie auf „Kostenlos herunterladen“.

Wählen Sie dann Ihr Devops-Team-Projekt aus, für das diese Tools installiert werden müssen.

Nachdem die Installation abgeschlossen ist, aktualisieren Sie Ihren Browser und kehren Sie zurück, um Ihre Release-Pipeline zu bearbeiten, bearbeiten Sie „Stage1“ und fügen Sie Task zu „Agent Job 1“ hinzu.

Der erste Schritt in der Aufgabe besteht darin, die Verbindung zu LCS mithilfe der zuvor erstellten AAD-App einzurichten. Drücken Sie Neu und füllen Sie die Felder aus. Die Anwendungs-ID ist die Client-ID der App, die Sie zuvor im Azure-Portal erstellt haben.

Es ist nur erforderlich, den Verbindungsnamen, den Benutzernamen und das Passwort aus den Feldern Benutzer- und Anwendungs-ID (Client-ID) einzugeben. Die Endpunktfelder sollten automatisch ausgefüllt werden. Abschließend drücken Sparen und die LCS-Verbindung ist bereit.

Verwenden Sie im Feld LCS-Projekt-ID die ID aus der LCS-Projekt-URL, zum Beispiel lautet das Projekt in https://lcs.dynamics.com/V2/ProjectOverview/1234567 1234567.

Klicken Sie auf die Schaltfläche neben „Datei zum Hochladen“ und wählen Sie die vom Build generierte bereitstellbare Paketdatei aus:

Wenn die Build-Definition nicht geändert wurde, hat das bereitstellbare Ausgabepaket einen Namen wie AXDeployableRuntime_VERSION_BUILDNUMBER.zip. Ändern Sie die feste Build-Nummer für die DevOps-Variable $(Build.BuildNumber) wie im Bild unten:

Erstellen Sie dann eine Ausgangsvariable um die Paket-ID zu erfassen und dynamisch an die nächste Aufgabe zu übergeben.

Fahren Sie dann mit der nächsten Aufgabe fortIn Umgebung bereitstellen“, um die Felder auszufüllen.

Der Umgebungsname kann von LCS abgerufen werden.

Der Name der LCS-Asset-ID ist die Ausgabevariable der vorherigen Aufgabe: $(OutputVariableName.FileAssetId) . Sobald Sie fertig sind, füllen Sie die Felder Speichern und Aufgaben und die Pipeline aus.

Eine letzte Sache, die Sie tun müssen, bevor wir Continuous Deployment abschließen, besteht darin, diese Option zu aktivieren, durch die diese Releasepipeline ausgeführt wird, wenn wir einen erfolgreichen Build haben.

Herzlichen Glückwunsch, Sie haben CI und CD für D365 F&SCM erfolgreich konfiguriert!!

Author: admin

Leave a Reply

Your email address will not be published.