Esercizio - Alza di livello la fase di test

8 minuti

La pipeline di versione ha ancora due fasi, ma ora sono diverse da quelle precedenti. Le fasi sono Build e Dev. Ogni modifica push in GitHub attiva la fase di compilazione da eseguire. La fase sviluppo viene eseguita solo quando la modifica si trova nel ramo di rilascio . In questo caso si aggiunge la fase test alla pipeline.

Tenere presente che il team ha deciso di usare un trigger pianificato per alzare di livello la build dalla fase di sviluppo alla fase di test alle 3 di ogni mattina. Per configurare il trigger pianificato:

Definire la pianificazione nella configurazione di compilazione.
Definire la fase test , che include una condizione che esegue la fase solo se il motivo della compilazione è contrassegnato come Schedule.

Ai fini dell'apprendimento, in questo caso si definisce la pianificazione, ma si consente alla compilazione di passare direttamente da Sviluppo a Test. Questa configurazione evita la necessità di attendere l'attivazione della pianificazione. Dopo aver completato questo modulo, sperimentare diverse espressioni Cron per eseguire la fase di test solo all'ora pianificata.

Alzare di livello le modifiche alla fase test

In questo caso si modifica la configurazione della pipeline per distribuire la compilazione nella fase test .

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

trigger:
- '*'

variables:
  buildConfiguration: 'Release'
  releaseBranchName: 'release'

schedules:
- cron: '0 3 * * *'
  displayName: 'Deploy every day at 3 A.M.'
  branches:
    include:
    - release
  always: false 

stages:
- stage: 'Build'
  displayName: 'Build the web application'
  jobs: 
  - job: 'Build'
    displayName: 'Build job'
    pool:
      vmImage: 'ubuntu-20.04'
      demands:
      - npm

    variables:
      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

    - publish: '$(Build.ArtifactStagingDirectory)'
      artifact: drop

- stage: 'Dev'
  displayName: 'Deploy to the dev environment'
  dependsOn: Build
  condition: |
    and
    (
      succeeded(),
      eq(variables['Build.SourceBranchName'], variables['releaseBranchName'])
    )
  jobs:
  - deployment: Deploy
    pool:
      vmImage: 'ubuntu-20.04'
    environment: dev
    variables:
    - group: Release
    strategy:
      runOnce:
        deploy:
          steps:
          - download: current
            artifact: drop
          - task: AzureWebApp@1
            displayName: 'Azure App Service Deploy: website'
            inputs:
              azureSubscription: 'Resource Manager - Tailspin - Space Game'
              appName: '$(WebAppNameDev)'
              package: '$(Pipeline.Workspace)/drop/$(buildConfiguration)/*.zip'

- stage: 'Test'
  displayName: 'Deploy to the test environment'
  dependsOn: Dev
  #condition: eq(variables['Build.Reason'], 'Schedule')
  jobs:
  - deployment: Deploy
    pool:
      vmImage: 'ubuntu-20.04'
    environment: test
    variables:
    - group: 'Release'
    strategy:
      runOnce:
        deploy:
          steps:
          - download: current
            artifact: drop
          - task: AzureWebApp@1
            displayName: 'Azure App Service Deploy: website'
            inputs:
              azureSubscription: 'Resource Manager - Tailspin - Space Game'
              appName: '$(WebAppNameTest)'
              package: '$(Pipeline.Workspace)/drop/$(buildConfiguration)/*.zip'

La schedules sezione definisce un'espressione cron. È possibile definire più espressioni nella configurazione. L'espressione attiva la pipeline per l'esecuzione sul ramo di versione alle 3.00 di ogni mattina. Il always flag è impostato su false in modo che la pipeline venga eseguita solo quando il ramo di versione contiene modifiche rispetto all'esecuzione precedente.

La Test fase definisce una condizione che esegue la fase solo quando il motivo della compilazione Scheduleè uguale a . La variabile predefinita definisce il motivo della compilazione Build.Reason . Se questa condizione è false, la fase viene ignorata, ma le fasi precedenti continuano a essere eseguite.

Nota

Questa condizione viene visualizzata a scopo di apprendimento. È impostato come commento per abilitare la modifica da Sviluppo a Test senza attendere l'attivazione della pianificazione.

Dal terminale integrato all'indice aggiungere azure-pipelines.yml. Eseguire quindi il commit della modifica ed eseguirne il push in GitHub.

Suggerimento

Prima di eseguire questi comandi Git, salvare azure-pipelines.yml.
```
git add azure-pipelines.yml
git commit -m "Deploy to the Test stage"
git push origin release
```
In Azure Pipelines passare alla compilazione. Tracciare quindi la compilazione durante l'esecuzione.
Al termine della compilazione, per tornare alla pagina di riepilogo, selezionare il pulsante Indietro.

Si noterà che la distribuzione è stata completata correttamente.
Da un Web browser passare all'URL associato all'istanza di servizio app per l'ambiente di test.

Se la scheda del browser è ancora aperta, aggiornare la pagina. Se non si ricorda l'URL, trovarlo nella portale di Azure, nella pagina dei dettagli servizio app.

Si noterà che il sito Web Space Game viene distribuito in servizio app ed è in esecuzione.
Come passaggio facoltativo, in Azure Pipelines selezionare Ambienti. Selezionare quindi l'ambiente di test .

Azure Pipelines registra la cronologia di distribuzione. Nella cronologia è possibile tracciare le modifiche nell'ambiente ai commit del codice e agli elementi di lavoro.

Andy e Mara aggiungono la fase test alla pipeline. Mostrano i risultati ad Amita.

Amita: mi piace che le modifiche vengano compilate e distribuite in modo da poterle testare ogni mattina. Ma non vedo come è possibile controllare quando arrivano le modifiche alla gestione temporanea.

Mara: Sì, la distribuzione tramite automazione consente di risparmiare molto tempo. Tenere presente che è stato incluso solo il trigger pianificato. Si aggiungerà ora un'approvazione della versione quando si configura l'ambiente di gestione temporanea per Tim. In questo modo, le modifiche passano alla gestione temporanea solo quando si è pronti.

Continua

Esercizio - Alza di livello la fase di test

Alzare di livello le modifiche alla fase test

Commenti e suggerimenti