Exercice – Publier le résultat dans le pipeline
Choisissez votre environnement de développement pour le module de formation.
- Environnement de développement local utilisant un agent hébergé par Microsoft
- Environnement de développement GitHub Codespaces utilisant un agent auto-hébergé.
À ce stade, vous pouvez compiler le projet web Space Game via le pipeline.
Mais où vont les résultats du build ?
Actuellement, la sortie du build reste sur le serveur de build temporaire.
Mara a besoin d’un moyen de transmettre ce build à Amita pour qu’elle puisse commencer les tests.
Vous pouvez stocker les artefacts de build dans Azure Pipelines afin qu’ils soient disponibles pour les autres membres de votre équipe une fois le build terminé — c’est ce que vous allez faire ici.
En bonus, vous allez également réorganiser la configuration du build en utilisant des variables, ce qui rendra le fichier plus lisible et plus facile à maintenir.
Remarque
Azure Pipelines vous permet de déployer automatiquement l’application compilée vers un environnement de test ou de production, que ce soit dans le cloud ou dans votre centre de données.
Pour l’instant, l’objectif de Mara est simplement de produire des builds qu’elle peut transmettre à l’équipe QA en utilisant leurs processus existants.
Publier le build dans le pipeline
Avec .NET, vous pouvez empaqueter votre application dans un fichier .zip.
Vous pouvez ensuite utiliser la tâche intégrée PublishBuildArtifacts@1 pour publier ce fichier .zip dans Azure Pipelines.
Dans Visual Studio Code, modifiez le fichier azure-pipelines.yml comme indiqué ici :
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()Cette version du fichier azure-pipelines.yml ressemble à la version précédente, mais elle ajoute deux tâches supplémentaires.
- La première tâche utilise
DotNetCoreCLI@2pour publier ou empaqueter les résultats du build de l’application (y compris ses dépendances) dans un dossier.
L’argumentzipAfterPublishindique qu’il faut ajouter les résultats compilés dans un fichier.zip. - La deuxième tâche utilise
PublishBuildArtifacts@1pour publier le fichier.zipdans Azure Pipelines.
L’argumentconditionindique que cette tâche ne doit s’exécuter que si la tâche précédente réussit.succeeded()est la condition par défaut, donc vous n’avez pas besoin de la spécifier, mais elle est montrée ici à titre d’exemple.
Depuis le terminal intégré, exécutez les commandes Git suivantes pour :
- Ajouter
azure-pipelines.ymlà l’index - Valider la modification
- Pousser la modification sur GitHub
💡 Astuce
Avant d’exécuter ces commandes Git, n’oubliez pas d’enregistrer le fichier azure-pipelines.yml.
git add azure-pipelines.yml
git commit -m "Add publish tasks"
git push origin build-pipelineUne fois le build terminé, comme précédemment, suivez l’exécution du pipeline étape par étape dans Azure Pipelines.
Lorsque le pipeline est terminé, revenez au résumé du build.
Sous la section « Related » (Associé), vous verrez « 1 publié », indiquant qu’un artefact de build a été publié.
Sélectionnez l’artefact.
Dépliez le dossier drop.
Vous verrez un fichier .zip contenant votre application compilée ainsi que ses dépendances.
Si vous souhaitez essayer un exercice facultatif, vous pouvez télécharger ce fichier .zip sur votre ordinateur et explorer son contenu.
Définir des variables pour améliorer la lisibilité
Mara prend du recul pour examiner son travail.
La configuration du build répond à ses besoins, mais elle souhaite s’assurer qu’Andy et les autres pourront facilement la maintenir et l’étendre.
Les variables permettent de définir une valeur une seule fois et de la réutiliser dans tout le pipeline.
Azure Pipelines remplace chaque variable par sa valeur actuelle lors de l’exécution du pipeline.
Comme dans d’autres langages de programmation, les variables permettent de :
- Définir des valeurs susceptibles de changer entre les exécutions du pipeline.
- Stocker des informations répétées dans le pipeline, comme un numéro de version ou un chemin de fichier, à un seul endroit.
Ainsi, vous n’avez pas besoin de mettre à jour toutes les occurrences lorsque la valeur change.
Azure Pipelines fournit de nombreuses variables intégrées.
Ces variables décrivent des aspects du processus de build, comme :
- L’identifiant du build
- Les noms de répertoires où votre logiciel est compilé et préparé
Vous pouvez également définir vos propres variables.
Voici un exemple qui montre une variable nommée buildConfiguration définissant la configuration de build Release :
variables:
buildConfiguration: 'Release'Utilisez des variables lorsque vous répétez la même valeur plusieurs fois ou lorsqu’une valeur, comme une version de dépendance, est susceptible de changer.
Vous n’avez pas besoin de créer une variable pour chaque élément de votre configuration de build.
En fait, trop de variables peuvent rendre le code du pipeline plus difficile à lire et à comprendre pour les autres.
Prenez un moment pour examiner le fichier azure-pipelines.yml.
Remarquez que les valeurs suivantes sont répétées :
- Configuration de build :
Release - Emplacement du répertoire
wwwroot:Tailspin.SpaceGame.Web/wwwroot - Version du SDK .NET :
6.x
Vous allez maintenant utiliser des variables pour définir ces valeurs une seule fois, puis les référencer dans tout le pipeline.
Dans Visual Studio Code, modifiez le fichier azure-pipelines.yml comme indiqué ici :
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()Remarquez la section variables, qui définit les variables suivantes :
buildConfiguration: Spécifie la configuration de build.wwwrootDir: Spécifie le chemin vers le répertoirewwwroot.dotnetSdkVersion: Spécifie la version du SDK .NET à utiliser.
Pour référencer ces variables, utilisez la syntaxe $(), comme vous le feriez pour les variables intégrées.
Voici un exemple d’étape qui exécute node-sass pour convertir les fichiers Sass en CSS.
Pour obtenir le chemin vers le répertoire wwwroot, elle référence la variable wwwrootDir.
- script: './node_modules/.bin/node-sass $(wwwrootDir) --output $(wwwrootDir)'
displayName: 'Compile Sass assets'La commande de script utilise la variable pour définir à la fois le répertoire source des fichiers Sass et le répertoire dans lequel écrire les fichiers CSS. Elle utilise également la variable pour définir le nom de la tâche affiché dans l’interface utilisateur.
Depuis le terminal intégré, ajoutez le fichier azure-pipelines.yml à l’index, validez la modification (commit) et poussez-la sur GitHub.
git add azure-pipelines.yml
git commit -m "Refactor common variables"
git push origin build-pipelineDepuis Azure Pipelines, suivez la construction (build) à travers chacune des étapes.
Vous verrez que les variables sont remplacées par leurs valeurs lorsque la construction s’exécute. Par exemple, voici la tâche UseDotNet@2 qui définit la version du SDK .NET à utiliser.
Comme précédemment, pour voir l’artéfact une fois la construction terminée, vous pouvez naviguer vers le résumé de la build.
Félicitations ! Vous avez utilisé Azure Pipelines avec succès et créé votre premier artéfact de build.
