Exercice – Créer plusieurs configurations en utilisant des modèles
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é.
Dans les exercices précédents, vous avez mis en place un pipeline qui compile le site web du jeu Space Game. Vous avez commencé avec un script qui exécutait chaque action de compilation et vous avez associé chaque action à sa tâche correspondante dans le pipeline. Le résultat du pipeline est un fichier .zip contenant l’application web compilée.
Dans cet exercice, vous allez utiliser un modèle pour définir des tâches de compilation capables de compiler n’importe quelle configuration définie dans le fichier de projet. Les modèles permettent de définir une logique une seule fois et de la réutiliser plusieurs fois. Ils combinent le contenu de plusieurs fichiers YAML en un seul pipeline.
💡 Conseil
Cette étape du module est optionnelle. Si vous ne souhaitez pas apprendre les modèles pour le moment, passez à l’étape suivante : Nettoyer votre environnement Azure DevOps.
Pour en savoir plus sur les modèles, consultez : Types de modèles et leur utilisation.
Commençons par retrouver Mara et Amita.
La démonstration
Mara, enthousiaste à l’idée de partager ses résultats, retrouve Amita pour lui montrer le pipeline de compilation.
Amita : Je suis impressionnée que tu aies réussi à faire fonctionner ça aussi vite ! En fait, je venais justement te voir parce que j’ai reçu un e-mail m’informant que la compilation était prête. Merci ! Je vois que le pipeline compile uniquement la configuration Release. Nous utilisons aussi des compilations Debug pour capturer des informations supplémentaires en cas de crash de l’application. Peut-on l’ajouter ?
Mara : Absolument. J’ai oublié de prendre en compte les compilations Debug quand j’ai mis ça en place. Et si on s’asseyait ensemble pour l’ajouter ?
Amita : Tu m’as montré le fichier YAML qui définit les étapes de compilation, mais je ne suis pas sûre de savoir comment le modifier.
Mara : Pas de souci. Tu peux regarder pendant que je tape. On peut y réfléchir ensemble.
Comment pourriez-vous définir les deux configurations de compilation ?
Voici les tâches qui compilent et publient la configuration Release du projet web Space Game.
(Ne copiez pas ce code dans votre fichier azure-pipelines.yml pour l’instant.)
- 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: truePour compiler la configuration Debug, vous pourriez répéter ces deux tâches, mais en remplaçant Release par Debug.
Cela vous donnerait le résultat souhaité, mais que se passe-t-il si votre processus de compilation devient plus complexe ou si vos exigences évoluent ?
Vous devrez alors localiser et modifier manuellement chaque variante de chaque tâche de compilation.
Et après avoir ajouté de nouvelles exigences de compilation, vous devrez créer deux tâches supplémentaires, une pour la configuration Debug et une pour Release, afin de répondre à ces nouvelles exigences.
Une meilleure solution consiste à utiliser un modèle.
Qu’est-ce qu’un modèle ?
Un modèle vous permet de définir une fois des tâches de compilation communes et de les réutiliser plusieurs fois.
Vous appelez un modèle depuis le pipeline parent comme une étape de compilation. Vous pouvez également passer des paramètres au modèle depuis le pipeline parent.
Mara peut définir les tâches de compilation et de publication de l’application sous forme de modèle, puis appliquer ce modèle à chaque configuration dont elle a besoin.
Définir le modèle
Rappelez-vous qu’un modèle permet de définir une fois des tâches de compilation communes et de les réutiliser plusieurs fois.
Vous appelez un modèle depuis son pipeline parent comme une étape de compilation, et vous pouvez lui transmettre des paramètres.
Vous allez maintenant créer un modèle capable de compiler n’importe quelle configuration définie dans le fichier de projet.
Depuis la console intégrée de Visual Studio Code, à la racine de votre projet, créez un répertoire nommé templates.
mkdir templatesEn pratique, vous pouvez placer un fichier de modèle (template) à n’importe quel emplacement.
Il n’est pas obligatoire de le mettre dans le répertoire templates.
Dans Visual Studio Code, sélectionnez Fichier > Nouveau fichier.
Ensuite, pour enregistrer ce fichier vierge sous le nom build.yml dans le répertoire templates de votre projet, sélectionnez Fichier > Enregistrer.
Un exemple de chemin serait : ~/mslearn-tailspin-spacegame-web/templates.
Important
Comme précédemment, sous Windows, dans la liste Type d’enregistrement, sélectionnez YAML.
Dans Visual Studio Code, ajoutez le code suivant dans le fichier 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: trueCes tâches ressemblent à celles que vous avez définies précédemment pour compiler et publier l’application ; mais dans un modèle, vous travaillez avec des paramètres d’entrée différemment des variables classiques. Voici deux différences importantes :
- Dans un fichier de modèle, utilisez la section
parametersau lieu devariablespour définir les entrées. - Dans un fichier de modèle, utilisez la syntaxe
${{ }}au lieu de$()pour lire la valeur d’un paramètre.
Lorsque vous lisez la valeur d’un paramètre, vous devez inclure la sectionparametersdans son nom.
Par exemple :${{ parameters.buildConfiguration }}
Appeler le modèle depuis le pipeline
Vous allez maintenant appeler le modèle que vous venez de créer depuis le pipeline.
Vous le ferez une fois pour la configuration Debug, puis vous répéterez le processus pour la configuration Release.
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'
- template: templates/build.yml
parameters:
buildConfiguration: 'Debug'
- template: templates/build.yml
parameters:
buildConfiguration: 'Release'
- task: PublishBuildArtifacts@1
displayName: 'Publish Artifact: drop'
condition: succeeded()Ce fichier ressemble à l’original, sauf qu’il remplace les tâches de compilation et de publication par des appels au modèle qui effectue les mêmes tâches.
Vous verrez que le modèle est appelé une fois pour chaque configuration.
Pour transmettre le nom de la configuration au modèle, chaque tâche du modèle utilise l’argument parameters.
Exécuter le pipeline
Vous allez maintenant pousser vos modifications sur GitHub et observer l’exécution du pipeline.
Depuis le terminal intégré, ajoutez les fichiers azure-pipelines.yml et templates/build.yml à l’index, validez les modifications (commit) et poussez-les sur GitHub.
git add azure-pipelines.yml templates/build.yml
git commit -m "Support build configurations"
git push origin build-pipelineDepuis Azure Pipelines, suivez l’exécution de la compilation étape par étape, comme vous l’avez fait précédemment.
Pendant l’exécution du pipeline, vous verrez que le processus déploie les tâches contenues dans le modèle.
Les tâches de compilation et de publication du projet sont exécutées deux fois : une fois pour chaque configuration de compilation (Debug et Release).
Une fois la compilation terminée, retournez à la page de résumé et sélectionnez l’artefact publié, comme vous l’avez fait précédemment.
Développez le dossier drop.
Vous verrez que le pipeline a produit un fichier .zip pour la configuration Debug et un autre pour la configuration Release.
Fusionner la branche dans main
À ce stade, vous avez un pipeline de compilation fonctionnel qui répond à tous les besoins actuels de Mara.
En pratique, vous soumettriez une pull request pour fusionner votre branche build-pipeline dans la branche main.
Nous allons passer cette étape pour le moment.
Dans le prochain module, vous apprendrez différentes façons de collaborer avec votre équipe sur GitHub, notamment comment soumettre, examiner et fusionner des pull requests.
