Esercitazione: Compilare più configurazioni usando i modelli

• 11 minuti

Negli esercizi precedenti è stata implementata una pipeline che compila il sito Web di Space Game. Abbiamo iniziato con uno script che esegue ogni azione di compilazione e successivamente è stato eseguito il mapping di ogni azione alla relativa attività della pipeline corrispondente. L'output della pipeline è un file con estensione zip che contiene l'app Web compilata.

In questo esercizio si userà un modello per definire le attività di compilazione da impiegare per qualsiasi configurazione definita nel file di progetto. I modelli consentono di definire la logica una volta e quindi di riusarla più volte. I modelli combinano il contenuto di più file YAML in un'unica pipeline.

Per iniziare, si verifica cosa stanno facendo Mara e Amita.

La dimostrazione

Mara, entusiasta di condividere i suoi risultati, si rivolge ad Amita per illustrarle la pipeline di compilazione.

Amita: Sono stupita dalla tua velocità! In realtà, sono venuta qui solo perché ho ricevuto un messaggio di posta elettronica che mi informa che la compilazione è pronta. Grazie. Ho visto che la pipeline compila solo la configurazione Release. Usiamo anche le build Debug per poter acquisire informazioni aggiuntive se l'app si arresta in modo anomalo. È possibile aggiungerle?

Mara: Assolutamente. Ho dimenticato di prendere in considerazione le build Debug durante la configurazione. Cosa ne dici se ci sediamo un attimo e le aggiungiamo?

Amita: Mi hai mostrato che il file YAML definisce le fasi di compilazione, ma non credo di essere in grado di modificarlo.

Mara: Non ti preoccupare. Puoi guardare mentre digito. Possiamo farlo insieme.

Come definiresti entrambe le configurazioni della build?

Si considerino le attività seguenti che compilano e pubblicano la configurazione Release del progetto Web di Space Game. Non aggiungere questo codice al file azure-pipelines.yml.

- task: DotNetCoreCLI@2
  displayName: 'Build the project - Release'
  inputs:
    command: 'build'
    arguments: '--no-restore --configuration Release'
    projects: '**/*.csproj'

- task: DotNetCoreCLI@2
  displayName: 'Publish the project - Release'
  inputs:
    command: 'publish'
    projects: '**/*.csproj'
    publishWebProjects: false
    arguments: '--no-build --configuration Release --output $(Build.ArtifactStagingDirectory)/Release'
    zipAfterPublish: true

Per compilare la configurazione Debug, è possibile ripetere queste due attività, ma sostituendo Release con Debug.

In questo modo è possibile ottenere il risultato che si sta cercando, ma cosa accade quando la compilazione diventa più complessa o i requisiti cambiano? Sarebbe necessario individuare e modificare manualmente entrambe le varianti di ogni attività di compilazione. Dopo aver aggiunto i requisiti di compilazione aggiuntivi, sarebbe inoltre necessario creare due attività, una per la configurazione Debug e una per Release, per soddisfare tali requisiti.

Una soluzione migliore consiste nell'uso dei modelli.

Cosa sono i modelli?

Un modello consente di definire le attività di compilazione comuni una volta e di riusarle più volte.

Un modello viene chiamato dalla pipeline padre come passaggio di compilazione. I parametri in un modello possono essere trasferiti dalla pipeline padre.

Mara può definire le attività per compilare e pubblicare l'app come modello, quindi applicarlo a ogni configurazione necessaria.

Definire il modello

Ricordarsi che un modello consente di definire le attività di compilazione comuni una volta e di riusarle più volte. È possibile chiamare un modello dal modello padre come passaggio di compilazione e passare i parametri in un modello dalla pipeline padre.

Verrà ora creato un modello in grado di compilare qualsiasi configurazione definita nel file di progetto.

1. Dalla console integrata di Visual Studio Code creare una directory templates alla radice del progetto.

   mkdir templates
   

   In pratica, un file modello può essere inserito in qualsiasi posizione. Non è necessario inserirli nella directory templates.

2. In Visual Studio Code selezionare File > Nuovo file. Quindi, per salvare il file vuoto come build.yml nella directory templates del progetto, selezionare File > Salva. Ad esempio ~/mslearn-tailspin-spacegame-web/templates.

   Importante

   Come in precedenza, in Windows, nell'elenco Salva come selezionare YAML.

3. In Visual Studio Code aggiungere questo codice a build.yml:

   parameters:
     buildConfiguration: 'Release'
   
   steps:
   - task: DotNetCoreCLI@2
     displayName: 'Build the project - ${{ parameters.buildConfiguration }}'
     inputs:
       command: 'build'
       arguments: '--no-restore --configuration ${{ parameters.buildConfiguration }}'
       projects: '**/*.csproj'
   
   - task: DotNetCoreCLI@2
     displayName: 'Publish the project - ${{ parameters.buildConfiguration }}'
     inputs:
       command: 'publish'
       projects: '**/*.csproj'
       publishWebProjects: false
       arguments: '--no-build --configuration ${{ parameters.buildConfiguration }} --output $(Build.ArtifactStagingDirectory)/${{ parameters.buildConfiguration }}'
       zipAfterPublish: true
   

   Queste attività sono simili a quelle definite in precedenza per compilare e pubblicare l'app. In un modello si usano tuttavia i parametri di input in modo diverso rispetto alle variabili normali. Sono presenti due differenze:

   • In un file modello si usa la sezione parameters anziché variables per definire gli input.
   • In un file modello si usa la sintassi ${{ }} anziché $() per leggere il valore di un parametro. Quando si legge il valore di un parametro, la sezione parameters deve essere inclusa nel nome. Ad esempio: ${{ parameters.buildConfiguration }}.

Chiamare il modello dalla pipeline

A questo punto si chiamerà il modello appena compilato dalla pipeline. Questa operazione viene eseguita una sola volta per la configurazione Debug, quindi si ripete il processo per la configurazione Release.

1. In Visual Studio Code modificare azure-pipelines.yml come indicato di seguito:

   trigger:
   - '*'
   
   pool:
     vmImage: ubuntu-latest
   
   variables:
     buildConfiguration: 'Release'
     wwwrootDir: 'Tailspin.SpaceGame.Web/wwwroot'
     dotnetSdkVersion: '6.x'
   
   steps:
   - task: UseDotNet@2
     displayName: 'Use .NET SDK $(dotnetSdkVersion)'
     inputs:
       version: '$(dotnetSdkVersion)'
   
   - task: Npm@1
     displayName: 'Run npm install'
     inputs:
       verbose: false
   
   - script: './node_modules/.bin/node-sass $(wwwrootDir) --output $(wwwrootDir)'
     displayName: 'Compile Sass assets'
   
   - task: gulp@1
     displayName: 'Run gulp tasks'
   
   - script: 'echo "$(Build.DefinitionName), $(Build.BuildId), $(Build.BuildNumber)" > buildinfo.txt'
     displayName: 'Write build info'
     workingDirectory: $(wwwrootDir)
   
   - task: DotNetCoreCLI@2
     displayName: 'Restore project dependencies'
     inputs:
       command: 'restore'
       projects: '**/*.csproj'
   
   - template: templates/build.yml
     parameters:
       buildConfiguration: 'Debug'
   
   - template: templates/build.yml
     parameters:
       buildConfiguration: 'Release'
   
   - task: PublishBuildArtifacts@1
     displayName: 'Publish Artifact: drop'
     condition: succeeded()
   

   trigger:
   - '*'
   
   pool:
     name: 'Default' #replace if needed with name of your agent pool
   
   variables:
     buildConfiguration: 'Release'
     wwwrootDir: 'Tailspin.SpaceGame.Web/wwwroot'
     dotnetSdkVersion: '6.x'
   
   steps:
   - task: UseDotNet@2
     displayName: 'Use .NET SDK $(dotnetSdkVersion)'
     inputs:
       version: '$(dotnetSdkVersion)'
   
   - task: Npm@1
     displayName: 'Run npm install'
     inputs:
       verbose: false
   
   - script: './node_modules/.bin/node-sass $(wwwrootDir) --output $(wwwrootDir)'
     displayName: 'Compile Sass assets'
   
   - task: gulp@1
     displayName: 'Run gulp tasks'
   
   - script: 'echo "$(Build.DefinitionName), $(Build.BuildId), $(Build.BuildNumber)" > buildinfo.txt'
     displayName: 'Write build info'
     workingDirectory: $(wwwrootDir)
   
   - task: DotNetCoreCLI@2
     displayName: 'Restore project dependencies'
     inputs:
       command: 'restore'
       projects: '**/*.csproj'
   
   - template: templates/build.yml
     parameters:
       buildConfiguration: 'Debug'
   
   - template: templates/build.yml
     parameters:
       buildConfiguration: 'Release'
   
   - task: PublishBuildArtifacts@1
     displayName: 'Publish Artifact: drop'
     condition: succeeded()
   

   Questo file è simile all'originale, ad eccezione del fatto che sostituisce le attività di compilazione e pubblicazione con chiamate al modello che esegue le stesse attività.

   Si noterà che il modello viene chiamato una volta per ogni configurazione. Per passare il nome della configurazione al modello, ogni attività template usa l'argomento parameters.

Eseguire la pipeline

A questo punto si eseguirà il push delle modifiche in GitHub e si assisterà all'esecuzione della pipeline.

1. Nel terminale integrato aggiungere azure-pipelines.yml e templates/build.yml all'indice, eseguire il commit delle modifiche ed eseguire il push delle modifiche in GitHub.

   git add azure-pipelines.yml templates/build.yml
   git commit -m "Support build configurations"
   git push origin build-pipeline
   

2. Come è stato fatto in precedenza, in Azure Pipelines tracciare la compilazione tramite ognuno dei passaggi.

   Durante l'esecuzione della pipeline si noterà che il processo espande le attività all'interno del modello. Le attività che compilano e pubblicano il progetto vengono eseguite due volte, una per ogni configurazione della build.

   

3. Al termine della compilazione, tornare alla pagina del riepilogo e selezionare l'artefatto pubblicato come in precedenza. Espandere la cartella a sola scrittura.

   Si noterà che la pipeline genera un file ZIP per le configurazioni Debug e Release.

   

Unire il ramo nel ramo principale

A questo punto, si dispone di una pipeline di compilazione funzionante che soddisfa tutte le esigenze attuali di Mara.

In pratica, si invia una richiesta pull che unisce il ramo build-pipeline al ramo main.

Questo passaggio verrà saltato per il momento. Nel modulo successivo verranno illustrati alcuni modi per collaborare con il team in GitHub, incluso come inviare, rivedere ed eseguire il merge delle richieste pull.