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

Artikel
12/12/2023

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, wie GitHub Actions, Azure Arc, GitLab oder Jenkins.

Continuous Integration und Continuous Delivery (CI/CD) ist ein Softwareentwicklungsansatz, mit dem Teams den Prozess des Erstellens, Testens und Bereitstellens von Softwareänderungen automatisieren können. CI/CD ermöglicht es Ihnen, Softwareänderungen häufiger und mit größerer Sicherheit zu veröffentlichen.

Sie verwenden einen Workflow mit drei Branches: Main, Dev und Test.

Der Mainbranch wird immer als Produktion betrachtet.
Sie erstellen Funktionsbranches über den Mainbranch.
Sie erstellen Pull Requests, um Funktionsbranches im Main zu mergen.

Dieser Workflow ist ein kleines Beispiel für die Zwecke dieses Tutorials. Reale Workflows sind möglicherweise komplexer.

Bevor Sie mit diesem Tutorial beginnen, können Sie sich anhand des Artikels Schlüsselkonzepte für Azure Deployment Environments mit den Ressourcen und Konzepten von Bereitstellungsumgebungen vertraut machen.

In diesem Tutorial lernen Sie Folgendes:

Erstellen und Konfigurieren eines Dev Center
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

Ein Azure-Konto mit einem aktiven Abonnement.
- Sie können kostenlos ein Konto erstellen.
Besitzerberechtigungen für das Azure-Abonnement
Ein GitHub-Konto.
- Falls Sie noch nicht über ein Konto verfügen, können Sie sich kostenlos registrieren.
Installieren Sie Git.
Installieren Sie die Azure CLI.

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 jede Featurebranch 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 befolgen Sie die Anweisungen, um den Authentifizierungsprozess abzuschließen.

az login

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

az extension add --name devcenter --upgrade

Nachdem jetzt die aktuelle Erweiterung installiert wurde, registrieren Sie den Namespace Microsoft.DevCenter.

az provider register --namespace Microsoft.DevCenter

Tipp

In diesem Tutorial werden Sie mehrere Werte als Umgebungsvariablen für die spätere Verwendung speichern. Möglicherweise möchten Sie diesen Wert auch an anderer Stelle aufzeichnen, um sicherzustellen, dass sie bei Bedarf verfügbar sind.

Rufen Sie die ID Ihres Benutzers ab, und legen Sie diese auf eine Umgebungsvariable fest für späteren Gebrauch:

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

Rufen Sie die Abonnement-ID für Ihr aktuelles Abonnement ab.

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 Schlüsseltresornamen 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, die ähnliche Einstellungen haben. Dev Centers bieten Zugriff auf einen Katalog von Vorlagen und Artefakten, die zum Erstellen von Umgebungen verwendet werden können. Dev Centers 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 Sie ein neues Dev Center.

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, die später verwendet werden können.

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

1.3 Zuweisen der Rolle „Dev Center-Identitätsbesitzer“ im Abonnement

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

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

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. Entwicklung, Test, Sandbox, Vorproduktion oder 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 Entwicklungsteams. Jedes Projekt ist einem Dev Center zugeordnet.

Erstelle ein neues Projekt.

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 eine Umgebungsvariable für die spätere Verwendung.

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

Auf Projektebene geben Plattformtechniker*innen 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 Schlüsseltresors

In diesem Abschnitt erstellen Sie einen neuen Schlüsseltresor. Sie verwenden diesen Schlüsseltresor später im Tutorial, 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 auch hier die id aus der JSON-Ausgabe des vorherigen Befehls als Umgebungsvariable.

AZURE_KEYVAULT_ID=<id>

Geben Sie sich die Rolle "Key Vault-Administrator" im neuen Schlüsseltresor.

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 Identität des Dev Centers die Rolle des Schlüsseltresor-Schlüsselbenutzers 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 Deployment Environments unterstützen sowohl GitHub- als auch Azure DevOps-Repositorys. In diesem Tutorial verwenden Sie GitHub.

3.1 Erstellen eines neuen GitHub-Repositorys

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

Verwenden Sie diesen Link, um ein neues GitHub-Repository aus der Beispielvorlage zu generieren.
Wenn Sie über kein kostenpflichtiges GitHub-Konto verfügen, legen Sie Ihr Repository auf Öffentlich fest.
Wählen Sie Create repository from template (Repository aus Vorlage erstellen) aus.
Beachten Sie auf der Registerkarte Aktionen , dass bei der Aktion „Umgebung erstellen“ ein Fehler auftritt. Dieses Verhalten ist erwartet, Sie können mit dem nächsten Schritt fortfahren.

3.2 Schützen des Mainbranch des Repositorys

Sie können wichtige Branches schützen, indem Sie Branchschutzregeln festlegen. Schutzregeln definieren, ob Projektmitarbeiter den Branch löschen oder das Pushen in den Branch erzwingen können. Sie legen auch Anforderungen für alle Pushvorgänge an den Branch fest, z. B. das Übergeben von Statusprüfungen oder einen linearen Commitverlauf.

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-Produkte.

Navigieren Sie zur Hauptseite Ihres Repositorys, wen sie noch nicht geöffnet ist.
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.
Wählen Sie auf der Randleiste im Abschnitt Code und Automatisierungdie Option Branches aus.
Wählen Sie unter Branch-Schutzregeln die Option Branch-Schutzregel hinzufügen aus.
Geben Sie unter "Verzweigungsnamenmuster" die Zeichenfolge mainein.
Wählen Sie unter Übereinstimmende Branches schützen die Option Pull Request vor dem Zusammenführen anfordern aus.
Optional können Sie weitere Schutzregeln aktivieren.
Klicken Sie auf Erstellen.

3.3 Konfigurieren von Repositoryvariablen

Hinweis

Konfigurationsvariablen für GitHub Actions befinden sich in der Betaversion und können sich ändern.

Wählen Sie im Abschnitt Sicherheit der Randleiste die Option Geheimnisse und Variablen und dann Aktionen aus.
Wählen Sie die Registerkarte Variablen aus.

Für jedes Element in der Tabelle:

Wählen Sie Neue Repositoryvariable aus.
Geben Sie in das Feld Name den Namen der Variable ein.
Geben Sie in das Feld Wert den in der Tabelle beschriebenen Wert ein.
Wählen Sie Variable hinzufügen aus.

Variablenname	Variablenwert
AZURE_DEVCENTER	Ihr Dev Center-Name
AZURE_PROJECT	Ihr Projektname
AZURE_CATALOG	Auf "Umgebungen" festlegen
AZURE_CATALOG_ITEM	Auf "FunctionApp" festgelegt
AZURE_SUBSCRIPTION_ID	ID Ihres Azure-Abonnements
AZURE_TENANT_ID	Ihre Azure-Mandanten-ID

3.4 Erstellen eines persönlichen GitHub-Zugriffstokens

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

Hinweis

Das feingranulare persönliche Zugriffstoken befindet sich derzeit in der Betaversion und kann sich ändern. Um Feedback zu hinterlassen, lesen Sie Feedbackdiskussion.

Wählen Sie in der oberen rechten Ecke einer beliebigen Seite auf GitHub.com Ihre Profilfoto und dann Einstellungen aus.
Wählen Sie auf der linken Seitenleiste Entwicklereinstellungen aus.
Wählen Sie auf der linken Randleiste unter Persönliche Zugriffstoken die Option Feingranulare Token und dann Neues Token generieren aus.
Geben Sie auf der Seite "Neues persönliches Zugriffstoken " unter "Tokenname" einen Namen für das Token ein.
Wählen unter Ablauf ein Ablaufdatum für das Token aus.
Wählen Sie unter Ressourcenbesitzer Ihren GitHub-Benutzer aus.
Wählen Sie unter Repositoryzugriff die Option Nur Repositorys auswählen aus, und suchen Sie dann in der Dropdownliste Ausgewählte Repositorys nach dem Repository, das Sie erstellt haben, und wählen Sie es aus.
Wählen Sie unter Berechtigungen die Option Repositoryberechtigungen aus, und ändern Sie Inhalt in Schreibgeschützt.
Wählen Sie Generate token (Token generieren) aus.
Kopieren und speichern Sie jetzt Ihr persönliches Zugriffstoken. Sie können sie nicht mehr anzeigen.

3.5 Speichern Ihres persönlichen Zugriffstokens im Schlüsseltresor

Speichern Sie als Nächstes das persönliche Zugriffstoken als Schlüsseltresorschlüssel namens Pat.

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

4. Verbinden des Katalogs mit Ihrem Dev Center

In Azure Deployment Environments ist ein Katalog ein Repository, das eine Reihe von Umgebungsdefinitionen enthält. Katalogelemente bestehen aus einer Infrastruktur als Codevorlage (IaC) 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 eines Katalogs zu Ihrem Dev Center

Ersetzen Sie im folgenden Befehl < Organization/Repository > durch Ihre GitHub-Organisation und den Repositorynamen.

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 Actions ist eine Authentifizierungsmethode, die kurzlebige Token verwendet, um gehärtete Sicherheit zu bieten. Dies ist die empfohlene Methode zur Authentifizierung von GitHub Actions bei Azure.

Sie können einen Dienstprinzipal auch direkt mithilfe eines geheimen Schlüssels authentifizieren, aber das ist außerhalb des Gültigkeitsbereichs für dieses Lernprogramm.

5.1 Generieren von Bereitstellungsidentitäten

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 einer id aus, die Sie beim Erstellen von Verbundanmeldeinformationen mit Graph-API verwenden, und eine appId (auch als Client-ID bezeichnet).

Legen Sie die folgenden Umgebungsvariablen fest:
```
DEV_AZURE_CLIENT_ID=<appId>
DEV_APPLICATION_ID=<id>
```
Wiederholen Sie den Test.
```
az ad app create --display-name "$AZURE_PROJECT-Test"
```
```
TEST_AZURE_CLIENT_ID=<appId>
TEST_APPLICATION_ID=<id>
```
Und für Prod.
```
az ad app create --display-name "$AZURE_PROJECT-Prod"
```
```
PROD_AZURE_CLIENT_ID=<appId>
PROD_APPLICATION_ID=<id>
```
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 einem anderen id und wird im nächsten Schritt verwendet.

Legen Sie die folgenden Umgebungsvariablen fest:
```
DEV_SERVICE_PRINCIPAL_ID=<id>
```
Wiederholen Sie den Test.
```
 az ad sp create --id $TEST_AZURE_CLIENT_ID
```
```
TEST_SERVICE_PRINCIPAL_ID=<id>
```
Und für Prod.
```
 az ad sp create --id $PROD_AZURE_CLIENT_ID
```
```
PROD_SERVICE_PRINCIPAL_ID=<id>
```

Führen Sie die folgenden Befehle aus, um neue Anmeldeinformationen für die Verbundidentität für jede Active Directory-Anwendung zu erstellen.

Ersetzen Sie in jedem der drei Befehle < Organization/Repository > durch Ihre GitHub-Organisation und den Repositorynamen.

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"]}'

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"]}'

Und 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

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

Weisen Sie jeder Bereitstellungsidentität die Rolle "Deployment Environments User" dem entsprechenden Umgebungstyp 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 Geheimnissen 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 Repositorys für alle Produkte verfügbar. Für den Zugriff auf Umgebungen, Umgebungsgeheimnisse und Bereitstellungsbranches 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-Produkte.

6.1 Erstellen der Dev-Umgebung

Wechseln Sie auf GitHub zur Hauptseite Ihres Repositorys.
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.
Wählen Sie in der linken Seitenleiste Umgebungen aus.
Wählen Sie Neue Umgebung aus, geben Sie Dev als Umgebungsnamen ein, und wählen Sie dann Umgebung konfigurieren aus.
Wählen Sie unter Umgebungsgeheimnis die Option Geheimnis hinzufügen aus, und geben Sie AZURE_CLIENT_ID ein für Name.
Geben Sie für "Wert" die Client-ID () für die zuvor erstellte *Dev**Microsoft Entra-App einappId (gespeichert als $DEV_AZURE_CLIENT_ID Umgebungsvariable).
Klicken Sie auf Add secret (Geheimnis hinzufügen).

6.2 Erstellen der Test-Umgebung

Kehren Sie zur Seite „Main-Umgebungen“ zurück, indem Sie in der linken Randleiste Umgebungen auswählen.

Wählen Sie Neue Umgebung aus, geben Sie Test als Umgebungsnamen ein, und wählen Sie dann Umgebung konfigurieren aus.
Wählen Sie unter Umgebungsgeheimnis die Option Geheimnis hinzufügen aus, und geben Sie AZURE_CLIENT_ID ein für Name.
Geben Sie unter Wert die Client-ID (appId) für die zuvor erstellte Test-Microsoft Entra-App ein (als Umgebungsvariable $TEST_AZURE_CLIENT_ID gespeichert).
Klicken Sie auf Add secret (Geheimnis hinzufügen).

6.3 Erstellen der Prod-Umgebung

Kehren Sie erneut zur Seite „Main-Umgebungen“ zurück, indem Sie in der linken Randleiste Umgebungen auswählen

Wählen Sie Neue Umgebung aus, geben Sie Prod als Umgebungsnamen ein, und wählen Sie dann Umgebung konfigurieren aus.
Wählen Sie unter Umgebungsgeheimnis die Option Geheimnis hinzufügen aus, und geben Sie AZURE_CLIENT_ID ein für Name.
Geben Sie unter Wert die Client-ID (appId) für die zuvor erstellte Prod-Microsoft Entra-App ein (als Umgebungsvariable $PROD_AZURE_CLIENT_ID gespeichert).
Klicken Sie auf Add secret (Geheimnis hinzufügen).

Legen Sie sich als Nächstes selber als erforderlicher Prüfer für diese Umgebung fest. Beim Versuch, die Bereitstellung in Prod zu durchführen, wartet die 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.

Wähle Required reviewers aus.
Suchen Sie nach Ihrem GitHub-Benutzer, und wählen Sie ihn 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.
Wählen Sie Save protection rules (Schutzregeln speichern) aus.

main Konfigurieren Sie schließlich als Bereitstellungszweig:

Wählen Sie in der Dropdownliste „Bereitstellungsbranches“ die Option Ausgewählte Branches aus.
Wählen Sie "Bereitstellungszweigregel hinzufügen" aus, und geben main Sie es für das Branch-Namensmuster ein.
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

Wechseln Sie in Ihrem Terminal in einen Ordner, in dem Sie Ihr Repository lokal klonen möchten.
Klonen Sie das Repository. Stellen Sie sicher, dass Sie < Organization/Repository > im folgenden Befehl durch Ihre GitHub-Organisation und den Repositorynamen ersetzen.
```
git clone https://github.com/< Organization/Repository >.git
```
Navigieren Sie in das geklonte Verzeichnis.
```
cd <repository>
```
Erstellen Sie als Nächstes einen neuen Branch, und veröffentlichen Sie ihn remote.
```
git checkout -b feature1
```
```
git push -u origin feature1
```
Eine neue Umgebung wird in Azure speziell für diesen Branch erstellt.
Navigieren Sie auf GitHub zur Standard Seite Ihres neu erstellten Repositorys.
Wählen Sie unter dem Namen Ihres Repositorys Aktionen aus.

Es sollte ein neuer Workflow „Erstellen einer Umgebung“ angezeigt werden.

7.2 Vornehmen einer Änderung am Code

Öffnen Sie das lokal geklonte Repository in VS Code.
In der ADE. Lernprogrammordner , nehmen Sie eine Änderung an einer Datei vor.
Speichern Sie die Änderung.

7.3 Pushen Ihrer Änderungen, um die Umgebung zu aktualisieren

Stagen Sie Ihre Änderungen, und pushen Sie diese an den feature1-Branch.
```
git add .
git commit -m '<commit message>'
git push
```
Auf der Seite Aktionen Ihres Repositorys wird ein neuer Workflow für die Update-Umgebung ausgeführt.

7.4 Erstellen eines Pull Requests

Erstellen Sie eine GitHub-Pull-Anforderung main <- feature1.
Auf der Seite "Aktionen" Ihres Repositorys sehen Sie, dass ein neuer Workflow gestartet wird, um eine Umgebung zu erstellen, die für die Pullanforderung mit dem Testumgebungstyp spezifisch ist.

7.5 Zusammenführen der Pullanforderung

Navigieren Sie auf GitHub zu dem Pull Request, den Sie erstellt haben.
Führen Sie den 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:

Wählen Sie im Portal links oben die Menüschaltfläche und dann Ressourcengruppen aus.
Wählen Sie in der Liste die Ressourcengruppe aus, die Sie erstellt haben.
Wählen Sie die Option Ressourcengruppe löschen.
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.

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

Share via

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

Voraussetzungen

1. Erstellen und Konfigurieren eines Dev Centers

1.1 Einrichten der Azure CLI

1.2. Erstellen eines Dev Centers

1.3 Zuweisen der Rolle „Dev Center-Identitätsbesitzer“ im Abonnement

1.4 Erstellen der Umgebungstypen

1.5. Erstellen eines Projekts

1.6 Erstellen von Projektumgebungstypen

2. Erstellen eines Schlüsseltresors

3. Erstellen und Konfigurieren eines GitHub-Repositorys

3.1 Erstellen eines neuen GitHub-Repositorys

3.2 Schützen des Mainbranch des Repositorys

3.3 Konfigurieren von Repositoryvariablen

3.4 Erstellen eines persönlichen GitHub-Zugriffstokens

3.5 Speichern Ihres persönlichen Zugriffstokens im Schlüsseltresor

4. Verbinden des Katalogs mit Ihrem Dev Center

Hinzufügen eines Katalogs zu Ihrem Dev Center

5. Konfigurieren von Bereitstellungsidentitäten

5.1 Generieren von Bereitstellungsidentitäten

5.2 Zuweisen von Rollen zu Bereitstellungsidentitäten

6. Konfigurieren von GitHub-Umgebungen

6.1 Erstellen der Dev-Umgebung

6.2 Erstellen der Test-Umgebung

6.3 Erstellen der Prod-Umgebung

7, Testen der CI/CD-Pipeline

7.1 Klonen des Repositorys

7.2 Vornehmen einer Änderung am Code

7.3 Pushen Ihrer Änderungen, um die Umgebung zu aktualisieren

7.4 Erstellen eines Pull Requests

7.5 Zusammenführen der Pullanforderung

Bereinigen von Ressourcen

Feedback

Feedback

Zusätzliche Ressourcen

Share via

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

Voraussetzungen

1. Erstellen und Konfigurieren eines Dev Centers

1.1 Einrichten der Azure CLI

1.2. Erstellen eines Dev Centers

1.3 Zuweisen der Rolle „Dev Center-Identitätsbesitzer“ im Abonnement

1.4 Erstellen der Umgebungstypen

1.5. Erstellen eines Projekts

1.6 Erstellen von Projektumgebungstypen

2. Erstellen eines Schlüsseltresors

3. Erstellen und Konfigurieren eines GitHub-Repositorys

3.1 Erstellen eines neuen GitHub-Repositorys

3.2 Schützen des Mainbranch des Repositorys

3.3 Konfigurieren von Repositoryvariablen

3.4 Erstellen eines persönlichen GitHub-Zugriffstokens

3.5 Speichern Ihres persönlichen Zugriffstokens im Schlüsseltresor

4. Verbinden des Katalogs mit Ihrem Dev Center

Hinzufügen eines Katalogs zu Ihrem Dev Center

5. Konfigurieren von Bereitstellungsidentitäten

5.1 Generieren von Bereitstellungsidentitäten

5.2 Zuweisen von Rollen zu Bereitstellungsidentitäten

6. Konfigurieren von GitHub-Umgebungen

6.1 Erstellen der Dev-Umgebung

6.2 Erstellen der Test-Umgebung

6.3 Erstellen der Prod-Umgebung

7, Testen der CI/CD-Pipeline

7.1 Klonen des Repositorys

7.2 Vornehmen einer Änderung am Code

7.3 Pushen Ihrer Änderungen, um die Umgebung zu aktualisieren

7.4 Erstellen eines Pull Requests

7.5 Zusammenführen der Pullanforderung

Bereinigen von Ressourcen

Zugehöriger Inhalt

Feedback

Feedback

Zusätzliche Ressourcen