Esercizio - Pubblicare il risultato nella pipeline

Completato

A questo punto, è possibile compilare il progetto Web Space Game tramite la pipeline.

Ma dove vanno i risultati della compilazione? Al momento, l'output della compilazione rimane nel server di compilazione temporaneo. Mara ha bisogno di un modo per consegnare questa build ad Amita in modo da poter iniziare a testare.

Gli artefatti della compilazione possono essere archiviati in Azure Pipelines per consentire agli altri membri del team di accedervi in un secondo momento al termine della compilazione. Sono queste le operazioni che verranno eseguite. Come vantaggio, si eseguirà anche il refactoring della configurazione di compilazione per usare le variabili per semplificare la lettura e l'aggiornamento della configurazione.

Nota

Azure Pipelines consente di distribuire automaticamente l'app compilata in un ambiente di test o di produzione in esecuzione nel cloud o nel data center. Per il momento, l'obiettivo di Mara è quello di produrre compilazioni che può passare al controllo di qualità usando i processi esistenti.

Pubblicare la compilazione nella pipeline

In .NET si può comprimere l'app come file con estensione zip. È quindi possibile usare l'attività predefinita PublishBuildArtifacts@1 per pubblicare il file con estensione zip in Azure Pipelines.

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

    trigger:
    - '*'
    
    pool:
      name: 'Default' #replace if needed with name of your agent pool
    
    steps:
    - task: UseDotNet@2
      displayName: 'Use .NET SDK 6.x'
      inputs:
        version: '6.x'
    
    - task: Npm@1
      displayName: 'Run npm install'
      inputs:
        verbose: false
    
    - script: './node_modules/.bin/node-sass Tailspin.SpaceGame.Web/wwwroot --output Tailspin.SpaceGame.Web/wwwroot'
      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: Tailspin.SpaceGame.Web/wwwroot
    
    - task: DotNetCoreCLI@2
      displayName: 'Restore project dependencies'
      inputs:
        command: 'restore'
        projects: '**/*.csproj'
    
    - 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
    
    - task: PublishBuildArtifacts@1
      displayName: 'Publish Artifact: drop'
      condition: succeeded()
    
    trigger:
    - '*'
    
    pool:
      vmImage: ubuntu-latest
    
    steps:
    - task: UseDotNet@2
      displayName: 'Use .NET SDK 6.x'
      inputs:
        version: '6.x'
    
    - task: Npm@1
      displayName: 'Run npm install'
      inputs:
        verbose: false
    
    - script: './node_modules/.bin/node-sass Tailspin.SpaceGame.Web/wwwroot --output Tailspin.SpaceGame.Web/wwwroot'
      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: Tailspin.SpaceGame.Web/wwwroot
    
    - task: DotNetCoreCLI@2
      displayName: 'Restore project dependencies'
      inputs:
        command: 'restore'
        projects: '**/*.csproj'
    
    - 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
    
    - task: PublishBuildArtifacts@1
      displayName: 'Publish Artifact: drop'
      condition: succeeded()
    

    Questa versione di azure-pipelines.yml è simile alla versione precedente, ma aggiunge due attività aggiuntive.

    La prima attività usa l'attività DotNetCoreCLI@2 per pubblicare, o comprimere, i risultati della compilazione dell'app (incluse le relative dipendenze) in una cartella. L'argomento zipAfterPublish specifica di aggiungere i risultati compilati a un file con estensione zip.

    La seconda attività usa l'attività PublishBuildArtifacts@1 per pubblicare il file con estensione zip in Azure Pipelines. L'argomento condition specifica di eseguire l'attività solo quando l'attività precedente ha esito positivo. succeeded() è la condizione predefinita, quindi non è necessario specificarla. Ma lo mostriamo qui per mostrarne l'uso.

  2. Dal terminale integrato aggiungere azure-pipelines.yml all'indice, eseguire il commit della modifica ed eseguire il push della modifica in GitHub.

    Suggerimento

    Prima di eseguire questi comandi Git, ricordarsi di salvare azure-pipelines.yml.

    git add azure-pipelines.yml
    git commit -m "Add publish tasks"
    git push origin build-pipeline
    
  3. Come in precedenza, da Azure Pipelines tracciare la compilazione tramite ognuno dei passaggi.

  4. Al termine della pipeline, tornare al riepilogo per la compilazione.

  5. In Correlati è presente 1 pubblicata.

    Screenshot of the build summary. Details include the repository and version, the time started and elapsed, and a link to the published build artifact.

  6. Selezionare l'artefatto.

  7. Espandere la cartella di rilascio.

    Viene visualizzato un file con estensione zip contenente l'app compilata e le relative dipendenze:

    Screenshot of the packaged web application in the Artifacts explorer.

    Se si vuole provare un esercizio facoltativo, è possibile scaricare il file con estensione zip nel computer ed esplorarne il contenuto.

Definire le variabili per migliorare la leggibilità

Mara torna a esaminare il suo lavoro. La configurazione della build fa ciò di cui ha bisogno, ma vuole assicurarsi che Andy e gli altri possano tenerla aggiornata ed estenderla con facilità.

Le variabili consentono di definire i valori una volta e di farvi riferimento in tutta la pipeline. Azure Pipelines sostituisce ogni variabile con il relativo valore corrente quando viene eseguita la pipeline.

Analogamente ad altri linguaggi di programmazione, le variabili consentono di eseguire operazioni come le seguenti:

  • Definire valori che potrebbero cambiare tra le esecuzioni della pipeline.
  • Archiviare le informazioni ripetute in tutta la pipeline, ad esempio un numero di versione o un percorso di file, in un'unica posizione. In questo modo, non è necessario aggiornare tutte le occorrenze quando le esigenze cambiano.

Azure Pipelines fornisce molte variabili predefinite. Queste variabili descrivono gli aspetti del processo di compilazione, ad esempio l'identificatore di compilazione e i nomi di directory in cui viene compilato e gestito il software.

È anche possibile definire le proprie variabili. Di seguito è riportato un esempio in cui viene illustrata una variabile denominata buildConfiguration che definisce la configurazione della build Release:

variables:
  buildConfiguration: 'Release'

Usare le variabili quando si ripete lo stesso valore più volte o quando un valore, ad esempio una versione di dipendenza, potrebbe cambiare.

Non è necessario creare una variabile per ogni parte della configurazione di compilazione. In effetti, troppe variabili possono rendere più difficile il codice della pipeline per consentire ad altri utenti di leggere e comprendere.

Esaminare azure-pipelines.yml. Si noti che questi valori vengono ripetuti:

  • Configurazione della build: Release.
  • Percorso della directory wwwroot: Tailspin.SpaceGame.Web/wwwroot.
  • Versione di .NET SDK: 6.x.

Ora si usano le variabili per definire questi valori una volta. Si fa quindi riferimento alle variabili in tutta la pipeline.

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

    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'
    
    - task: DotNetCoreCLI@2
      displayName: 'Build the project - $(buildConfiguration)'
      inputs:
        command: 'build'
        arguments: '--no-restore --configuration $(buildConfiguration)'
        projects: '**/*.csproj'
    
    - task: DotNetCoreCLI@2
      displayName: 'Publish the project - $(buildConfiguration)'
      inputs:
        command: 'publish'
        projects: '**/*.csproj'
        publishWebProjects: false
        arguments: '--no-build --configuration $(buildConfiguration) --output $(Build.ArtifactStagingDirectory)/$(buildConfiguration)'
        zipAfterPublish: true
    
    - task: PublishBuildArtifacts@1
      displayName: 'Publish Artifact: drop'
      condition: succeeded()
    
    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'
    
    - task: DotNetCoreCLI@2
      displayName: 'Build the project - $(buildConfiguration)'
      inputs:
        command: 'build'
        arguments: '--no-restore --configuration $(buildConfiguration)'
        projects: '**/*.csproj'
    
    - task: DotNetCoreCLI@2
      displayName: 'Publish the project - $(buildConfiguration)'
      inputs:
        command: 'publish'
        projects: '**/*.csproj'
        publishWebProjects: false
        arguments: '--no-build --configuration $(buildConfiguration) --output $(Build.ArtifactStagingDirectory)/$(buildConfiguration)'
        zipAfterPublish: true
    
    - task: PublishBuildArtifacts@1
      displayName: 'Publish Artifact: drop'
      condition: succeeded()
    

    Si noti la variables sezione , che definisce queste variabili:

    • buildConfiguration: specifica la configurazione della build.
    • wwwrootDir: specifica il percorso della directory wwwroot.
    • dotnetSdkVersion: specifica la versione di .NET SDK da usare.

    Per fare riferimento a queste variabili, usare la sintassi $() come per le variabili predefinite. Ecco il passaggio che esegue node-Sass per convertire i file sass in CSS. Per ottenere il percorso della directory wwwroot, fa riferimento alla variabile wwwrootDir.

    - script: './node_modules/.bin/node-sass $(wwwrootDir) --output $(wwwrootDir)'
      displayName: 'Compile Sass assets'
    

    Il comando script usa la variabile per definire sia la directory di origine per i file Sass che la directory in cui scrivere file CSS. Usa anche la variabile per definire il nome dell'attività visualizzato nell'interfaccia utente.

  2. Dal terminale integrato aggiungere azure-pipelines.yml all'indice, eseguire il commit della modifica ed eseguire il push della modifica in GitHub.

    git add azure-pipelines.yml
    git commit -m "Refactor common variables"
    git push origin build-pipeline
    
  3. Da Azure Pipelines tracciare la compilazione tramite ognuno dei passaggi.

    Si noterà che quando viene eseguita la compilazione le variabili vengono sostituite con i relativi valori. Ad esempio, questa è l'attività UseDotNet@2 che imposta la versione di .NET SDK da usare.

    Screenshot of Azure Pipelines showing the .NET SDK task running in the pipeline.

    Come in precedenza, per visualizzare l'artefatto al termine della compilazione, è possibile passare al riepilogo della compilazione.

Si è così Azure Pipelines è stato usato correttamente e creato il primo artefatto di compilazione.