Exercice : Créer le pipeline

Effectué

À ce stade, Mara a défini une configuration de build pour le site web Space Game. C’est maintenant à 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 la build. Quand vous créez un pipeline, le processus vous invite à fournir votre fichier YAML. Le projet n’a pas encore ce fichier.

Si vous ne fournissez pas de fichier YAML initial pour votre projet, Azure Pipelines peut en créer un pour vous en fonction du type de votre application. Ici, vous allez générer une application de type ASP.NET Core, mais Azure Pipelines fournit également des configurations de builds de démarrage pour d’autres types de projets, comme Java et Go, entre autres.

Créer le pipeline

1. Dans Azure DevOps, accédez à votre projet.

2. Dans la page du projet ou à partir du menu de gauche, sélectionnez Pipelines.

3. Sélectionnez Créer un pipeline (ou Nouveau pipeline s’il ne s’agit pas du premier pipeline du projet).

4. Sous l’onglet Se connecter, sélectionnez GitHub.

   À l’invite, entrez vos informations d’identification GitHub.

5. Sous l’onglet Sélectionner, sélectionnez votre dépôt mslearn-tailspin-spacegame-web.

6. Pour installer l’application Azure Pipelines, vous pouvez être redirigé vers GitHub. Si c’est le cas, faites défiler la page jusqu’en bas et sélectionnez Approuver et installer.

7. Sous l’onglet Configurer, sélectionnez ASP.NET Core.

   Notes

   Si vous ne voyez pas cette option, sélectionnez Afficher plus. Ne sélectionnez pas ASP.NET Core (.NET Framework).

   

8. Sous l’onglet Revue, examinez la configuration de build initiale.

   

   Il s’agit d’une configuration de base qu’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 référentiel Codespaces).

9. Sous l’onglet Revue, sélectionnez Enregistrer et exécuter. Pour valider vos modifications dans GitHub et démarrer le pipeline, choisissez Valider directement dans la branche primaire, puis sélectionnez Enregistrer et exécuter une deuxième fois. Si vous êtes invité à accorder l’autorisation avec un message tel que This pipeline needs permission to access a resource before this run can continue, choisissez Afficher et suivez les invites pour autoriser l’accès.

Observer l’exécution du pipeline

Sous Travaux, sélectionnez Travail. Tracez ensuite le processus de build tout au long des étapes de génération. Pour voir la sortie du travail sous forme de fichier texte une fois que la build est terminée, sélectionnez Afficher le journal brut du travail.

Si votre pipeline ne démarre pas rapidement, vérifiez que Codespaces est toujours en cours d’exécution. Codespaces s’arrête après 30 minutes et peut avoir à être redémarré.

Si l’état de votre pipeline reste En file d’attente et ne passe pas à En cours d’exécution après quelques instants, vérifiez vos travaux parallèles et demandez un octroi gratuit. Si vous n’avez pas accès aux travaux parallèles, vous pouvez recommencer le module avec Codespaces.

Vous voyez ci-dessous les étapes qui ont été créées par la définition de build. La définition prépare la machine virtuelle, récupère (fetch) le dernier code source disponible de GitHub, puis génère l’application.

Cette configuration est un excellent point de départ, car vous pouvez y ajouter des tâches de génération. Vous devez tout de même la mettre à jour pour répondre aux besoins de l’équipe Tailspin, par exemple afin de minifier les fichiers JavaScript et CSS.

Conseil

Consultez vos e-mails. Vous avez peut-être déjà reçu une notification de build, indiquant les résultats de votre exécution. Vous pouvez utiliser ce type de notification pour informer les membres de votre équipe quand les builds sont terminées et leur indiquer si elles ont réussi ou échoué.

Ajouter des tâches de génération

Maintenant que vous avez un processus de build opérationnel, vous pouvez commencer à y ajouter des tâches de génération.

Souvenez-vous que vous travaillez à partir de la branche main. Pour y conserver votre travail, vous allez maintenant créer une branche nommée build-pipeline. La branche est un endroit où vous pouvez expérimenter et faire fonctionner votre build entièrement sans impacter le travail du reste de l’équipe.

Vous pouvez ajouter directement des tâches de génération à azure-pipelines.yml depuis Azure Pipelines. Azure Pipelines permet de commiter directement vos modifications dans votre branche. Ici, vous allez modifier azure-pipelines.yml localement et pousser (ou charger) vos modifications vers GitHub. Cela vous permettra de mettre en pratique vos connaissances de Git. Regardez le pipeline générer automatiquement l’application quand vous poussez les modifications.

Dans la pratique, vous pouvez ajouter des tâches de génération une par une, pousser vos modifications, puis observer leur exécution. Vous allez maintenant ajouter toutes les tâches de génération que nous avons identifiées précédemment.

Notes

Vous êtes sur le point d’exécuter quelques commandes Git. Ne vous inquiétez pas si vous ne connaissez pas bien Git. Nous allons vous montrer ce que vous devez faire. Sachez également que nous nous intéresserons à Git plus en détail dans des modules ultérieurs.

1. Dans Visual Studio Code, accédez au terminal intégré. Vérifiez que vous accédez à la branche main dans votre dépôt, puis suivez les étapes.

2. Pour récupérer les dernières modifications apportées à GitHub et mettre à jour votre branche main, exécutez la commande git pull.

   git pull origin main
   

   Vous voyez d’après la sortie que Git récupère un fichier nommé azure-pipelines.yml. Il s’agit de la configuration du pipeline de démarrage qu’Azure Pipelines a créée pour vous. Quand vous configurez le pipeline, Azure Pipelines ajoute ce fichier à votre dépôt GitHub.

3. Pour créer une branche nommée build-pipeline, exécutez la commande git checkout :

   git checkout -B build-pipeline
   

4. Dans Visual Studio Code, modifiez azure-pipelines.yml comme ci-dessous :

   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'
   

   trigger:
   - '*'
   
   pool:
     vmImage: ubuntu-latest
   
   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 génération qui sont mappées à chacune des commandes de script que nous avons identifiées précédemment.

   Azure Pipelines fournit des tâches de génération intégrées qui sont mappées à diverses activités de build courantes. Par exemple, la tâche DotNetCoreCLI@2 correspond à l’utilitaire de ligne de commande dotnet. Le pipeline utilise DotNetCoreCLI@2 deux fois : une première fois pour restaurer, ou installer, les dépendances du projet, et une seconde fois pour générer le projet.

   N’oubliez pas que les activités de build ne sont pas toutes mappées à une tâche intégrée. Par exemple, il n’existe pas de tâche intégrée qui exécute l’utilitaire node-Sass ou qui écrit des informations sur la 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 la tâche script, car il s’agit d’un raccourci courant pour CmdLine@2.

   Dans l’étape de génération qui écrit les informations sur la build dans un fichier, les éléments suivants sont utilisés :

   • $(Build.DefinitionName)
   • $(Build.BuildId)
   • $(Build.BuildNumber)

   Ces éléments sont des variables intégrées qui sont fournies par le système et que vous pouvez utiliser dans vos pipelines :

   • $(Build.DefinitionName) est le nom du pipeline de build. Par exemple, « SpaceGame-Web-CI ».
   • $(Build.BuildId) est un identificateur numérique de la build terminée, comme 115.
   • $(Build.BuildNumber) est le nom de la build terminée. Vous pouvez configurer le format, mais par défaut, le numéro de build inclut la date du jour, suivie du numéro de build de ce jour-là. Exemple de numéro de build : « 20190329.1 ».

   Vous pouvez également définir vos propres variables, ce que vous ferez sous peu.

   Vous avez peut-être également remarqué la tâche UseDotNet@2, qui est la première étape de génération. Mara s’est souvenu que son script de génération n’a pas installé les outils de génération nécessaires. Bien que l’agent de build soit fourni avec plusieurs versions du SDK .NET, cette tâche permet à l’auteur du pipeline de facilement spécifier la version qu’elle souhaite utiliser sur l’agent de build.

5. À partir du terminal intégré, exécutez les commandes Git suivantes pour ajouter azure-pipelines.yml à l’index, commiter la modification et la pousser vers GitHub. Ces étapes sont similaires aux étapes que vous avez effectuées précédemment.

   Conseil

   Avant d’exécuter ces commandes Git, pensez à enregistrer azure-pipelines.yml.

   git add azure-pipelines.yml
   git commit -m "Add build tasks"
   git push origin build-pipeline
   

   Cette fois, vous poussez (push) la branche build-pipeline, pas la branche main, vers GitHub.

   Le fait de pousser (push) la branche vers GitHub déclenche le processus de génération dans Azure Pipelines.

6. Dans Azure Pipelines, accédez à votre build. Pour cela, sur le côté de la page, sélectionnez Pipelines, puis sélectionnez votre pipeline. Vous voyez votre message de commit et remarquez que la build s’exécute en utilisant le code de la branche build-pipeline.

   

   Conseil

   Si vous ne voyez pas la build immédiatement, patientez quelques instants ou actualisez la page.

7. Sélectionnez votre build, choisissez Travaux et suivez les tâches de génération pendant leur exécution.

   Par exemple, voici ce qui se passe quand la tâche gulp@1 s’exécute pour effectuer les tâches gulp qui minifient les ressources JavaScript et CSS :

   

   En cas d’échec d’une étape, l’erreur est signalée dans la sortie pour vous permettre de diagnostiquer et corriger le problème.

   Précédemment, vous avez exécuté une configuration de build minimale. Cette fois, quand la build se termine, vous voyez l’ensemble complet des tâches nécessaires pour générer l’application.

   

8. Quand votre build se termine, sélectionnez l’une des étapes pour afficher la progression globale de la build. À partir de là, vous pouvez accéder aux journaux de génération ou à la modification associée sur GitHub.