Ejercicio: Promoción a la fase de pruebas

8 minutos

La canalización de versión sigue teniendo dos fases, pero ahora son distintas de las anteriores. Las fases son las de compilación y desarrollo. Cada cambio que inserte en GitHub desencadenará la ejecución de la fase de compilación. La fase de desarrollo solo se ejecuta cuando el cambio se realiza en la rama de versión. Aquí agregará la fase de pruebas a la canalización.

Recuerde que el equipo decidió usar un desencadenador programado para promover la compilación de la fase de desarrollo a la de pruebas a las 03:00 cada mañana. Para configurar el desencadenador programado:

Defina la programación en la configuración de la compilación.
Defina la fase de pruebas, que incluye una condición que ejecuta la fase solo si el motivo de la compilación está marcado como Schedule.

Con fines de aprendizaje, aquí definirá la programación, pero permitirá que la compilación vaya directamente del desarrollo a las pruebas. Esta configuración evita que haya que esperar a que se desencadene la programación. Después de completar este módulo, pruebe a experimentar con diferentes expresiones cron para ejecutar la fase de prueba solo en el momento programado.

Promoción de cambios a la fase de pruebas

Aquí modificará la configuración de la canalización para implementar la compilación en la fase de pruebas.

En Visual Studio Code, modifique azure-pipelines.yml de la manera siguiente:

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 sección schedules define una expresión cron. Puede definir más de una expresión en la configuración. La expresión desencadena que la canalización se ejecute en la rama de versión a las 3 a. m. cada día. La marca always se establece en false para que la canalización se ejecute solo cuando la rama de versión contiene cambios de la ejecución anterior.

La fase Test define una condición que ejecuta la fase solo cuando el motivo de la compilación es igual a Schedule. (La variable integrada Build.Reason define el motivo de la compilación). Si esta condición es false, se omite la fase, pero las fases anteriores siguen ejecutándose.

Nota:

Esta condición se muestra con fines de aprendizaje. Se comenta para permitir que el cambio pase del desarrollo a las pruebas sin esperar a que se desencadene la programación.

En el terminal integrado, agregue azure-pipelines.yml al índice. Después, confirme el cambio e insértelo en GitHub.

Sugerencia

Antes de ejecutar estos comandos de Git, guarde azure-pipelines.yml.
```
git add azure-pipelines.yml
git commit -m "Deploy to the Test stage"
git push origin release
```
En Azure Pipelines, vaya a la compilación. Realice el seguimiento de la compilación a medida que se ejecuta.
Una vez que finalice la compilación, seleccione el botón Atrás para volver a la página de resumen.

Verá que la implementación ha finalizado correctamente.
En un explorador web, vaya a la dirección URL asociada a la instancia de App Service para el entorno de prueba.

Si todavía tiene abierta la pestaña del explorador, actualice la página. Si no recuerda la dirección URL, búsquela en Azure Portal, en la página de detalles de App Service.

Verá que el sitio web de Space Game se implementa en App Service y está en funcionamiento.
Como paso opcional, seleccione Entornos en Azure Pipelines. Luego, seleccione el entorno de pruebas.

Azure Pipelines registra el historial de implementación. En el historial, puede llevar un seguimiento de los cambios en el entorno, hasta las confirmaciones de código y los elementos de trabajo.

Andy y Mara agregan la fase de pruebas a la canalización y le muestran los resultados a Amita.

Amita: Me gusta que los cambios se compilen y se implementen de modo que pueda probarlos por la mañana. Pero no veo cómo puedo controlar cuándo llegan los cambios al entorno de ensayo.

Mara: Sí, la implementación mediante la automatización ahorra mucho tiempo. Recuerda que solo hemos incluido el desencadenador programado. Vamos a agregar una aprobación de versión para ti cuando configuremos la fase de ensayo para Tim. De este modo, los cambios pasarán a la fase de ensayo solo cuando estés lista.

Ejercicio: Promoción a la fase de pruebas

Promoción de cambios a la fase de pruebas

Comentarios