Ejercicio: promoción a la fase de ensayo
La canalización de versión tiene ahora tres fases: compilación, desarrollo y pruebas. Usted y el equipo de Tailspin deben implementar una fase más: la de ensayo.
En esta parte, hará lo siguiente:
- Creará el entorno de ensayo en Azure Pipelines y se asignará a sí mismo como aprobador.
- Definirá la fase de ensayo, que solo se ejecuta después de que un aprobador compruebe los resultados de la fase de pruebas.
Creación del entorno de ensayo
En este caso, creará un entorno en Azure Pipelines para la fase de ensayo. Con fines de aprendizaje, se asignará a sí mismo como aprobador. En la práctica, asignaría a los usuarios que deben aprobar los cambios antes de que estos pasen a la fase siguiente. En el equipo de Tailspin, Amita aprueba los cambios para que se puedan promover de la fase de pruebas a la de ensayo.
Anteriormente en este módulo, especificó las opciones de configuración de environment
de las fases de desarrollo y pruebas. Este es un ejemplo de la fase de desarrollo.
- stage: 'Deploy'
displayName: 'Deploy the web application'
dependsOn: Build
jobs:
- deployment: Deploy
pool:
vmImage: 'ubuntu-20.04'
environment: dev
variables:
- group: Release
Puede definir un entorno mediante Azure Pipelines que incluya criterios específicos para su versión. Estos criterios pueden incluir las canalizaciones que están autorizadas para implementarse en el entorno. También puede especificar las aprobaciones humanas necesarias para promover la versión de una fase a la siguiente. Aquí especificará esas aprobaciones.
Para crear el entorno de ensayo:
En Azure Pipelines, seleccione Entornos.
Seleccione Nuevo entorno.
En Nombre, escriba staging (ensayo).
Deje los campos restantes con sus valores predeterminados.
Seleccione Crear.
En la página del entorno staging, abra la lista desplegable y seleccione Aprobaciones y comprobaciones.
Seleccione Aprobaciones.
En Aprobadores, seleccione Agregar usuarios y grupos y, luego, seleccione su cuenta.
En Instructions to approvers (Instrucciones para los aprobadores), escriba Approve this change when it's ready for staging (Aprobar este cambio cuando esté listo para la fase de ensayo).
Seleccione Crear.
Promoción de los cambios a la fase de ensayo
Aquí modificará la configuración de la canalización para implementar la compilación en la fase de ensayo.
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' - stage: 'Staging' displayName: 'Deploy to the staging environment' dependsOn: Test jobs: - deployment: Deploy pool: vmImage: 'ubuntu-20.04' environment: staging 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: '$(WebAppNameStaging)' package: '$(Pipeline.Workspace)/drop/$(buildConfiguration)/*.zip'
Este código agrega la fase de ensayo. La fase se implementa en el entorno de ensayo, que incluye una aprobación de versión.
Sugerencia
Probablemente se haya dado cuenta de que las tres fases de implementación siguen unos pasos similares. Puede usar plantillas para definir una vez las tareas comunes de compilación y reutilizarlas varias veces. Ya ha usado esta técnica en el módulo Creación de una canalización de compilación con Azure Pipelines. Estamos repitiendo los pasos de cada fase con fines de aprendizaje.
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 Staging" git push origin release
En Azure Pipelines, vaya a la compilación. Realice el seguimiento de la compilación a medida que se ejecuta.
Cuando la compilación alcance la fase de ensayo, verá que la canalización espera a que se pasen todas las comprobaciones. En este caso, hay una comprobación: la aprobación manual de la versión.
Puede configurar Azure DevOps de modo que le envíe una notificación por correo electrónico cuando la compilación requiera aprobación. Este es un ejemplo:
Seleccione Revisar>Aprobar.
En la práctica, debe revisar los cambios para comprobar que cumplen los requisitos.
Una vez finalizada la compilación, abra un explorador web. Vaya a la dirección URL asociada a la instancia de App Service para el entorno de ensayo.
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. Después, seleccione el entorno staging.
Azure Pipelines registra el historial de implementación, lo que le permite llevar un seguimiento de los cambios en el entorno, hasta las confirmaciones de código y los elementos de trabajo.
El equipo de Tailspin se reúne para hablar sobre el progreso. Amita aprueba los cambios en la fase de pruebas mientras los demás la observan.
Tim: La verdad es que al principio las canalizaciones de versión automatizadas me asustaban un poco, pero ahora me veo que funcionan me gustan mucho. Cada fase puede tener su propio entorno, pruebas asociadas y aprobadores. La canalización automatiza muchas tareas que teníamos que hacer manualmente, pero todavía tenemos el control donde lo necesitamos.
Amita: Podríamos hacer algo similar para promover los cambios de la fase de ensayo a la de producción. Por cierto, ¿cuándo agregaremos un entorno de producción?
Andy: En breve. Creo que todavía tenemos que pulir algunas cosas.