Anterior

Siguientes

Ejercicio: Compilación de varias configuraciones con plantillas

Completado

En los ejercicios anteriores, se ha implementado una canalización que compila el sitio web de Space Game. Empezamos con un script que realizaba cada acción de compilación y asignaba cada acción a su tarea de canalización correspondiente. La salida de la canalización es un archivo .zip que contiene la aplicación web compilada.

En este ejercicio, usará una plantilla para definir tareas de compilación que puedan compilar cualquier configuración definida en el archivo de proyecto. Las plantillas permiten definir la lógica una vez y, después, reutilizarla varias veces. Combinan el contenido de varios archivos YAML en una sola canalización.

Sugerencia

Este paso del módulo es opcional. Si no desea obtener información sobre las plantillas en este momento, continúe con el paso siguiente: Limpieza del entorno de Azure DevOps. Para más información sobre las plantillas, consulte Uso y tipos de plantilla.

Comencemos viendo cómo van Mara y Amita.

Demostración

Mara, impaciente por compartir sus resultados, localiza a Amita para mostrarle la canalización de compilación.

Amita: Estoy impresionada de que hayas puesto esto en funcionamiento tan rápidamente. De hecho, iba de camino a verte porque he recibido un correo electrónico que me dice que la compilación estaba lista. ¡Gracias! Pero veo que la canalización compila solo la configuración Release. También usamos compilaciones Debug para capturar información adicional por si la aplicación se bloquea. ¿Podemos incluir eso?

Mara: Por supuesto. Cuando preparé todo esto, olvidé tener en cuenta las compilaciones Debug. ¿Qué te parece si nos ponemos a agregarlas ahora?

Amita: Me has enseñado el archivo YAML que define los pasos de compilación, pero no estoy segura de si sabría modificarlo.

Mara: No pasa nada. Puedes mirar mientras escribo. Podemos analizarlo detenidamente entre ambas.

¿Cómo se definirían las configuraciones de compilación?

Fíjese en las siguientes tareas que crean y publican la configuración Release del proyecto web Space Game (no agregue este código a su archivo azure-pipelines.yml).

- 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

Para compilar la configuración Debug, puede repetir estas dos tareas, pero reemplace Release por Debug.

Esto nos proporcionaría el resultado que buscamos, pero ¿qué ocurre cuando la compilación se vuelve más compleja o cambian los requisitos? Se necesitaría localizar y modificar manualmente las dos variaciones de cada tarea de compilación. Una vez agregados los requisitos de compilación adicionales, también habría que crear dos tareas (una para la configuración Debug y otra para Release) a fin de satisfacer esos requisitos.

Una solución mejor es usar una plantilla.

¿Qué son las plantillas?

Una plantilla permite definir tareas de compilación comunes una sola vez y reutilizar esas tareas varias veces.

Se puede llamar a una plantilla de la canalización principal como un paso de compilación. Se pueden pasar parámetros a una plantilla de la canalización principal.

Mara puede definir tareas para compilar y publicar la aplicación como una plantilla y, luego, aplicar dicha plantilla a cada configuración que necesite.

Definición de la plantilla

Recuerde que una plantilla permite definir tareas de compilación comunes una sola vez y reutilizar esas tareas varias veces. Se puede llamar a una plantilla de la canalización principal como un paso de compilación y pasar parámetros a una plantilla de la canalización principal.

Ahora se creará una plantilla que pueda compilar cualquier configuración definida en el archivo de proyecto.

1. En la consola integrada de Visual Studio Code, cree el directorio templates en la raíz del proyecto.

   mkdir templates
   

   En la práctica, puede poner un archivo de plantilla en cualquier ubicación. No tiene por qué ponerlo en el directorio templates.

2. En Visual Studio Code, seleccione Archivo > Nuevo archivo. Después, para guardar el archivo en blanco como build.yml en el directorio plantillas del proyecto, seleccione Archivo > Guardar. Un ejemplo sería ~/mslearn-tailspin-spacegame-web/templates.

   Importante

   Al igual que antes, en Windows, en la lista Save as type (Guardar como tipo), seleccione YAML.

3. En Visual Studio Code, agregue este código a build.yml:

   parameters:
     buildConfiguration: 'Release'
   
   steps:
   - task: DotNetCoreCLI@2
     displayName: 'Build the project - ${{ parameters.buildConfiguration }}'
     inputs:
       command: 'build'
       arguments: '--no-restore --configuration ${{ parameters.buildConfiguration }}'
       projects: '**/*.csproj'
   
   - task: DotNetCoreCLI@2
     displayName: 'Publish the project - ${{ parameters.buildConfiguration }}'
     inputs:
       command: 'publish'
       projects: '**/*.csproj'
       publishWebProjects: false
       arguments: '--no-build --configuration ${{ parameters.buildConfiguration }} --output $(Build.ArtifactStagingDirectory)/${{ parameters.buildConfiguration }}'
       zipAfterPublish: true
   

   Estas tareas se parecen a las que se han definido anteriormente para compilar y publicar la aplicación. Sin embargo, en una plantilla, se trabaja con los parámetros de entrada de forma diferente a como se haría con las variables normales. Estas son las dos diferencias:

   • En un archivo de plantilla, usamos la sección parameters en lugar de variables para definir las entradas.
   • En un archivo de plantilla, se usa la sintaxis ${{ }} en lugar de $() para leer el valor de un parámetro. Al leer el valor de un parámetro, incluirá la sección parameters en el nombre. Por ejemplo, ${{ parameters.buildConfiguration }}.

Llamada a la plantilla desde la canalización

Ahora se llamará a la plantilla que acabamos de crear desde la canalización. Lo haremos una vez con la configuración Debug y, luego, repetiremos el proceso con la configuración Release.

1. En Visual Studio Code, modifique azure-pipelines.yml tal como se ve aquí:

   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'
   
   - template: templates/build.yml
     parameters:
       buildConfiguration: 'Debug'
   
   - template: templates/build.yml
     parameters:
       buildConfiguration: 'Release'
   
   - task: PublishBuildArtifacts@1
     displayName: 'Publish Artifact: drop'
     condition: succeeded()
   

   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'
   
   - template: templates/build.yml
     parameters:
       buildConfiguration: 'Debug'
   
   - template: templates/build.yml
     parameters:
       buildConfiguration: 'Release'
   
   - task: PublishBuildArtifacts@1
     displayName: 'Publish Artifact: drop'
     condition: succeeded()
   

   Este archivo es similar al original, con la salvedad de que sustituye las tareas de compilación y publicación por llamadas a la plantilla que realiza las mismas tareas.

   Veremos que la plantilla se llama una vez con cada configuración. Cada tarea de template usa el argumento parameters para pasar el nombre de la configuración a la plantilla.

Ejecución de la canalización

Aquí podrá insertar los cambios en GitHub y ver la ejecución de canalización.

1. En el terminal integrado, agregue azure-pipelines.yml y templates/build.yml al índice, confirme los cambios e insértelos en GitHub.

   git add azure-pipelines.yml templates/build.yml
   git commit -m "Support build configurations"
   git push origin build-pipeline
   

2. Tal como se ha hecho anteriormente, en Azure Pipelines siga la compilación a lo largo de cada uno de los pasos.

   A medida que la canalización se ejecuta, veremos que el proceso expande las tareas dentro de la plantilla. Las tareas que compilan y publican el proyecto se ejecutan dos veces, una por cada configuración de compilación.

   

3. Cuando se complete la compilación, vuelva a la página Resumen y seleccione el artefacto publicado, tal como se ha hecho antes. Expanda la carpeta de entrega.

   Verá que la canalización genera un archivo .zip en las configuraciones Debug y Release.

   

Fusión de la rama (“branch”) con la principal mediante combinación con “merge”

Llegado este punto, tenemos una canalización de compilación operativa que lleva a cabo todo lo que Mara necesita ahora mismo.

En la práctica, enviaríamos una solicitud de incorporación de cambios que combine la rama build-pipeline en la rama main.

Omitiremos este paso por ahora. En el módulo siguiente, conoceremos algunas maneras de colaborar con el equipo en GitHub, incluido cómo enviar, revisar y combinar solicitudes de incorporación de cambios.

Continuar