Esercitazione: Distribuire ambienti in CI/CD usando GitHub e ambienti di distribuzione di Azure

Articolo
12/07/2023

In questa esercitazione si apprenderà come integrare gli ambienti di distribuzione di Azure nella pipeline CI/CD. È possibile usare qualsiasi provider GitOps che supporta CI/CD, ad esempio GitHub Actions, Azure Arc, GitLab o Jenkins.

L'integrazione continua e il recapito continuo (CI/CD) è un approccio di sviluppo software che consente ai team di automatizzare il processo di compilazione, test e distribuzione delle modifiche software. CI/CD consente di rilasciare le modifiche software più frequentemente e con maggiore attendibilità.

Si usa un flusso di lavoro che include tre rami: main, dev e test.

Il ramo principale è sempre considerato di produzione.
I rami di funzionalità vengono creati dal ramo principale .
Si creano richieste pull per unire rami di funzionalità in main.

Questo flusso di lavoro è un piccolo esempio ai fini di questa esercitazione. I flussi di lavoro reali potrebbero essere più complessi.

Prima di iniziare questa esercitazione, è possibile acquisire familiarità con le risorse e i concetti degli ambienti di distribuzione esaminando i concetti chiave per gli ambienti di distribuzione di Azure.

In questa esercitazione apprenderai a:

Creare e configurare un dev center
Creare un insieme di credenziali delle chiavi
Creare e configurare un repository GitHub
Connessione il catalogo al dev center
Configurare le identità di distribuzione
Configurare gli ambienti GitHub
Testare la pipeline CI/CD

Prerequisiti

Un account Azure con una sottoscrizione attiva.
- Creare un account gratuitamente.
Autorizzazioni di proprietario nella sottoscrizione di Azure.
Un account GitHub.
- Se non è disponibile, iscriversi per riceverne uno gratuito.
Installare Git.
Installare l'interfaccia della riga di comando di Azure.

1. Creare e configurare un dev center

In questa sezione viene creato un dev center per gli ambienti di distribuzione di Azure e un progetto con tre tipi di ambiente: Sviluppo, Test e Prod.

Il tipo di ambiente Prod contiene l'ambiente di produzione singolo.
Viene creato un nuovo ambiente in Sviluppo per ogni ramo di funzionalità.
Viene creato un nuovo ambiente in Test per ogni richiesta pull.

1.1 Configurare l'interfaccia della riga di comando di Azure

Per iniziare, accedere ad Azure. Eseguire il comando seguente e seguire le istruzioni per completare il processo di autenticazione.

az login

Installare quindi l'estensione Azure devcenter per l'interfaccia della riga di comando di Azure.

az extension add --name devcenter --upgrade

Ora che l'estensione corrente è installata, registrare lo Microsoft.DevCenter spazio dei nomi.

az provider register --namespace Microsoft.DevCenter

Suggerimento

In questa esercitazione verranno salvati diversi valori come variabili di ambiente da usare in un secondo momento. È anche possibile registrare questi valori altrove per assicurarsi che siano disponibili quando necessario.

Ottenere l'ID dell'utente e impostarlo su una variabile di ambiente per un secondo momento:

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

Recuperare l'ID sottoscrizione per la sottoscrizione corrente.

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

Recuperare l'ID tenant per il tenant corrente.

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

Impostare le seguenti variabili di ambiente:

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

Nota

È necessario usare un nome univoco globale dell'insieme di credenziali delle chiavi. In caso contrario, è possibile che venga visualizzato l'errore seguente: 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 Creare un dev center

Un dev center è una raccolta di progetti e ambienti con impostazioni simili. I dev center forniscono l'accesso a un catalogo di modelli e artefatti che possono essere usati per creare ambienti. I centri di sviluppo offrono anche un modo per gestire l'accesso agli ambienti e ai progetti.

Crea un gruppo di risorse.

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

Creare un nuovo dev center.

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

Il comando precedente restituisce JSON. Salvare i valori per id e identity.principalId come variabili di ambiente da usare in un secondo momento.

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

1.3 Assegnare il ruolo di proprietario dell'identità di Dev Center nella sottoscrizione

Un dev center necessita delle autorizzazioni per assegnare ruoli alle sottoscrizioni associate ai tipi di ambiente.

Per ridurre la complessità non necessaria, in questa esercitazione si usa una singola sottoscrizione per il dev center e tutti i tipi di ambiente. In pratica, le sottoscrizioni di dev center e di distribuzione di destinazione saranno probabilmente sottoscrizioni separate con criteri diversi applicati.

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

1.4 Creare i tipi di ambiente

A livello di dev center, i tipi di ambiente definiscono gli ambienti che i team di sviluppo possono creare, ad esempio sviluppo, test, sandbox, preproduzione o produzione.

Creare tre nuovi tipi di ambiente: Sviluppo, Test e 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 Creare un progetto

Un progetto è il punto di accesso per il team di sviluppo. Ogni progetto è associato a un dev center.

Creare un nuovo progetto.

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

Il comando precedente restituisce JSON. Salvare il id valore come variabile di ambiente da usare in un secondo momento.

AZURE_PROJECT_ID=<id>

Assegnare a se stessi il ruolo di Amministrazione progetto DevCenter nel progetto.

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

1.6 Creare tipi di ambiente di progetto

A livello di progetto, i tecnici della piattaforma specificano i tipi di ambiente appropriati per il team di sviluppo.

Creare un nuovo tipo di ambiente di progetto per ognuno dei tipi di ambiente creati nel dev center.

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. Creare un insieme di credenziali delle chiavi

In questa sezione viene creato un nuovo insieme di credenziali delle chiavi. Questo insieme di credenziali delle chiavi verrà usato più avanti nell'esercitazione per salvare un token di accesso personale da GitHub.

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

Anche in questo caso, salvare l'oggetto id dall'output JSON del comando precedente come variabile di ambiente.

AZURE_KEYVAULT_ID=<id>

Assegnare a se stessi il ruolo Amministrazione istrator dell'insieme di credenziali delle chiavi nel nuovo insieme di credenziali delle chiavi.

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

Assegnare l'identità di Dev Center il ruolo dell'utente dei segreti di Key Vault.

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. Creare e configurare un repository GitHub

In questa sezione viene creato un nuovo repository GitHub per archiviare un catalogo. Gli ambienti di distribuzione di Azure supportano sia GitHub che i repository Azure DevOps. In questa esercitazione si usa GitHub.

3.1 Creare un nuovo repository GitHub

In questo passaggio si crea un nuovo repository nell'account GitHub con una struttura di directory, rami e file predefiniti. Questi elementi vengono generati da un repository di modelli di esempio.

Usare questo collegamento per generare un nuovo repository GitHub dal modello di esempio.
Se non si ha un account GitHub a pagamento, impostare il repository su Pubblico.
Selezionare Create repository from template (Crea repository da modello).
Nella scheda Azioni si noti che l'azione Crea ambiente ha esito negativo. Questo comportamento è previsto, è possibile procedere con il passaggio successivo.

3.2 Proteggere il ramo principale del repository

È possibile proteggere rami importanti impostando le regole di protezione dei rami. Le regole di protezione definiscono se i collaboratori possono eliminare o forzare il push nel ramo. Impostano anche i requisiti per qualsiasi push nel ramo, ad esempio il passaggio di controlli di stato o una cronologia di commit lineare.

Nota

I rami protetti sono disponibili nei repository pubblici con GitHub Free e GitHub Free per le organizzazioni e nei repository pubblici e privati con GitHub Pro, GitHub Team, GitHub Enterprise Cloud e GitHub Enterprise Server. Per altre informazioni, vedere Prodotti GitHub.

Se non è già aperto, passare alla pagina principale del repository.
Sotto il nome del repository selezionare Settings. Se non è possibile visualizzare la scheda Impostazioni, selezionare il menu a discesa ... e quindi selezionare Impostazioni.
Nella sezione Codice e automazione della barra laterale selezionare Rami.
In Regole di protezione ramo selezionare Aggiungi regola di protezione ramo.
In Modello nome ramo immettere main.
In Proteggi rami corrispondenti selezionare Richiedi una richiesta pull prima dell'unione.
Facoltativamente, è possibile abilitare altre regole di protezione.
Seleziona Crea.

3.3 Configurare le variabili del repository

Nota

Le variabili di configurazione per GitHub Actions sono in versione beta e soggette a modifiche.

Nella sezione Sicurezza della barra laterale selezionare Segreti e variabili, quindi selezionare Azioni.
Seleziona la scheda Variabili.

Per ogni elemento della tabella:

Selezionare Nuova variabile del repository.
Nel campo Nome immettere il nome della variabile.
Nel campo Valore immettere il valore descritto nella tabella.
Selezionare Aggiungi variabile.

Nome variabile	Valore variabile
AZURE_DEVCENTER	Nome del dev center
AZURE_PROJECT	Nome del progetto
AZURE_CATALOG	Impostare su "Ambienti"
AZURE_CATALOG_ITEM	Impostare su "FunctionApp"
AZURE_SUBSCRIPTION_ID	L'ID sottoscrizione di Azure
AZURE_TENANT_ID	ID tenant di Azure

3.4 Creare un token di accesso personale GitHub

Creare quindi un token di accesso personale con granularità fine per consentire al dev center ambienti di distribuzione di Azure di connettersi al repository e usare il catalogo dell'ambiente.

Nota

Il token di accesso personale con granularità fine è attualmente in versione beta e soggetto a modifiche. Per lasciare commenti e suggerimenti, vedere la discussione sui commenti e suggerimenti.

Nell'angolo superiore destro di qualsiasi pagina in GitHub.com selezionare la foto del profilo e quindi selezionare Impostazioni.
Nella barra laterale sinistra selezionare Impostazioni sviluppatore.
Nella barra laterale sinistra, in Token di accesso personali selezionare Token con granularità fine e quindi selezionare Genera nuovo token.
Nella pagina Nuovo token di accesso personale con granularità fine immettere un nome per il token in Nome token.
In Scadenza selezionare una scadenza per il token.
Selezionare l'utente GitHub in Proprietario risorsa.
In Accesso al repository selezionare Solo repository e quindi nell'elenco a discesa Repository selezionati cercare e selezionare il repository creato.
In Autorizzazioni selezionare Autorizzazioni repository e modificare Contenuto in Sola lettura.
Selezionare Genera token.
Copiare e salvare il token di accesso personale. Non è possibile visualizzarlo di nuovo.

3.5 Salvare il token di accesso personale nell'insieme di credenziali delle chiavi

Salvare quindi il token di accesso personale come segreto dell'insieme di credenziali delle chiavi denominato pat.

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

4. Connessione il catalogo al dev center

In Ambienti di distribuzione di Azure un catalogo è un repository che contiene un set di definizioni di ambiente. Gli elementi del catalogo sono costituiti da un modello di infrastruttura come codice (IaC) e da un file di ambiente che funge da manifesto. Il modello definisce l'ambiente e il file di ambiente fornisce metadati sul modello. I team di sviluppo usano definizioni di ambiente dal catalogo per creare ambienti.

Il modello usato per creare il repository GitHub contiene un catalogo nella cartella Ambienti .

Aggiungere il catalogo al dev center

Nel comando seguente sostituire < Organization/Repository > con l'organizzazione GitHub e il nome del repository.

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. Configurare le identità di distribuzione

OpenID Connessione con GitHub Actions è un metodo di autenticazione che usa token di breve durata per offrire sicurezza avanzata. È il modo consigliato per autenticare GitHub Actions in Azure.

È anche possibile autenticare un'entità servizio direttamente usando un segreto, ma non rientra nell'ambito di questa esercitazione.

5.1 Generare identità di distribuzione

Registrare le applicazioni Microsoft Entra e le entità servizio per ognuno dei tre tipi di ambiente.

Creare l'applicazione Microsoft Entra per dev.
```
az ad app create --display-name "$AZURE_PROJECT-Dev"
```
Questo comando restituisce JSON con un oggetto id che viene usato durante la creazione di credenziali federate con l'API Graph e un appId (detto anche ID client).

Impostare le seguenti variabili di ambiente:
```
DEV_AZURE_CLIENT_ID=<appId>
DEV_APPLICATION_ID=<id>
```
Ripetere per Test.
```
az ad app create --display-name "$AZURE_PROJECT-Test"
```
```
TEST_AZURE_CLIENT_ID=<appId>
TEST_APPLICATION_ID=<id>
```
E per Prod.
```
az ad app create --display-name "$AZURE_PROJECT-Prod"
```
```
PROD_AZURE_CLIENT_ID=<appId>
PROD_APPLICATION_ID=<id>
```
Creare un'entità servizio per ogni applicazione.

Eseguire il comando seguente per creare una nuova entità servizio per Dev.
```
 az ad sp create --id $DEV_AZURE_CLIENT_ID
```
Questo comando genera un output JSON diverso id e verrà usato nel passaggio successivo.

Impostare le seguenti variabili di ambiente:
```
DEV_SERVICE_PRINCIPAL_ID=<id>
```
Ripetere per Test.
```
 az ad sp create --id $TEST_AZURE_CLIENT_ID
```
```
TEST_SERVICE_PRINCIPAL_ID=<id>
```
E per Prod.
```
 az ad sp create --id $PROD_AZURE_CLIENT_ID
```
```
PROD_SERVICE_PRINCIPAL_ID=<id>
```

Eseguire i comandi seguenti per creare una nuova credenziali di identità federata per ogni applicazione active directory.

In ognuno dei tre comandi seguenti sostituire < Organization/Repository > con l'organizzazione GitHub e il nome del repository.

Creare le credenziali di identità federate per 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"]}'

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

E per 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 Assegnare ruoli alle identità di distribuzione

Assegnare a ogni identità di distribuzione il ruolo Lettore nel progetto.

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

Assegnare a ogni identità di distribuzione il ruolo utente Ambienti di distribuzione al tipo di ambiente corrispondente.

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. Configurare gli ambienti GitHub

Con gli ambienti GitHub è possibile configurare gli ambienti con regole di protezione e segreti. Un processo del flusso di lavoro che fa riferimento a un ambiente deve seguire qualsiasi regola di protezione per l'ambiente prima di eseguire o accedere ai segreti dell'ambiente.

Creare ambienti di sviluppo, test e produzione che eseguono il mapping ai tipi di ambiente nel progetto Ambienti di distribuzione di Azure.

Nota

Gli ambienti, i segreti dell'ambiente e le regole di protezione dell'ambiente sono disponibili nei repository pubblici per tutti i prodotti. Per accedere a ambienti, segreti dell'ambiente e rami di distribuzione in repository privati o interni , è necessario usare GitHub Pro, GitHub Team o GitHub Enterprise. Per accedere ad altre regole di protezione dell'ambiente in repository privati o interni , è necessario usare GitHub Enterprise. Per altre informazioni, vedere Prodotti GitHub.

6.1 Creare l'ambiente di sviluppo

In GitHub passare alla pagina principale del repository.
Sotto il nome del repository selezionare Settings. Se non è possibile visualizzare la scheda Impostazioni, selezionare il menu a discesa ... e quindi selezionare Impostazioni.
Nella barra laterale sinistra selezionare Ambienti.
Selezionare Nuovo ambiente e immettere Sviluppo per il nome dell'ambiente e quindi selezionare Configura ambiente.
In Segreti dell'ambiente selezionare Aggiungi segreto e immettere AZURE_CLIENT_ID per Nome.
In Valore immettere l'ID client (appId) per l'app *Dev**Microsoft Entra creata in precedenza (salvata come $DEV_AZURE_CLIENT_ID variabile di ambiente).
Selezionare Aggiungi segreto.

6.2 Creare l'ambiente di test

Tornare alla pagina ambienti principali selezionando Ambienti nella barra laterale sinistra.

Selezionare Nuovo ambiente e immettere Test per il nome dell'ambiente e quindi selezionare Configura ambiente.
In Segreti dell'ambiente selezionare Aggiungi segreto e immettere AZURE_CLIENT_ID per Nome.
In Valore immettere l'ID client (appId) per l'app Test Microsoft Entra creata in precedenza (salvata come $TEST_AZURE_CLIENT_ID variabile di ambiente).
Selezionare Aggiungi segreto.

6.3 Creare l'ambiente Prod

Ancora una volta, tornare alla pagina degli ambienti principali selezionando Ambienti nella barra laterale sinistra

Selezionare Nuovo ambiente e immettere Prod come nome dell'ambiente e quindi selezionare Configura ambiente.
In Segreti dell'ambiente selezionare Aggiungi segreto e immettere AZURE_CLIENT_ID per Nome.
In Valore immettere l'ID client (appId) per l'app Prod Microsoft Entra creata in precedenza (salvata come $PROD_AZURE_CLIENT_ID variabile di ambiente).
Selezionare Aggiungi segreto.

Impostare quindi se stessi come revisore necessario per questo ambiente. Quando si tenta di eseguire la distribuzione in Prod, GitHub Actions attende un'approvazione prima dell'avvio. Mentre un processo è in attesa di approvazione, ha lo stato In attesa. Se un processo non viene approvato entro 30 giorni, l'operazione ha esito negativo automaticamente.

Per altre informazioni sugli ambienti e le approvazioni necessarie, vedere Uso degli ambienti per la distribuzione.

Selezionare Revisori obbligatori.
Cercare e selezionare l'utente GitHub. È possibile immettere fino a sei persone o team. Solo uno dei revisori necessari deve approvare il processo per procedere.
Selezionare Salva regole di protezione.

Configurare main infine come ramo di distribuzione:

Nell'elenco a discesa Rami di distribuzione scegliere Rami selezionati.
Selezionare Aggiungi regola del ramo di distribuzione e immettere main per il modello nome ramo.
Seleziona Aggiungi regola.

7. Testare la pipeline CI/CD

In questa sezione vengono apportate alcune modifiche al repository e viene testata la pipeline CI/CD.

7.1 Clonare il repository

Nel terminale, cd in una cartella in cui si vuole clonare il repository in locale.
Clonare il repository. Assicurarsi di sostituire < Organization/Repository > nel comando seguente con l'organizzazione GitHub e il nome del repository.
```
git clone https://github.com/< Organization/Repository >.git
```
Passare alla directory clonata.
```
cd <repository>
```
Creare quindi un nuovo ramo e pubblicarlo in remoto.
```
git checkout -b feature1
```
```
git push -u origin feature1
```
Viene creato un nuovo ambiente in Azure specifico di questo ramo.
In GitHub passare alla pagina principale del repository appena creato.
Sotto il nome del repository selezionare Azioni.

Verrà visualizzato un nuovo flusso di lavoro Crea ambiente in esecuzione.

7.2 Apportare una modifica al codice

Aprire il repository clonato in locale in VS Code.
Nell'ambiente del servizio app . Cartella dell'esercitazione , apportare una modifica a un file.
Salvare la modifica.

7.3 Eseguire il push delle modifiche per aggiornare l'ambiente

Preparare le modifiche ed eseguire il push nel feature1 ramo.
```
git add .
git commit -m '<commit message>'
git push
```
Nella pagina Azioni del repository viene visualizzato un nuovo flusso di lavoro Update Environment in esecuzione.

7.4 Creare una richiesta pull

Creare una richiesta main <- feature1pull di GitHub.
Nella pagina Azioni del repository viene visualizzato un nuovo flusso di lavoro avviato per creare un ambiente specifico per la richiesta pull usando il tipo di ambiente test.

7.5 Unire la richiesta pull

In GitHub passare alla richiesta pull creata.
Unire la richiesta pull.

Le modifiche vengono pubblicate nell'ambiente di produzione e gli ambienti di richiesta pull e ramo vengono eliminati.

Pulire le risorse

Se non si prevede di usare alcuna delle risorse create, eliminarle in modo da non comportare ulteriori addebiti. Se l'applicazione di esempio è stata distribuita in un gruppo di risorse diverso, è possibile ripetere i passaggi seguenti.

Per eliminare le risorse usando il portale di Azure:

Selezionare il pulsante del menu nell'angolo superiore sinistro e quindi selezionare Gruppi di risorse.
Nell'elenco selezionare il gruppo di risorse creato.
Selezionare Elimina gruppo di risorse.
Immettere il nome del gruppo di risorse. Quindi seleziona Elimina.

Per eliminare le risorse usando l'interfaccia della riga di comando di Azure, immettere il comando seguente:

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

Tenere presente che l'eliminazione del gruppo di risorse comporta l'eliminazione di tutte le risorse al suo interno.

Creare e accedere a un ambiente usando l'interfaccia della riga di comando di Azure
Per gli elenchi di comandi completi, vedere la documentazione dell'interfaccia della riga di comando di Azure per Gli ambienti di distribuzione di Microsoft Dev Box e Azure

Condividi tramite

Esercitazione: Distribuire ambienti in CI/CD usando GitHub e ambienti di distribuzione di Azure

Prerequisiti

1. Creare e configurare un dev center

1.1 Configurare l'interfaccia della riga di comando di Azure

1.2 Creare un dev center

1.3 Assegnare il ruolo di proprietario dell'identità di Dev Center nella sottoscrizione

1.4 Creare i tipi di ambiente

1.5 Creare un progetto

1.6 Creare tipi di ambiente di progetto

2. Creare un insieme di credenziali delle chiavi

3. Creare e configurare un repository GitHub

3.1 Creare un nuovo repository GitHub

3.2 Proteggere il ramo principale del repository

3.3 Configurare le variabili del repository

3.4 Creare un token di accesso personale GitHub

3.5 Salvare il token di accesso personale nell'insieme di credenziali delle chiavi

4. Connessione il catalogo al dev center

Aggiungere il catalogo al dev center

5. Configurare le identità di distribuzione

5.1 Generare identità di distribuzione

5.2 Assegnare ruoli alle identità di distribuzione

6. Configurare gli ambienti GitHub

6.1 Creare l'ambiente di sviluppo

6.2 Creare l'ambiente di test

6.3 Creare l'ambiente Prod

7. Testare la pipeline CI/CD

7.1 Clonare il repository

7.2 Apportare una modifica al codice

7.3 Eseguire il push delle modifiche per aggiornare l'ambiente

7.4 Creare una richiesta pull

7.5 Unire la richiesta pull

Pulire le risorse

Commenti e suggerimenti

Risorse aggiuntive

Condividi tramite

Esercitazione: Distribuire ambienti in CI/CD usando GitHub e ambienti di distribuzione di Azure

Prerequisiti

1. Creare e configurare un dev center

1.1 Configurare l'interfaccia della riga di comando di Azure

1.2 Creare un dev center

1.3 Assegnare il ruolo di proprietario dell'identità di Dev Center nella sottoscrizione

1.4 Creare i tipi di ambiente

1.5 Creare un progetto

1.6 Creare tipi di ambiente di progetto

2. Creare un insieme di credenziali delle chiavi

3. Creare e configurare un repository GitHub

3.1 Creare un nuovo repository GitHub

3.2 Proteggere il ramo principale del repository

3.3 Configurare le variabili del repository

3.4 Creare un token di accesso personale GitHub

3.5 Salvare il token di accesso personale nell'insieme di credenziali delle chiavi

4. Connessione il catalogo al dev center

Aggiungere il catalogo al dev center

5. Configurare le identità di distribuzione

5.1 Generare identità di distribuzione

5.2 Assegnare ruoli alle identità di distribuzione

6. Configurare gli ambienti GitHub

6.1 Creare l'ambiente di sviluppo

6.2 Creare l'ambiente di test

6.3 Creare l'ambiente Prod

7. Testare la pipeline CI/CD

7.1 Clonare il repository

7.2 Apportare una modifica al codice

7.3 Eseguire il push delle modifiche per aggiornare l'ambiente

7.4 Creare una richiesta pull

7.5 Unire la richiesta pull

Pulire le risorse

Contenuto correlato

Commenti e suggerimenti

Risorse aggiuntive