Exercice – Créez 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, Mara a défini une configuration de build pour le site web Space Game.
Maintenant, c’est à votre tour : vous allez créer un pipeline et produire votre premier artefact de build.
Comme vous l’avez vu, Mara a utilisé un fichier YAML pour définir le build. Lorsque vous créez un pipeline, le processus vous demande votre fichier YAML. Le projet ne contient pas encore ce fichier.
Lorsque vous ne fournissez pas de fichier YAML initial pour votre projet, Azure Pipelines peut en créer un pour vous en fonction du type d’application. Ici, vous allez compiler une application ASP.NET Core, mais Azure Pipelines propose également des configurations de build de démarrage pour d’autres types de projets, comme Java, Go, et bien d’autres.
Créer le pipeline
- Dans Azure DevOps, accédez à votre projet.
- Depuis la page du projet ou le panneau de gauche, sélectionnez Pipelines.
- Sélectionnez Créer un pipeline (ou Nouveau pipeline si ce n’est pas le premier pipeline du projet).
- Dans l’onglet Connexion, sélectionnez GitHub.
- Lorsque vous y êtes invité, entrez vos identifiants GitHub.
- Dans l’onglet Sélection, choisissez votre dépôt mslearn-tailspin-spacegame-web.
- Pour installer l’application Azure Pipelines, vous pouvez être redirigé vers GitHub. Si c’est le cas, faites défiler vers le bas et sélectionnez Approuver et installer.
- Dans l’onglet Configuration, sélectionnez ASP.NET Core.
Remarque
Si vous ne voyez pas cette option, cliquez sur Afficher plus.
Ne sélectionnez pas ASP.NET Core (.NET Framework).
Remarque
Si votre dépôt contient un fichier azure-pipelines.yml à la racine, Azure DevOps peut ignorer l’étape de configuration.
Pour résoudre ce problème, supprimez ou renommez le fichier.
8. Dans l’onglet Révision, notez la configuration initiale du build.
Il s’agit d’une configuration très basique que Azure DevOps vous fournit en fonction du type de votre application, ici ASP.NET Core.
La configuration par défaut utilise un agent hébergé par Microsoft.
Remplacez le texte vmImage: ubuntu-latest par name: Default (ou le nom de votre pool d’agents si vous avez spécifié un pool différent lors de la configuration des secrets du dépôt Codespaces).
Dans l’onglet Révision, sélectionnez Enregistrer et exécuter.
Pour valider vos modifications sur GitHub et démarrer le pipeline :
- Choisissez Valider directement sur la branche main.
- Sélectionnez Enregistrer et exécuter une seconde fois.
Si vous êtes invité à accorder une autorisation avec un message du type Ce pipeline a besoin d’une autorisation pour accéder à une ressource avant de pouvoir continuer, sélectionnez Afficher et suivez les instructions pour autoriser l’accès.
Suivez l’exécution du pipeline
- Sous Jobs, sélectionnez Job.
- Ensuite, suivez le processus de build étape par étape.
- Pour voir la sortie du job sous forme de fichier texte une fois le build terminé, vous pouvez aussi sélectionner Afficher le journal brut (View raw log).
Si votre pipeline ne démarre pas rapidement, vérifiez que Codespaces est toujours actif.
Codespaces se ferme automatiquement après 30 minutes et peut nécessiter un redémarrage.
Ici, vous voyez les étapes créées par la définition du build :
- Préparation de la machine virtuelle (VM)
- Récupération du dernier code source depuis GitHub
- Compilation de l’application
Cette configuration est un excellent point de départ, car vous avez maintenant un endroit où ajouter des tâches de build.
Vous devez encore la mettre à jour pour répondre aux besoins de l’équipe Tailspin, comme la minification des fichiers JavaScript et CSS.
💡 Astuce
Vérifiez votre boîte mail. Vous avez peut-être déjà reçu une notification de build avec les résultats de l’exécution.
Vous pouvez utiliser ces notifications pour informer les membres de votre équipe lorsque les builds sont terminés, et indiquer si chaque build a réussi ou échoué.
Ajouter des tâches de build
Maintenant que vous avez un processus de build fonctionnel, vous pouvez commencer à ajouter des tâches de build.
Rappelez-vous que vous travaillez depuis la branche main. Pour conserver votre travail, vous allez maintenant créer une branche nommée build-pipeline.
Cette branche vous permet d’expérimenter et de finaliser votre build sans impacter le reste de l’équipe.
Vous pouvez ajouter des tâches de build au fichier azure-pipelines.yml directement depuis Azure Pipelines.
Azure Pipelines validera vos modifications directement dans votre branche.
Ici, vous allez modifier le fichier azure-pipelines.yml localement et pousser (ou téléverser) vos modifications sur GitHub.
Cette méthode vous permet de pratiquer vos compétences Git.
Observez comment le pipeline compile automatiquement l’application lorsque vous poussez des modifications.
En pratique, vous pourriez ajouter les tâches de build une par une, pousser vos modifications, et observer l’exécution du build.
Ici, vous allez ajouter toutes les tâches de build identifiées précédemment en une seule fois.
Remarque
Vous allez exécuter quelques commandes Git.
Ne vous inquiétez pas si vous débutez avec Git — nous allons vous montrer quoi faire.
Nous approfondirons Git dans les modules suivants.
Dans Visual Studio Code, ouvrez le terminal intégré.
Assurez-vous d’être sur la branche main de votre dépôt, puis suivez les étapes suivantes.
Pour récupérer les dernières modifications depuis GitHub et mettre à jour votre branche main, exécutez la commande suivante :
git pull origin mainVous verrez dans la sortie que Git récupère un fichier nommé azure-pipelines.yml.
Il s’agit de la configuration de pipeline de démarrage qu’Azure Pipelines a créée pour vous.
Lorsque vous configurez le pipeline, Azure Pipelines ajoute ce fichier à votre dépôt GitHub.
Pour créer une branche nommée build-pipeline, exécutez la commande suivante :
git checkout -B build-pipelineDans Visual Studio Code, modifiez le fichier azure-pipelines.yml comme indiqué ici :
trigger:
- '*'
pool:
name: 'Default' # Replace Default with the name of your agent pool if you used a different pool
variables:
buildConfiguration: 'Release'
steps:
- task: UseDotNet@2
displayName: 'Use .NET SDK 6.x'
inputs:
packageType: sdk
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'Sous la section steps, vous voyez les tâches de build qui correspondent à chacune des commandes du script que nous avons identifiées précédemment.
Azure Pipelines fournit des tâches de build intégrées qui correspondent à de nombreuses activités de build courantes.
Par exemple, la tâche DotNetCoreCLI@2 correspond à l’utilitaire en ligne de commande dotnet.
Le pipeline utilise DotNetCoreCLI@2 deux fois : une fois pour restaurer (installer) les dépendances du projet, et une autre fois pour compiler le projet.
Rappel :
Toutes les activités de build ne correspondent pas à une tâche intégrée.
Par exemple, il n’existe pas de tâche intégrée pour exécuter l’utilitaire node-sass, ni pour écrire des informations de build dans un fichier texte.
Pour exécuter des commandes système générales, vous utilisez la tâche CmdLine@2 ou script.
Le pipeline utilise ici la tâche script, car c’est un raccourci courant pour CmdLine@2.
Dans l’étape de build qui écrit des informations sur le build dans un fichier, remarquez les éléments suivants :
$(Build.DefinitionName)$(Build.BuildId)$(Build.BuildNumber)
Ce sont des variables intégrées que le système fournit pour une utilisation dans vos pipelines :
$(Build.DefinitionName): nom du pipeline de build, par exemple"SpaceGame-Web-CI".$(Build.BuildId): identifiant numérique du build terminé, par exemple115.$(Build.BuildNumber): nom du build terminé. Vous pouvez configurer le format, mais par défaut, le numéro de build inclut la date actuelle suivie du numéro de build du jour. Exemple :"20190329.1".
Vous pouvez également définir vos propres variables, ce que vous ferez bientôt.
Vous avez peut-être aussi remarqué la tâche UseDotNet@2, qui est la première étape de build.
Mara s’est souvenue que le script de build n’installait pas les outils nécessaires.
Bien que l’agent de build dispose de plusieurs versions du SDK .NET, cette tâche permet à l’auteur du pipeline de spécifier facilement la version à utiliser sur l’agent.
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
Ces étapes sont similaires à celles que vous avez effectuées précédemment.
💡 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 build tasks"
git push origin build-pipelineCette fois-ci, vous poussez la branche build-pipeline, et non la branche main, vers GitHub.
Le push de la branche vers GitHub déclenche le processus de build dans Azure Pipelines.
Dans Azure Pipelines, accédez à votre build :
- Sur le côté de la page, sélectionnez Pipelines.
- Puis sélectionnez votre pipeline.
Vous verrez votre message de commit et que le build est en cours d’exécution en utilisant le code de la branche build-pipeline.
💡 Astuce
Si vous ne voyez pas le build immédiatement, attendez quelques instants ou actualisez la page.
Sélectionnez votre build, puis choisissez Jobs pour suivre l’exécution des tâches de build.
Par exemple, voici ce qui se passe lorsque la tâche gulp@1 s’exécute pour effectuer les tâches Gulp qui minifient les fichiers JavaScript et CSS :
Si une étape échoue, vous verrez l’erreur dans la sortie, ce qui vous permettra de diagnostiquer et corriger le problème.
Plus tôt, vous avez exécuté une configuration de build plus minimale.
Cette fois-ci, lorsque le build se termine, vous voyez un ensemble plus complet de tâches nécessaires pour compiler l’application.
Une fois le build terminé, sélectionnez n’importe quelle étape pour voir la progression globale du build.
À partir de là, vous pouvez accéder aux journaux de build ou à la modification associée sur GitHub.
