Ejercicio: Promoción a la fase de desarrollo

El equipo tiene un plan y está listo para empezar a implementar su pipeline de lanzamiento. El proyecto de Azure DevOps está configurado y las instancias de Azure App Service están listas para recibir artefactos de compilación.

En este punto, recuerde que la canalización del equipo tiene solo dos fases. En la primera fase, se genera el artefacto de compilación. La segunda fase implementa la aplicación web Space Game en App Service. Aquí, sigue junto a Andy y Mara a medida que modifican la tubería. Se implementarán en el entorno de App Service correspondiente a la fase de desarrollo .

Aquí, usas un trigger de CI para iniciar el proceso de construcción.

Captura de la rama de GitHub

Aquí, obtienes la rama release de GitHub. También puede extraer del repositorio esa rama o cambiar a ella.

Esta rama sirve como rama de versión. Contiene el proyecto Space Game usado en módulos anteriores. También contiene una configuración de Azure Pipelines con la que empezar.

Para capturar la rama y cambiar a ella:

1. En Visual Studio Code, abra el terminal integrado.

2. Para capturar una rama denominada release desde el repositorio de Microsoft y cambiar a esa rama, ejecute los siguientes git comandos.

   git fetch upstream release
   git checkout -B release upstream/release
   

   El formato de estos comandos permite obtener código de inicio del repositorio de Microsoft GitHub, conocido como upstream. En breve, vas a subir esta rama a tu repositorio de GitHub, conocido como origin.

3. Como paso opcional, en Visual Studio Code, abra azure-pipelines.yml. Familiarícese con la configuración inicial.

   Nota:

   Una configuración más sólida podría especificar las ramas que participan en el proceso de compilación. Por ejemplo, para facilitar la comprobación de la calidad del código, podríamos ejecutar pruebas unitarias cada vez que insertemos un cambio en cualquier rama. También podríamos implementar la aplicación en un entorno que realice pruebas más exhaustivas. Pero esta implementación solo se realiza cuando se tiene una solicitud de cambios, cuando se tiene una versión candidata para lanzamiento o cuando se combina código en la rama principal.

   Para más información, consulte Implementar un flujo de trabajo de código en la canalización de compilación mediante Git y GitHub y Desencadenadores de la canalización de compilación.

Promoción de cambios en la fase de desarrollo

Aquí modificará la configuración de la canalización para promover la compilación a la fase de desarrollo.

1. En Visual Studio Code, modifique azure-pipelines.yml.

   trigger:
   - '*'
   
   variables:
     buildConfiguration: 'Release'
     releaseBranchName: 'release'
   
   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'
   

   Esta configuración es similar a la que creó en el módulo anterior. Allí, usted y el equipo crearon una prueba de concepto para la implementación continua. Pero tenga en cuenta estas diferencias, que se resaltan en el ejemplo de código anterior:

   • Esta configuración define variables al principio del archivo. Las variables se utilizan a lo largo de todo el flujo de trabajo. Definen qué configuración se va a compilar (Release). así como el nombre de la rama de versión (release).
   • La fase Implementar a partir de la prueba de concepto ahora se denomina Dev.
   • La fase de desarrollo usa una condición que dirige al sistema para ejecutar la fase solo cuando la fase anterior se realiza correctamente y la rama actual es release. Esta configuración garantiza que las características de versión solo se implementan en el entorno de desarrollo .
   • El paso de implementación utiliza la variable WebAppNameDev para desplegar en la instancia de App Service asociada con el entorno Dev.

   Nota:

   En la práctica, puede realizar la implementación desde otra rama, como main. Puede incluir lógica que permita que los cambios se promuevan a la fase de desarrollo desde varias ramas, como release y main.

2. En el terminal integrado, agregue azure-pipelines.yml al índice. 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 Dev stage"
   git push origin release
   

3. En Azure Pipelines, vaya a la compilación. A medida que se ejecuta, haga un seguimiento de la compilación.

4. Una vez finalizada la compilación, para volver a la página de resumen, seleccione el botón Atrás.

   

   Verá que la implementación finalizó correctamente.

5. En un explorador web, vaya a la dirección URL asociada a la instancia de App Service para el entorno de desarrollo.

   Si sigue teniendo abierta la pestaña del explorador, actualice la página. Si no recuerda la dirección URL, encuéntrela en el portal de Azure, en la página de detalles del App Service.

   Verá que el sitio web de Space Game está implementado en App Service y que se está ejecutando.

   

6. Como paso opcional, en Azure Pipelines, seleccione Entornos. A continuación, seleccione el entorno de desarrollo .

   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.