Lernprogramm: Bereitstellen von Umgebungen in CI/CD mithilfe von GitHub- und Azure-Bereitstellungsumgebungen

In diesem Lernprogramm erfahren Sie, wie Sie Azure-Bereitstellungsumgebungen in Ihre CI/CD-Pipeline integrieren. Sie können jeden GitOps-Anbieter verwenden, der CI/CD unterstützt, z. B. GitHub-Aktionen, Azure Arc, GitLab oder Jenkins.

Continuous Integration und Continuous Delivery (CI/CD) ist ein Softwareentwicklungsansatz, mit dem Teams den Prozess zum Erstellen, Testen und Bereitstellen von Softwareänderungen automatisieren können. CI/CD ermöglicht es Ihnen, Softwareänderungen häufiger und mit mehr Vertrauen freizugeben.

Sie verwenden einen Workflow mit drei Verzweigungen: Haupt-, Entwicklungs- und Testfunktionen.

• Der Hauptzweig gilt immer als Produktion.
• Sie erstellen Feature-Verzweigungen aus der Hauptzweigung .
• Sie erstellen Pullanforderungen zum Zusammenführen von Funktionszweigen in den Hauptteil.

Der Workflow in diesem Lernprogramm ist ein vereinfachtes Beispiel. Reale Workflows sind möglicherweise komplexer.

Bevor Sie mit diesem Lernprogramm beginnen, können Sie sich mit Komponenten und Konzepten der Bereitstellungsumgebungen vertraut machen, indem Sie wichtige Konzepte für Azure-Bereitstellungsumgebungen überprüfen.

In diesem Tutorial erfahren Sie, wie:

• Erstellen und Konfigurieren eines Dev Centers
• Erstellen eines Schlüsseltresors
• Erstellen und Konfigurieren eines GitHub-Repositorys
• Verbinden des Katalogs mit Ihrem Dev Center
• Konfigurieren von Bereitstellungsidentitäten
• Konfigurieren von GitHub-Umgebungen
• Testen der CI/CD-Pipeline

Voraussetzungen

Produkt	Anforderungen
Azure	– Ein Azure-Abonnement. – Besitzerberechtigungen für das Azure-Abonnement. - Azure CLI installiert.
Git	- Ein GitHub-Konto. - Git installiert.

1. Erstellen und Konfigurieren eines Dev Centers

In diesem Abschnitt erstellen Sie ein Dev Center für Azure-Bereitstellungsumgebungen und ein Projekt mit drei Umgebungstypen: Dev, Test und Prod.

• Der Prod-Umgebungstyp enthält die einzelne Produktionsumgebung.
• Für jeden Featurezweig wird in Dev eine neue Umgebung erstellt.
• Für jede Pullanforderung wird eine neue Umgebung im Test erstellt.

1.1 Einrichten der Azure CLI

Melden Sie sich zunächst bei Azure an. Führen Sie den folgenden Befehl aus, und folgen Sie den Anweisungen, um den Authentifizierungsprozess abzuschließen:

az login

Installieren Sie als Nächstes die Azure Devcenter-Erweiterung für Azure CLI:

az extension add --name devcenter --upgrade

Nachdem die aktuelle Erweiterung installiert ist, registrieren Sie den Microsoft.DevCenter Namespace:

az provider register --namespace Microsoft.DevCenter

Tipp

In diesem Lernprogramm speichern Sie mehrere Werte als Umgebungsvariablen, die sie später verwenden können. Möglicherweise möchten Sie diese Werte auch an anderer Stelle aufzeichnen, um sicherzustellen, dass sie verfügbar sind, wenn Sie sie benötigen.

Rufen Sie Ihre Benutzer-ID ab, und legen Sie sie für später auf eine Umgebungsvariable fest:

MY_AZURE_ID=$(az ad signed-in-user show --query id -o tsv)

Abrufen der Abonnement-ID für Ihr aktuelles Abonnement:

AZURE_SUBSCRIPTION_ID=$(az account show --query id --output tsv)

Rufen Sie die Mandanten-ID für Ihren aktuellen Mandanten ab:

AZURE_TENANT_ID=$(az account show --query tenantId --output tsv)

Legen Sie die folgenden Umgebungsvariablen fest:

LOCATION="eastus"
AZURE_RESOURCE_GROUP=<resourceGroupName>
AZURE_DEVCENTER=<devcenterName>
AZURE_PROJECT=<projectName>
AZURE_KEYVAULT=<keyVaultName>

Hinweis

Sie müssen einen global eindeutigen Namen für Ihren Schlüsseltresor verwenden. Andernfalls wird möglicherweise die folgende Fehlermeldung angezeigt:

Code: VaultAlreadyExists Message: The vault name 'mykeyvaultname' is already in use. Vault names are globally unique so it is possible that the name is already taken.

1.2 Erstellen eines Dev Centers

Ein Dev Center ist eine Sammlung von Projekten und Umgebungen mit ähnlichen Einstellungen. Dev Center bieten Zugriff auf einen Katalog von Vorlagen und Artefakten, die zum Erstellen von Umgebungen verwendet werden können. Dev Center bieten auch eine Möglichkeit, den Zugriff auf Umgebungen und Projekte zu verwalten.

Erstellen Sie eine Ressourcengruppe:

az group create \
  --name $AZURE_RESOURCE_GROUP \
  --location $LOCATION

Erstellen eines Dev Centers:

az devcenter admin devcenter create \
  --name $AZURE_DEVCENTER \
  --identity-type SystemAssigned \
  --resource-group $AZURE_RESOURCE_GROUP \
  --location $LOCATION

Der vorherige Befehl gibt JSON aus. Speichern Sie die Werte für id und identity.principalId als Umgebungsvariablen, um sie später zu verwenden:

AZURE_DEVCENTER_ID=<id>
AZURE_DEVCENTER_PRINCIPAL_ID=<identity.principalId>

1.3 Weisen Sie die Rolle des Dev Center-Identitätsbesitzers für das Abonnement zu

Ein Dev Center benötigt Berechtigungen zum Zuweisen von Rollen für Abonnements, die Mit Umgebungstypen verknüpft sind.

Um unnötige Komplexität zu reduzieren, verwenden Sie in diesem Lernprogramm ein einzelnes Abonnement für das Dev Center und alle Umgebungstypen. In der Praxis wären die Entwicklungszentrum- und Zielbereitstellungs-Abonnements wahrscheinlich separate Abonnements, auf die unterschiedliche Richtlinien angewendet wurden.

az role assignment create \
  --scope /subscriptions/$AZURE_SUBSCRIPTION_ID \
  --role Owner \
  --assignee-object-id $AZURE_DEVCENTER_PRINCIPAL_ID \
  --assignee-principal-type ServicePrincipal

1.4 Erstellen der Umgebungstypen

Auf Dev Center-Ebene definieren Umgebungstypen die Umgebungen, die Entwicklungsteams erstellen können, z. B. Dev, Test, Sandbox, Preproduction und Produktion.

Erstellen Sie drei neue Umgebungstypen: Dev, Test und Prod:

az devcenter admin environment-type create \
  --name Dev \
  --resource-group $AZURE_RESOURCE_GROUP \
  --dev-center $AZURE_DEVCENTER

az devcenter admin environment-type create \
  --name Test \
  --resource-group $AZURE_RESOURCE_GROUP \
  --dev-center $AZURE_DEVCENTER

az devcenter admin environment-type create \
  --name Prod \
  --resource-group $AZURE_RESOURCE_GROUP \
  --dev-center $AZURE_DEVCENTER

1.5 Erstellen eines Projekts

Ein Projekt ist der Zugriffspunkt für das Entwicklungsteam. Jedes Projekt ist einem Dev Center zugeordnet.

Erstellen eines Projekts:

az devcenter admin project create \
  --name $AZURE_PROJECT \
  --resource-group $AZURE_RESOURCE_GROUP \
  --location $LOCATION \
  --dev-center-id $AZURE_DEVCENTER_ID

Der vorherige Befehl gibt JSON aus. Speichern Sie den id Wert als Umgebungsvariable, um später zu verwenden:

AZURE_PROJECT_ID=<id>

Weisen Sie sich selbst die DevCenter-Projektadministratorrolle für das Projekt zu:

az role assignment create \
  --scope "$AZURE_PROJECT_ID" \
  --role "DevCenter Project Admin" \
  --assignee-object-id $MY_AZURE_ID \
  --assignee-principal-type User

1.6 Erstellen von Projektumgebungstypen

Plattformingenieure geben auf Projektebene an, welche Umgebungstypen für das Entwicklungsteam geeignet sind.

Erstellen Sie einen neuen Projektumgebungstyp für jeden der Umgebungstypen, die Sie im Dev Center erstellt haben:

az devcenter admin project-environment-type create \
  --name Dev \
  --roles "{\"b24988ac-6180-42a0-ab88-20f7382dd24c\":{}}" \
  --deployment-target-id /subscriptions/$AZURE_SUBSCRIPTION_ID \
  --resource-group $AZURE_RESOURCE_GROUP \
  --location $LOCATION \
  --project $AZURE_PROJECT \
  --identity-type SystemAssigned \
  --status Enabled

az devcenter admin project-environment-type create \
  --name Test \
  --roles "{\"b24988ac-6180-42a0-ab88-20f7382dd24c\":{}}" \
  --deployment-target-id /subscriptions/$AZURE_SUBSCRIPTION_ID \
  --resource-group $AZURE_RESOURCE_GROUP \
  --location $LOCATION \
  --project $AZURE_PROJECT \
  --identity-type SystemAssigned \
  --status Enabled

az devcenter admin project-environment-type create \
  --name Prod \
  --roles "{\"b24988ac-6180-42a0-ab88-20f7382dd24c\":{}}" \
  --deployment-target-id /subscriptions/$AZURE_SUBSCRIPTION_ID \
  --resource-group $AZURE_RESOURCE_GROUP \
  --location $LOCATION \
  --project $AZURE_PROJECT \
  --identity-type SystemAssigned \
  --status Enabled

2. Erstellen eines Key Vault

In diesem Abschnitt erstellen Sie einen neuen Key Vault. Sie verwenden diesen Schlüsseltresor später im Lernprogramm, um ein persönliches Zugriffstoken von GitHub zu speichern.

az keyvault create \
  --name $AZURE_KEYVAULT \
  --resource-group $AZURE_RESOURCE_GROUP \
  --location $LOCATION \
  --enable-rbac-authorization true

Speichern Sie die id JSON-Ausgabe des vorherigen Befehls erneut als Umgebungsvariable:

AZURE_KEYVAULT_ID=<id>

Weisen Sie sich selbst die Rollte „Schlüsseltresor-Administrator“ im neuen Schlüsseltresor zu:

az role assignment create \
  --scope $AZURE_KEYVAULT_ID \
  --role "Key Vault Administrator" \
  --assignee-object-id $MY_AZURE_ID \
  --assignee-principal-type User

Weisen Sie der Dev Center-Identität die Rolle „Schlüsseltresor-Geheimnisbenutzer“ zu:

az role assignment create \
  --scope $AZURE_KEYVAULT_ID \
  --role "Key Vault Secrets User" \
  --assignee-object-id $AZURE_DEVCENTER_PRINCIPAL_ID \
  --assignee-principal-type ServicePrincipal

3. Erstellen und Konfigurieren eines GitHub-Repositorys

In diesem Abschnitt erstellen Sie ein neues GitHub-Repository zum Speichern eines Katalogs. Azure-Bereitstellungsumgebungen unterstützen sowohl GitHub- als auch Azure DevOps-Repositorys. In diesem Lernprogramm verwenden Sie GitHub.

3.1 Erstellen eines GitHub-Repositorys

In diesem Schritt erstellen Sie ein neues Repository in Ihrem GitHub-Konto, das über eine vordefinierte Verzeichnisstruktur, Verzweigungen und Dateien verfügt. Diese Elemente werden aus einem Beispielvorlagen-Repository generiert.

1. Generieren Sie ein neues GitHub-Repository aus der Beispielvorlage:

   

2. Wenn Sie nicht über ein kostenpflichtiges GitHub-Konto verfügen, legen Sie Ihr Repository auf "Öffentlich" fest.

3. Wählen Sie "Repository erstellen" aus.

3.2 Schützen der Hauptzweige des Repositorys

Sie können wichtige Branches schützen, indem Sie Branch-Regeln festlegen. Schutzregeln definieren, ob Projektmitwirkende eine Verzweigung löschen oder einen Pushvorgang zur Verzweigung erzwingen können. Sie legen auch Anforderungen für Pushvorgänge zur Verzweigung fest, z. B. das Übergeben von Statusprüfungen oder das Durchsetzen eines linearen Commitverlaufs.

Hinweis

Geschützte Branches sind in öffentlichen Repositorys mit GitHub Free und GitHub Free für Organisationen sowie in öffentlichen und privaten Repositorys mit GitHub Pro, GitHub Team, GitHub Enterprise Cloud und GitHub Enterprise Server verfügbar. Weitere Informationen finden Sie unter GitHub-Pläne.

1. Wenn sie noch nicht geöffnet ist, wechseln Sie zur Hauptseite Ihres Repositorys.

2. Wählen Sie "Einstellungen" im Menü oben im Fenster aus:

   

3. Wählen Sie im Abschnitt Code und Automatisierung der linken Randleiste Zweige aus:

   

4. Wählen Sie unter Branch-Schutzregeln die Option "Branch-Regelsatz hinzufügen" aus:

   

5. Geben Sie auf der Seite New branch ruleset im Feld Ruleset Name den Begriff CI-CD-tutorial-ruleset ein:

   

6. Wählen Sie unter "Zielverzweigungen" die Option " Ziel hinzufügen" und dann entweder "Standardverzweigung einschließen " oder "Alle Verzweigungen einschließen" aus:

   

7. Wählen Sie unter Verzweigungsregeln die Option Eine Pull-Anfrage ist erforderlich vor dem Zusammenführen aus:

   

8. Optional können Sie weitere Schutzregeln aktivieren.

9. Wählen Sie "Erstellen" aus.

3.3 Repositoryvariablen konfigurieren

1. Wählen Sie im Abschnitt "Sicherheit " der Randleiste "Geheime Schlüssel" und "Variablen" und dann "Aktionen" aus:

   

2. Wählen Sie die Registerkarte "Variablen" aus .

3. Für jedes Element in der folgenden Tabelle:

   1. Wählen Sie Neue Repositoryvariable aus.
   2. Geben Sie im Feld "Name " den Variablennamen ein.
   3. Geben Sie im Feld "Wert " den in der Tabelle beschriebenen Wert ein.
   4. Wählen Sie "Variable hinzufügen" aus.

   Variablenname	Variabler Wert
   AZURE_DEVCENTER	Ihr Dev Center-Name
   AZURE_PROJECT	Ihr Projektname
   AZURE_CATALOG	Auf Umgebungen festlegen
   AZURE_CATALOG_ITEM	Auf FunctionApp festlegen
   AZURE_SUBSCRIPTION_ID	Ihre Azure-Abonnement-ID
   AZURE_TENANT_ID	Ihre Azure-Mandanten-ID

   

3.4 Erstellen eines persönlichen GitHub-Zugriffstokens

Erstellen Sie als Nächstes ein differenziertes persönliches Zugriffstoken , damit Ihr Dev Center für Azure-Bereitstellungsumgebungen eine Verbindung mit Ihrem Repository herstellen und den Umgebungskatalog nutzen kann.

Hinweis

Sie können Feedback zu fein abgestimmten persönlichen Zugriffstoken in der Feedbackdiskssion hinterlassen.

1. Wählen Sie in der oberen rechten Ecke einer beliebigen Seite auf GitHub.com Ihr Profilfoto aus, und wählen Sie dann "Einstellungen" aus.

2. Wählen Sie in der linken Randleiste "Entwicklereinstellungen" aus.

3. Wählen Sie in der linken Randleiste unter "Persönliche Zugriffstoken" feinkörnige Token aus, und wählen Sie dann "Neues Token generieren" aus:

   

4. Geben Sie auf der Seite "Neues fein abgestuftes persönliches Zugriffstoken" unter "Tokenname" einen Namen für das Token ein.

5. Wählen unter Ablauf ein Ablaufdatum für das Token aus.

6. Wählen Sie unter "Ressourcenbesitzer" Ihren GitHub-Benutzernamen aus.

7. Wählen Sie unter Repositoryzugriff die Option Nur ausgewählte Repositories aus. Suchen Sie unter "Ausgewählte Repositorys" nach dem erstellten Repository, und wählen Sie es aus:

   

8. Wählen Sie unter Berechtigungen die Option Repositoryberechtigungen aus und ändern Sie dann Inhalt in Schreibgeschützt um.

   

9. Wählen Sie "Token generieren" aus.

10. Kopieren und speichern Sie Ihr persönliches Zugriffstoken. Sie werden es nicht mehr ansehen können.

3.5 Speichern Ihres persönlichen Zugriffstokens im Schlüsselarchiv

Speichern Sie als Nächstes das persönliche Zugriffstoken als Schlüsselvault-Geheimnis namens pat:

az keyvault secret set \
    --name pat \
    --vault-name $AZURE_KEYVAULT \
    --value <personalAccessToken>

4. Verbinden des Katalogs mit Ihrem Dev Center

In Azure-Bereitstellungsumgebungen ist ein Katalog ein Repository, das eine Reihe von Umgebungsdefinitionen enthält. Katalogelemente bestehen aus einer IaC-Vorlage (Infrastructure-as-Code) und einer Umgebungsdatei, die als Manifest fungiert. Die Vorlage definiert die Umgebung, und die Umgebungsdatei stellt Metadaten zur Vorlage bereit. Entwicklungsteams verwenden Umgebungsdefinitionen aus dem Katalog, um Umgebungen zu erstellen.

Die Vorlage, die Sie zum Erstellen Ihres GitHub-Repositorys verwendet haben, enthält einen Katalog im Ordner "Umgebungen ".

Hinzufügen des Katalogs zu Ihrem Dev Center

Ersetzen Sie < Organization/Repository > im folgenden Befehl durch den Namen Ihrer GitHub-Organisation und Ihres Repositorys:

az devcenter admin catalog create \
    --name Environments \
    --resource-group $AZURE_RESOURCE_GROUP \
    --dev-center $AZURE_DEVCENTER \
    --git-hub path="/Environments" branch="main" secret-identifier="https://$AZURE_KEYVAULT.vault.azure.net/secrets/pat" uri="https://github.com/< Organization/Repository >.git"

5. Konfigurieren von Bereitstellungsidentitäten

OpenID Connect mit GitHub-Aktionen ist eine Authentifizierungsmethode, die kurzlebige Token verwendet, um die Sicherheit zu gewährleisten. Es ist die empfohlene Methode zum Authentifizieren von GitHub-Aktionen bei Azure.

Sie können einen Dienstprinzipal auch direkt mithilfe eines Secrets authentifizieren. Dies ist jedoch nicht Gegenstand dieses Tutorials.

5.1 Generieren von Bereitstellungsidentitäten

1. Registrieren Sie Microsoft Entra-Anwendungen und Dienstprinzipale für jeden der drei Umgebungstypen.

   Erstellen Sie die Microsoft Entra-Anwendung für Dev:

   az ad app create --display-name "$AZURE_PROJECT-Dev"
   

   Dieser Befehl gibt JSON mit einem id aus, den Sie beim Erstellen von Verbundanmeldeinformationen mit der Graph API verwenden, und einer appId (auch als Client-ID bezeichnet).

   Legen Sie die folgenden Umgebungsvariablen fest:

   DEV_AZURE_CLIENT_ID=<appId>
   DEV_APPLICATION_ID=<id>
   

   Wiederholen Sie die folgenden Schritte für "Test":

   az ad app create --display-name "$AZURE_PROJECT-Test"
   

   TEST_AZURE_CLIENT_ID=<appId>
   TEST_APPLICATION_ID=<id>
   

   Wiederholen Sie die Schritte erneut für Prod:

   az ad app create --display-name "$AZURE_PROJECT-Prod"
   

   PROD_AZURE_CLIENT_ID=<appId>
   PROD_APPLICATION_ID=<id>
   

2. Erstellen Sie einen Dienstprinzipal für jede Anwendung.

   Führen Sie den folgenden Befehl aus, um einen neuen Dienstprinzipal für Dev zu erstellen:

    az ad sp create --id $DEV_AZURE_CLIENT_ID
   

   Dieser Befehl generiert eine JSON-Ausgabe mit einer anderen id , die im nächsten Schritt verwendet wird.

   Legen Sie die folgende Umgebungsvariable fest:

   DEV_SERVICE_PRINCIPAL_ID=<id>
   

   Wiederholen Sie die folgenden Schritte für "Test":

    az ad sp create --id $TEST_AZURE_CLIENT_ID
   

   TEST_SERVICE_PRINCIPAL_ID=<id>
   

   Wiederholen Sie die Schritte erneut für Prod:

    az ad sp create --id $PROD_AZURE_CLIENT_ID
   

   PROD_SERVICE_PRINCIPAL_ID=<id>
   

3. Führen Sie die folgenden Befehle aus, um für jede Microsoft Entra-Anwendung eine neue Verbundidentitäts-Anmeldeinformationen zu erstellen .

   Ersetzen Sie < Organization/Repository > in jedem der drei folgenden Befehle mit dem Namen Ihrer GitHub-Organisation und des Repositorys.

   Erstellen Sie die Verbundidentitätsanmeldeinformationen für Dev:

   az rest --method POST \
       --uri "https://graph.microsoft.com/beta/applications/$DEV_APPLICATION_ID/federatedIdentityCredentials" \
       --body '{"name":"ADEDev","issuer":"https://token.actions.githubusercontent.com","subject":"repo:< Organization/Repository >:environment:Dev","description":"Dev","audiences":["api://AzureADTokenExchange"]}'
   

   Erstellen Sie die Anmeldeinformationen für Test:

   az rest --method POST \
       --uri "https://graph.microsoft.com/beta/applications/$TEST_APPLICATION_ID/federatedIdentityCredentials" \
       --body '{"name":"ADETest","issuer":"https://token.actions.githubusercontent.com","subject":"repo:< Organization/Repository >:environment:Test","description":"Test","audiences":["api://AzureADTokenExchange"]}'
   

   Erstellen Sie die Anmeldeinformationen für Prod:

   az rest --method POST \
       --uri "https://graph.microsoft.com/beta/applications/$PROD_APPLICATION_ID/federatedIdentityCredentials" \
       --body '{"name":"ADEProd","issuer":"https://token.actions.githubusercontent.com","subject":"repo:< Organization/Repository >:environment:Prod","description":"Prod","audiences":["api://AzureADTokenExchange"]}'
   

5.2 Zuweisen von Rollen zu Bereitstellungsidentitäten

1. Weisen Sie jeder Bereitstellungsidentität die Rolle „Leser“ für das Projekt zu:

   az role assignment create \
       --scope "$AZURE_PROJECT_ID" \
       --role Reader \
       --assignee-object-id $DEV_SERVICE_PRINCIPAL_ID \
       --assignee-principal-type ServicePrincipal
   

   az role assignment create \
       --scope "$AZURE_PROJECT_ID" \
       --role Reader \
       --assignee-object-id $TEST_SERVICE_PRINCIPAL_ID \
       --assignee-principal-type ServicePrincipal
   

   az role assignment create \
       --scope "$AZURE_PROJECT_ID" \
       --role Reader \
       --assignee-object-id $PROD_SERVICE_PRINCIPAL_ID \
       --assignee-principal-type ServicePrincipal
   

2. Weisen Sie die Rolle "Deployment Environments User" dem entsprechenden Umgebungstyp jeder Bereitstellungsidentität zu:

   az role assignment create \
       --scope "$AZURE_PROJECT_ID/environmentTypes/Dev" \
       --role "Deployment Environments User" \
       --assignee-object-id $DEV_SERVICE_PRINCIPAL_ID \
       --assignee-principal-type ServicePrincipal
   

   az role assignment create \
       --scope "$AZURE_PROJECT_ID/environmentTypes/Test" \
       --role "Deployment Environments User" \
       --assignee-object-id $TEST_SERVICE_PRINCIPAL_ID \
       --assignee-principal-type ServicePrincipal
   

   az role assignment create \
       --scope "$AZURE_PROJECT_ID/environmentTypes/Prod" \
       --role "Deployment Environments User" \
       --assignee-object-id $PROD_SERVICE_PRINCIPAL_ID \
       --assignee-principal-type ServicePrincipal
   

6. Konfigurieren von GitHub-Umgebungen

Mit GitHub-Umgebungen können Sie Umgebungen mit Schutzregeln und geheimen Schlüsseln konfigurieren. Ein Workflowauftrag, der auf eine Umgebung verweist, muss alle Schutzregeln für diese Umgebung befolgen, ehe er ausgeführt wird oder auf die Geheimnisse der Umgebung zugreift.

Erstellen Sie Entwicklungs-, Test- und Prod-Umgebungen , die den Umgebungstypen im Azure Deployment Environments-Projekt zugeordnet sind.

Hinweis

Umgebungen, Umgebungsgeheimnisse und Umgebungsschutzregeln sind in öffentlichen Repositories für alle Produkte verfügbar. Für den Zugriff auf Umgebungen, geheime Umgebungsschlüssel und Bereitstellungszweige in privaten oder internen Repositorys müssen Sie GitHub Pro, GitHub Team oder GitHub Enterprise verwenden. Für den Zugriff auf andere Umgebungsschutzregeln in privaten oder internen Repositorys müssen Sie GitHub Enterprise verwenden. Weitere Informationen finden Sie unter GitHub-Pläne.

6.1 Erstellen der Entwicklungsumgebung

1. Wechseln Sie in GitHub zur Hauptseite Ihres Repositorys.

2. Wählen Sie unter dem Namen Ihres Repositorys settings. Wenn die Registerkarte "Einstellungen " nicht angezeigt wird, wählen Sie das Dropdownmenü "... " und dann " Einstellungen" aus.

3. Wählen Sie in der linken Randleiste "Umgebungen" aus.

4. Wählen Sie "Neue Umgebung" aus, und geben Sie "Dev " für den Namen der Umgebung ein, und wählen Sie dann " Umgebung konfigurieren" aus:

   

5. Wählen Sie unter "Geheime Umgebung" die Option "Umgebungsgeheimnis hinzufügen" aus, und geben Sie dann im Feld "Name" AZURE_CLIENT_ID ein.

   

6. Geben Sie im Feld "Wert " die Client-ID (appId) für die Zuvor erstellte Dev Microsoft Entra-App ein (gespeichert als $DEV_AZURE_CLIENT_ID Umgebungsvariable):

   

7. Wählen Sie "Geheimen Schlüssel hinzufügen" aus.

6.2 Erstellen der Testumgebung

Kehren Sie zur Hauptseite der Umgebungen zurück, indem Sie " Umgebungen " in der linken Randleiste auswählen.

1. Wählen Sie "Neue Umgebung" aus, geben Sie "Test für den Namen der Umgebung" ein, und wählen Sie dann " Umgebung konfigurieren" aus.

2. Wählen Sie unter "Geheime Umgebung" die Option "Umgebungsgeheimnis hinzufügen" aus, und geben Sie dann im Feld "Name" AZURE_CLIENT_ID ein.

3. Geben Sie im Feld "Wert" die Client-ID () für die zuvor erstellte Microsoft Entra-App "appId" ein (gespeichert als $TEST_AZURE_CLIENT_ID Umgebungsvariable).

4. Wählen Sie "Geheimen Schlüssel hinzufügen" aus.

6.3 Erstellen der Prod-Umgebung

Kehren Sie erneut zur Hauptseite der Umgebungen zurück, indem Sie " Umgebungen " in der linken Randleiste auswählen.

1. Wählen Sie "Neue Umgebung" aus, geben Sie "Prod " für den Namen der Umgebung ein, und wählen Sie dann " Umgebung konfigurieren" aus.

2. Wählen Sie unter "Geheime Umgebung" die Option "Umgebungsgeheimnis hinzufügen" aus, und geben Sie dann im Feld "Name" AZURE_CLIENT_ID ein.

3. Geben Sie im Feld "Wert " die Client-ID (appId) für die Zuvor erstellte Prod Microsoft Entra-App ein (gespeichert als $PROD_AZURE_CLIENT_ID Umgebungsvariable).

4. Wählen Sie "Geheimen Schlüssel hinzufügen" aus.

Legen Sie sich als Nächstes als erforderlicher Prüfer für diese Umgebung fest. Wenn versucht wird, die Bereitstellung für Prod durchzuführen, wartet GitHub Actions vor dem Start auf eine Genehmigung. Während ein Auftrag auf die Genehmigung wartet, hat er den Status " Warten". Wenn ein Auftrag nicht innerhalb von 30 Tagen genehmigt wird, schlägt er automatisch fehl.

Weitere Informationen zu Umgebungen und erforderlichen Genehmigungen finden Sie unter Verwenden von Umgebungen für die Bereitstellung.

1. Wähle Required reviewers aus.

2. Suchen Sie nach Ihrem GitHub-Benutzernamen, und wählen Sie sie aus. Sie können bis zu sechs Personen oder Teams eingeben. Nur einer der erforderlichen Reviewer muss den Auftrag genehmigen, damit er fortgesetzt werden kann.

3. Wählen Sie "Schutzregeln speichern" aus.

Konfigurieren Sie main schließlich als Bereitstellungszweig:

1. Wählen Sie in der Liste Bereitstellungsverzweigungen und Tags die Option Ausgewählte Verzweigungen und Tags aus.

2. Wählen Sie "Bereitstellungsbranch- oder Tagregel hinzufügen", stellen Sie sicher, dass "Ref-Typ: Branch" ausgewählt ist, und geben Sie dann main im Name-Muster Feld ein.

3. Wählen Sie "Regel hinzufügen" aus.

7. Testen der CI/CD-Pipeline

In diesem Abschnitt nehmen Sie einige Änderungen am Repository vor und testen die CI/CD-Pipeline.

7.1 Klonen des Repositorys

1. In Git Bash verwenden Sie cd, um zu einem Ordner zu wechseln, in dem Sie Ihr Repository lokal klonen möchten.

2. Klonen Sie das Repository. Ersetzen Sie den folgenden Befehl unbedingt < Organization/Repository > durch Ihren GitHub-Organisations- und Repositorynamen.

   git clone https://github.com/< Organization/Repository >.git
   

3. Navigieren Sie zum geklonten Verzeichnis:

   cd <repository>
   

4. Erstellen Sie eine neue Verzweigung, und veröffentlichen Sie sie remote:

   git checkout -b feature1
   

   git push -u origin feature1
   

   In Azure wird eine neue Umgebung erstellt, die spezifisch für diese Verzweigung ist.

5. Wechseln Sie in GitHub zur Hauptseite Ihres neu erstellten Repositorys.

6. Wählen Sie unter Ihrem Repositorynamen "Aktionen" aus:

   Sie sollten sehen, dass ein neuer Workflow „Umgebung erstellen“ ausgeführt wird.

7.2 Ändern des Codes

1. Öffnen Sie das lokal geklonte Repository in Visual Studio Code.

2. In dem ADE.Tutorial Ordner, nehmen Sie eine Änderung an einer Datei vor.

3. Speichern Sie die Änderung.

7.3 Pushen Sie Ihre Änderungen, um die Umgebung zu aktualisieren.

1. Testen Sie Ihre Änderungen, und übertragen Sie diese an die feature1-Verzweigung:

   git add .
   git commit -m '<commit message>'
   git push
   

2. Auf der Seite "Actions" Ihres Repositorys wird ein neuer Umgebungsaktualisierungs-Workflow ausgeführt.

7.4 Erstellen einer Pullanforderung

1. Erstellen Sie eine GitHub-Pull-Anforderung main <- feature1.

2. Auf der Seite "Aktionen " Ihres Repositorys sehen Sie, dass ein neuer Workflow gestartet wird, um eine Umgebung zu erstellen, die für die Pullanforderung spezifisch ist. Der Testumgebungstyp wird verwendet.

7.5 Zusammenführen der Pullanforderung

1. Wechseln Sie in GitHub zu der von Ihnen erstellten Pull-Anforderung.

2. Führe die Pull Request zusammen.

   Ihre Änderungen werden in der Produktionsumgebung veröffentlicht und die Branch- und Pull Request-Umgebungen werden gelöscht.

Bereinigen von Ressourcen

Wenn Sie die erstellten Ressourcen nicht mehr benötigen, löschen Sie sie, damit Ihnen keine weiteren Kosten entstehen. Wenn Sie die Beispielanwendung in einer anderen Ressourcengruppe bereitgestellt haben, müssen die folgenden Schritte ggf. wiederholt werden.

So löschen Sie Ressourcen über das Azure-Portal:

1. Wählen Sie im Portal links oben die Menüschaltfläche und dann Ressourcengruppen aus.

2. Wählen Sie in der Liste die Ressourcengruppe aus, die Sie erstellt haben.

3. Wählen Sie die Option Ressourcengruppe löschen.

4. Geben Sie den Ressourcengruppennamen ein. Wählen Sie anschließend die Option Löschen.

Um Ressourcen mithilfe des Azure CLI löschen, geben Sie den folgenden Befehl ein:

az group delete --name <my-dev-center-rg>

Denken Sie daran, dass beim Löschen der Ressourcengruppe alle darin enthaltenen Ressourcen gelöscht werden.

Verwandte Inhalte

• Erstellen einer Umgebung und Zugreifen darauf mithilfe der Azure-Befehlszeilenschnittstelle
• Vollständige Befehlsauflistungen finden Sie in der Azure CLI-Dokumentation zu Microsoft Dev Box und Azure Deployment Environments