Planifier vos tâches de génération

  • 7 minutes

Mara a maintenant une copie du code de Space Game. Elle va le générer en utilisant Microsoft Azure Pipelines au lieu du serveur de build Ubuntu 22.04 existant. Avant cela, elle doit réfléchir aux scripts de build existants. Observez-la mapper les scripts existants à des tâches Azure Pipelines. Pensez à la façon dont vous pouvez en faire de même avec votre propre processus de génération.

Voici quelques notes que Mara a prises pendant sa conversation avec Andy, responsable du développement :

  • La machine de build exécute Ubuntu 22.04.
  • L’ordinateur de build inclut des outils de génération comme :
    • npm, le gestionnaire de package pour Node.js
    • NuGet, le gestionnaire de package pour .NET
    • Kit de développement logiciel (SDK) .NET
  • Le projet utilise Sass (Syntactically Awesome Style Sheets) pour faciliter la création de fichiers de feuilles de style en cascade (CSS).
  • Le projet utilise le kit de ressources gulp pour minifier les fichiers JavaScript et CSS.

Une ressource réduite 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 qui se produisent durant le processus de build :

  1. Pour installer les packages Node.js définis dans package.json, exécutez npm install.
  2. Pour convertir les fichiers Sass (.scss) en fichiers CSS (.css), exécutez node-sass.
  3. Pour réduire les fichiers JavaScript et CSS, exécutez gulp.
  4. Pour permettre à l’équipe de l’assurance qualité d’identifier le numéro et la date de la build, copiez les informations de la build dans le répertoire wwwroot.
  5. Pour installer les dépendances du projet, exécutez dotnet restore.
  6. Exécutez dotnet build pour générer l’application à la fois sous les configurations Debug et Release.
  7. Pour empaqueter l’application dans un fichier .zip et copier les résultats sur un partage réseau accessible à l’équipe de l’assurance qualité, exécutez dotnet publish.

Mara génère un script d’interpréteur de commandes qui effectue les tâches qu’elle a identifiées. Elle l’exécute sur son ordinateur portable.

Notes

Vous n’avez pas besoin d’exécuter ce script ni de comprendre complètement son rôle. Il ne sert ici qu’à illustrer ce que peut éventuellement faire un script de génération.

#!/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.

Une fois qu’elle a exécuté le script, Mara se rend compte qu’il est incomplet. Il ne traite, par exemple, pas les erreurs. Il n’informe personne en cas d’erreur de build. Même s’il y a des erreurs, il continue à s’exécuter. Il n’installe pas non plus les outils nécessaires à chaque étape.

Que sont les tâches Azure Pipelines ?

Dans Azure Pipelines, une tâche est une procédure ou un script packagé qui fait abstraction d’un ensemble d’entrées.

Une tâche Azure Pipelines fait abstraction des détails sous-jacents. Cette abstraction facilite l’exécution des fonctions de build courantes, telles que le téléchargement des outils de build ou des packages dont votre application dépend. Elle vous permet aussi de générer votre projet plus facilement, en exécutant Visual Studio ou Xcode.

Voici un exemple qui utilise la tâche DotNetCoreCLI@2 pour générer un projet C# ciblant .NET :

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

Le pipeline peut traduire cette tâche par cette commande :

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

Décomposons cette tâche un peu plus :

  • La tâche DotNetCoreCLI@2 est mappée à la commande dotnet.
  • displayName définit le nom de la tâche qui apparaît dans l’interface utilisateur. Vous verrez cela en action sous peu.
  • inputs définit les arguments passés à la commande.
    • command spécifie d’exécuter la sous-commande dotnet build.
    • arguments spécifie les arguments supplémentaires à passer à la commande.
    • projects spécifie les projets à générer. Cet exemple utilise le modèle générique **/*.csproj. ** et *.csproj sont tous les deux des exemples de modèles Glob. La partie ** indique de rechercher dans le répertoire actuel et tous les répertoires enfants. La partie *.csproj spécifie n’importe quel fichier .csproj. En utilisant des caractères génériques, vous pouvez agir sur plusieurs fichiers sans spécifier chacun d’eux. Si vous avez besoin d’agir sur un fichier spécifique uniquement, vous pouvez spécifier ce fichier au lieu d’utiliser des caractères génériques.

Le « @ » dans le nom de la tâche (par exemple, DotNetCoreCLI@2) fait référence à la version de la tâche. Au fur et à mesure que de nouvelles versions de la tâche sont disponibles, vous pouvez migrer progressivement vers la dernière version pour exploiter de nouvelles fonctionnalités.

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

Mara va maintenant mapper les commandes de script existantes à des tâches Azure Pipelines. Un pipeline est créé à l’aide d’un fichier YAML, qui est un format compact facilitant la structuration du type des données contenues dans les fichiers de configuration. Les fichiers YAML de pipeline sont généralement tenus à jour directement avec le code source de votre application.

Mara a déjà utilisé YAML pour définir des tâches et des configurations de génération similaires. Elle aime aussi l’idée de gérer la définition de build sous forme de code, tout comme elle le ferait pour toute autre partie de son projet.

Pour définir sa build, Mara choisit d’utiliser Visual Studio Code pour créer un fichier YAML. Dans ce fichier, elle entre toutes les tâches Azure Pipelines qu’elle va utiliser pour remplacer les commandes de script existantes.

Mapper des commandes de script à des tâches Azure Pipelines

Vous allez maintenant observer Mara mapper les commandes de son script à des tâches Azure Pipelines.

Pour mapper chaque commande, Mara se reporte à la documentation de référence. Cette documentation classifie les tâches par fonction : génération, déploiement, etc.

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

Le tableau ci-dessous associe les commandes de script aux nouvelles tâches Azure Pipelines :

Commande de script Tâche Azure Pipelines
npm install Npm@1
node-sass CmdLine@2 (ou script)
gulp gulp@1
echo `date` CmdLine@2 (ou script)
dotnet restore DotNetCoreCLI@2
dotnet build DotNetCoreCLI@2
dotnet publish DotNetCoreCLI@2

Il n’existe aucun type de tâche intégrée qui exécute node-sass ou imprime la date dans un fichier. Pour cela, Mara utilise la tâche CmdLine@2, qui lui permet d’exécuter n’importe quelle commande dont elle a besoin. En général, vous verrez la tâche script, qui est un raccourci de CmdLine@2. Pour plus d’informations sur les autres raccourcis de tâche courants, consultez Informations de référence sur le schéma YAML pour Azure Pipelines - Étapes.

Vous allez bientôt créer votre propre fichier YAML qui utilisera ces tâches.

Vérifiez vos connaissances

1.

Une tâche de génération :