Mara a maintenant une copie du code du jeu spatial. Elle va le compiler en utilisant Microsoft Azure Pipelines au lieu du serveur de build Ubuntu 22.04 existant. Avant de pouvoir faire cela, elle doit réfléchir aux scripts de build existants. Suivez-la pendant qu’elle associe les scripts existants aux tâches d’Azure Pipelines. Réfléchissez à la manière dont vous pouvez faire la même chose avec votre propre processus de build.

Voici quelques notes que Mara a recueillies lors de sa discussion avec Andy, le responsable du développement :

• La machine de build fonctionne sous Ubuntu 22.04.
• Elle contient des outils de build comme :
  • npm, le gestionnaire de paquets pour Node.js
  • NuGet, le gestionnaire de paquets pour .NET
  • .NET SDK
• Le projet utilise Sass (Syntactically Awesome Style Sheets) pour faciliter la création de fichiers CSS.
• Le projet utilise l’outil gulp pour minifier les fichiers JavaScript et CSS.
• Un fichier minifié exclut les données inutiles (comme les espaces blancs) et raccourcit les noms de variables pour accélérer le téléchargement.

Voici les étapes du processus de build :

1. Pour installer les paquets Node.js définis dans package.json, exécuter npm install.
2. Pour convertir les fichiers Sass (.scss) en fichiers CSS (.css), exécuter node-sass.
3. Pour minifier les fichiers JavaScript et CSS, exécuter gulp.
4. Pour aider l’équipe QA à identifier le numéro et la date du build, imprimer les informations de build dans le répertoire wwwroot.
5. Pour installer les dépendances du projet, exécuter dotnet restore.
6. Pour compiler l’application en configurations Debug et Release, exécuter dotnet build.
7. Pour empaqueter l’application dans un fichier .zip et copier les résultats sur un partage réseau pour que l’équipe QA puisse les récupérer, exécuter dotnet publish.

Mara crée un script shell qui exécute les tâches qu’elle a identifiées. Elle le lance sur son ordinateur portable.

#!/bin/bash

# Install Node.js modules as defined in package.json.
npm install --quiet

# Compile Sass (.scss) files to standard CSS (.css).
node-sass Tailspin.SpaceGame.Web/wwwroot

# Minify JavaScript and CSS files.
gulp

# Print the date to wwwroot/buildinfo.txt.
echo `date` > Tailspin.SpaceGame.Web/wwwroot/buildinfo.txt

# Install the latest .NET packages the app depends on.
dotnet restore

# Build the app under the Debug configuration.
dotnet build --configuration Debug

# Publish the build to the /tmp directory.
dotnet publish --no-build --configuration Debug --output /tmp/Debug

# Build the app under the Release configuration.
dotnet build --configuration Release

# Publish the build to the /tmp directory.
dotnet publish --no-build --configuration Release --output /tmp/Release

#!/bin/bash

# Install Node.js modules as defined in package.json.
npm install --quiet

# Compile Sass (.scss) files to standard CSS (.css).
node-sass Tailspin.SpaceGame.Web/wwwroot

# Minify JavaScript and CSS files.
gulp

# Print the date to wwwroot/buildinfo.txt.
echo `date` > Tailspin.SpaceGame.Web/wwwroot/buildinfo.txt

# Install the latest .NET packages the app depends on.
dotnet restore

# Build the app under the Debug configuration.
dotnet build --configuration Debug

# Publish the build to the /tmp directory.
dotnet publish --no-build --configuration Debug --output /tmp/Debug

# Build the app under the Release configuration.
dotnet build --configuration Release

# Publish the build to the /tmp directory.
dotnet publish --no-build --configuration Release --output /tmp/Release

Le répertoire /tmp imite le partage réseau de l’équipe.

Après avoir exécuté le script, Mara se rend compte qu’il est incomplet. Par exemple, il ne gère pas les erreurs. Il ne prévient personne en cas d’erreurs de build. Même lorsqu’il y a des erreurs, il continue à s’exécuter. Il n’installe pas non plus les outils nécessaires à chaque étape.

Qu’est-ce qu’une tâche Azure Pipelines ?

Dans Azure Pipelines, une tâche est un script ou une procédure empaquetée, abstraite avec un ensemble d’entrées.

Une tâche Azure Pipelines masque les détails sous-jacents. Cette abstraction facilite l’exécution de fonctions de build courantes, comme le téléchargement des outils de build ou des paquets dont votre application dépend, ou encore la compilation de votre projet avec Visual Studio ou Xcode.

Pour compiler un projet C# ciblant .NET, voici un exemple utilisant la tâche DotNetCoreCLI@2 :

task: DotNetCoreCLI@2
  displayName: 'Build the project'
  inputs:
    command: 'build'
    arguments: '--no-restore --configuration Release'
    projects: '**/*.csproj'

task: DotNetCoreCLI@2
  displayName: 'Build the project'
  inputs:
    command: 'build'
    arguments: '--no-restore --configuration Release'
    projects: '**/*.csproj'

Le pipeline pourrait traduire cette tâche en cette commande :

.NET CLI

dotnet build MyProject.csproj --no-restore --configuration Release

Décomposons un peu plus cette tâche :

• La tâche DotNetCoreCLI@2 correspond à la commande dotnet.
• displayName définit le nom de la tâche affiché dans l’interface utilisateur. Vous verrez cela en action bientôt.
• inputs définit les arguments transmis à la commande.
• command spécifie qu’il faut exécuter la sous-commande dotnet build.
• arguments spécifie les arguments supplémentaires à transmettre à la commande.
• projects indique quels projets compiler. Cet exemple utilise le motif générique **/*.csproj. Les éléments ** et *.csproj sont des exemples de ce qu’on appelle des motifs glob :
  • ** indique qu’il faut rechercher dans le répertoire courant et tous ses sous-répertoires.
  • *.csproj indique tous les fichiers avec l’extension .csproj.
  • Les caractères génériques permettent d’agir sur plusieurs fichiers sans les spécifier un par un. Si vous devez agir sur un fichier spécifique, vous pouvez le nommer directement au lieu d’utiliser des jokers.
• Le symbole @ dans le nom de la tâche — par exemple DotNetCoreCLI@2 — fait référence à la version de la tâche. Lorsque de nouvelles versions sont disponibles, vous pouvez migrer progressivement vers la dernière pour bénéficier des nouvelles fonctionnalités.

Comment les tâches sont-elles utilisées dans un pipeline ?

Ensuite, Mara va associer les commandes de son script aux tâches Azure Pipelines. Un pipeline est créé à l’aide d’un fichier YAML, un format compact qui facilite la structuration des données typiques des fichiers de configuration. Les fichiers YAML de pipeline sont généralement maintenus directement avec le code source de l’application.

Mara a déjà utilisé YAML pour définir des tâches de build et des configurations similaires. Elle apprécie aussi l’idée de maintenir la définition du build comme du code, tout comme elle le ferait pour n’importe quelle autre partie de son projet.

Pour définir son build, Mara choisit d’utiliser Visual Studio Code pour créer un fichier YAML. Elle y saisit toutes les tâches Azure Pipelines qu’elle utilisera pour remplacer les commandes de script existantes.

Associer les commandes du script aux tâches Azure Pipelines

Vous allez maintenant suivre Mara pendant qu’elle associe les commandes de son script aux tâches Azure Pipelines.

Pour chaque commande, Mara consulte la documentation de référence. Celle-ci classe les tâches par fonction, comme build ou déploiement.

Par exemple, la tâche CLI .NET Core DotNetCoreCLI@2 permet d’exécuter des commandes dotnet.

Ce tableau associe les commandes du script aux nouvelles tâches Azure Pipelines :

Il n’existe pas de type de tâche intégré pour exécuter node-sass ou pour imprimer la date dans un fichier. Pour ces cas, Mara utilise la tâche CmdLine@2, qui lui permet d’exécuter n’importe quelle commande. Plus couramment, on utilise la tâche script, qui est un raccourci pour CmdLine@2.

Pour en savoir plus sur les autres raccourcis de tâches courants, consultez la documentation de référence sur le schéma YAML pour Azure Pipelines – section steps.