Ejercicio: Publicación del resultado en la canalización
Llegados a este punto, se puede compilar el proyecto web Space Game a través de la canalización.
¿Pero dónde van los resultados de la compilación? En este momento, la salida de la compilación permanece en el servidor de compilación temporal. Mara necesita una forma de hacer llegar esta compilación a Amita para que pueda empezar a realizar pruebas.
Puede almacenar artefactos de compilación en Azure Pipelines para que estén disponibles para otros usuarios del equipo una vez completada la compilación, que es lo que hará aquí. Como extra, también refactorizaremos la configuración de la compilación para usar variables; así, la configuración será más fácil de leer y mantener al día.
Nota:
Azure Pipelines permite implementar automáticamente la aplicación compilada en un entorno de prueba o de producción que se ejecute en la nube o en un centro de datos. Por ahora, el único objetivo de Mara es generar compilaciones para poder entregarlas a control de calidad mediante los procesos existentes.
Publicación de la compilación en la canalización
En .NET, puede empaquetar la aplicación como archivo .zip. Luego, puede usar la tarea integrada PublishBuildArtifacts@1
para publicar el archivo .zip en Azure Pipelines.
En Visual Studio Code, cambie azure-pipelines.yml tal como se ve aquí:
trigger: - '*' pool: name: 'Default' #replace if needed with name of your agent pool steps: - task: UseDotNet@2 displayName: 'Use .NET SDK 6.x' inputs: version: '6.x' - task: Npm@1 displayName: 'Run npm install' inputs: verbose: false - script: './node_modules/.bin/node-sass Tailspin.SpaceGame.Web/wwwroot --output Tailspin.SpaceGame.Web/wwwroot' 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: Tailspin.SpaceGame.Web/wwwroot - task: DotNetCoreCLI@2 displayName: 'Restore project dependencies' inputs: command: 'restore' projects: '**/*.csproj' - 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 - task: PublishBuildArtifacts@1 displayName: 'Publish Artifact: drop' condition: succeeded()
trigger: - '*' pool: vmImage: ubuntu-latest steps: - task: UseDotNet@2 displayName: 'Use .NET SDK 6.x' inputs: version: '6.x' - task: Npm@1 displayName: 'Run npm install' inputs: verbose: false - script: './node_modules/.bin/node-sass Tailspin.SpaceGame.Web/wwwroot --output Tailspin.SpaceGame.Web/wwwroot' 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: Tailspin.SpaceGame.Web/wwwroot - task: DotNetCoreCLI@2 displayName: 'Restore project dependencies' inputs: command: 'restore' projects: '**/*.csproj' - 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 - task: PublishBuildArtifacts@1 displayName: 'Publish Artifact: drop' condition: succeeded()
Esta versión de azure-pipelines.yml es similar a la versión anterior, pero agrega dos tareas más.
La primera tarea utiliza la tarea
DotNetCoreCLI@2
para publicar (o empaquetar) los resultados de compilación de la aplicación (dependencias incluidas) en una carpeta. El argumentozipAfterPublish
especifica que los resultados generados se van a incluir en un archivo .zip.La segunda tarea usa la tarea
PublishBuildArtifacts@1
para publicar el archivo .zip en Azure Pipelines. El argumentocondition
especifica que la tarea solo puede ejecutarse si la tarea anterior se realiza correctamente.succeeded()
es la condición predeterminada, por lo que no es necesario especificarla, pero se muestra aquí para mostrar su uso.Desde 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, recuerde guardar el archivo azure-pipelines.yml.
git add azure-pipelines.yml git commit -m "Add publish tasks" git push origin build-pipeline
Como hicimos antes, en Azure Pipelines, siga la compilación a lo largo de cada uno de los pasos.
Cuando se complete la canalización, vuelva al resumen de compilación.
En Relacionado, hay 1 publicado.
Seleccione el artefacto.
Expanda la carpeta de entrega.
Verá un archivo .zip que contiene la aplicación compilada y sus dependencias:
Si quiere probar un ejercicio opcional, puede descargar este archivo .zip en el equipo y explorar su contenido.
Definición de variables para mejorar la legibilidad
Mara retrocede para examinar su trabajo. La configuración de compilación hace lo que necesita, pero quiere asegurarse de que Andy y el resto pueden ayudar a mantenerla al día y ampliarla fácilmente.
Las variables permiten definir valores una vez y hacer referencia a esos valores a lo largo de la canalización. Azure Pipelines reemplaza cada variable por su valor actual cuando la canalización se ejecuta.
Al igual que en otros lenguajes de programación, las variables permiten hacer cosas como las siguientes:
- Definir valores que podrían cambiar entre las ejecuciones de la canalización.
- Almacenar la información que se repite a lo largo de la canalización, como un número de versión o una ruta de acceso de archivo, en un mismo lugar. De este modo, no será necesario actualizar todas las apariciones cuando las suyas deban modificarse.
Azure Pipelines proporciona muchas variables integradas. Estas variables describen aspectos del proceso de compilación, como el identificador de compilación y los nombres de directorio en los que se ha compilado y preconfigurado el software.
También puede definir sus propias variables. Este es un ejemplo que muestra una variable denominada buildConfiguration
, que define la configuración de una compilación Release:
variables:
buildConfiguration: 'Release'
Use variables cuando repita varias veces el mismo valor, o cuando exista la posibilidad de que un valor, como una versión de dependencia, cambie.
No es necesario crear una variable por cada parte de la configuración de compilación. De hecho, usar muchas variables puede hacer que el código de la canalización sea más difícil de leer y comprender.
Dedique un momento a examinar azure-pipelines.yml. Tenga en cuenta que estos valores se repiten:
- Configuración de compilación:
Release
. - Ubicación del directorio wwwroot:
Tailspin.SpaceGame.Web/wwwroot
. - Versión del SDK de .NET:
6.x
.
Ahora se usan variables para definir estos valores una vez. Después, se hace referencia a las variables a lo largo de la canalización.
En Visual Studio Code, cambie azure-pipelines.yml tal como se ve aquí:
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' - 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 - task: PublishBuildArtifacts@1 displayName: 'Publish Artifact: drop' condition: succeeded()
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' - 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 - task: PublishBuildArtifacts@1 displayName: 'Publish Artifact: drop' condition: succeeded()
Fíjese en la sección
variables
, donde se definen estas variables:buildConfiguration
: especifica la configuración de compilación.wwwrootDir
: especifica la ruta de acceso al directorio wwwroot.dotnetSdkVersion
: especifica la versión del SDK de .NET que se va a usar.
Para hacer referencia a estas variables, use la sintaxis
$()
, igual que cuando lo hace para variables integradas. Este es el paso en el que se ejecuta node-Sass para convertir archivos Sass a CSS. En él, se hace referencia a la variablewwwrootDir
para obtener la ruta de acceso al directorio wwwroot.- script: './node_modules/.bin/node-sass $(wwwrootDir) --output $(wwwrootDir)' displayName: 'Compile Sass assets'
El comando del script utiliza esta variable para definir tanto el directorio de origen de los archivos Sass como el directorio donde se van a escribir los archivos CSS. También usa la variable para definir el nombre de tarea que se muestra en la interfaz de usuario.
Desde el terminal integrado, agregue azure-pipelines.yml al índice, confirme el cambio e insértelo en GitHub.
git add azure-pipelines.yml git commit -m "Refactor common variables" git push origin build-pipeline
En Azure Pipelines, siga la compilación a lo largo de cada uno de los pasos.
Verá que las variables se reemplazan por sus valores cuando la compilación se ejecuta. Por ejemplo, esta es la tarea
UseDotNet@2
que establece la versión del SDK de .NET que se va a usar.Al igual que antes, para ver el artefacto cuando se completa la compilación, puede navegar al resumen de la compilación.
¡Enhorabuena! Ha usado Azure Pipelines y ha creado su primer artefacto de compilación correctamente.