Récemment, j’ai fait un tutoriel sur la façon d’utiliser Travis CI comme outil pour tester automatiquement votre code que vous venez de pousser ou que vous essayez de pousser vers la branche master . Le faire être compilé et testé et enfin vous signaler l’état de ce changement.

Mais nous pouvons continuer à l’améliorer **, par exemple, la bibliothèque principale qui a été créée dans ce dernier tutoriel, je souhaite la rendre publique en utilisant le flux NuGet, afin que tout le monde puisse utiliser facilement ses bibliothèques !

Mais comment ? Comment allons-nous compiler, tester puis publier ce package dans le flux pour que chacun puisse le télécharger dans ses projets ?

Eh bien, c’est ce tutoriel pour 😁 !

Quoi de neuf ?

Il n’y a presque aucun changement concernant le code, les choses que nous devons changer sont l’emballage, la publication et ensuite la façon dont nous pouvons l’automatiser.

CLI .NET Core

Nous allons utiliser la .NET Core CLI, nous l’avons utilisée dans le tutoriel précédent avec des commandes comme dotnet restore, dotnet build et dotnet test.

Nous allons maintenant utiliser un nouvel ensemble de commandes !

dotnet nuget

Vous pouvez consulter la documentation de cet ensemble d’outils directement ici, mais une brève explication :

dotnet nuget est un ensemble d’outils essentiels qui incluent l’installation, la restauration, la suppression et la publication de packages.

Flux NuGet

NuGet est le gestionnaire de packages pour .NET. Les outils clients NuGet offrent la possibilité de produire et de consommer des packages. La galerie NuGet est le référentiel central de packages utilisé par tous les auteurs et consommateurs de packages.

NuGet est gratuit, vous pouvez donc vous inscrire, récupérer votre clé API et commencer à télécharger des packages. Ils seront téléchargés, vérifiés puis répertoriés pour tout le monde.

Récupérer la clé API

Afin de télécharger votre package, vous devrez obtenir votre clé API après l’inscription, alors rendez-vous sur la page Clés API et créez-en une nouvelle.

Gardez à l’esprit que la clé API a une expiration de 365 jours.

Copiez ensuite votre clé et stockez-la quelque part, comme indiqué sur la page, vous ne pourrez plus la revoir, et si vous ne l’avez pas sauvegardée vous devrez la régénérer.

Générer le package NuGet

Maintenant que nous avons la clé API, notre prochaine étape consiste à générer ce package NuGet à partir de la solution, alors allez-y et ouvrez la solution dans laquelle vous avez votre bibliothèque de classes.

J’utiliserai la solution de mon dernier tutoriel, qui possède une classe de bibliothèque .NET Core appelée CalculatorCLI.Core.

Allez maintenant dans les propriétés du projet, puis dans Package, vous verrez de nombreuses informations concernant le package comme la version du package, les auteurs, les descriptions et plus encore.

Ensuite, il faut remplir ceci, vous n’êtes pas vraiment obligé de tout remplir, mais les plus importants et obligatoires sont Package id, Package version, Authors et Description. De plus, si vous essayez de télécharger le fichier par vous-même, il vous sera demandé License, nous devrons également l’ajouter.

Ensuite, vous pouvez enregistrer, faire un clic droit dans le projet et sélectionner Pack.

1>------ Build started: Project: CalculatorCLI.Core, Configuration: Debug Any CPU ------
1>CalculatorCLI.Core -> D:\Development\Personal\CalculatorCLI-demo\CalculatorCLI\CalculatorCLI.Core\bin\Debug\netstandard2.1\CalculatorCLI.Core.dll
1>Successfully created package 'D:\Development\Personal\CalculatorCLI-demo\CalculatorCLI\CalculatorCLI.Core\bin\Debug\CalculatorCLI.Core.1.0.0.1.nupkg'.
========== Build: 1 succeeded, 0 failed, 0 up-to-date, 0 skipped ==========

La sortie montrera que si tout va bien, elle imprimera Successfully created package.

Utilisation de dotnet

Comme dans le tutoriel précédent, nous avons utilisé différentes commandes afin de construire et tester la solution. Maintenant, nous allons ajouter plus de commandes pour compresser et publier les packages.

Ces commandes sont :

1. dotnet pack -c <configuration>
2. dotnet nuget push <package> <k <apikey> -s <source>

Scripts de déploiement

Comme nous allons changer la façon dont la construction va être, je pense qu’avoir des fichiers différents, chacun contenant une définition de construction en fonction de l’environnement, serait la meilleure idée.

Créons donc un dossier appelé scripts avec trois scripts bash à la racine du référentiel.

scripts\compile.sh

#!/bin/sh

echo "Restoring..."
dotnet restore ".\CalculatorCLI\CalculatorCLI.sln"   

echo "Building..."
dotnet build ".\CalculatorCLI\CalculatorCLI.sln" -c Release

scripts\test.sh

#!/bin/sh

echo "Testing..."
dotnet test ".\CalculatorCLI\CalculatorCLI.sln" -c Release -v n

scripts\push.sh

#!/bin/sh

echo "Packing..."
dotnet pack ./CalculatorCLI/CalculatorCLI.Core/CalculatorCLI.Core.csproj -c Release

echo "Pushing..."
dotnet nuget push ./CalculatorCLI/CalculatorCLI.Core/bin/Release/*.nupkg -s "https://nuget.org" -k $NUGET_API_KEY

Amélioration du fichier .travis.yml

Maintenant que nous avons le code source mis à jour, que nous connaissons les commandes que nous devons utiliser, nous devons intégrer notre livraison continue à l’intégration continue. Avec cela, nous n’avons pas vraiment besoin de faire autre chose que coder, tester, réviser et pousser.

Ce que nous allons faire maintenant, avec le fichier .travis.yml, est le suivant :

1. Ajoutez différents stages
2. Chaque stage dépend de la branche
3. Si votre build est sur master, cela signifie que le package doit être mis à jour, nous allons donc pousser notre package vers les flux NuGet
4. Si votre build est une pull request, nous allons quand même vérifier si la build est compilée et testée, mais nous n’allons pas la publier.

Étapes

D’après leur documentation :

Vous pouvez filtrer et rejeter les builds, les étapes et les tâches en spécifiant les conditions dans votre configuration de build (votre fichier .travis.yml).

Vous pouvez trouver plus d’informations sur TravisCI stages dans leur page de documentation.

Nous allons donc changer le fichier et ajouter les étapes, ce qui se termine ainsi :

language:
    csharp
sudo: required
mono: none 
dotnet: 3.0

os:
  - linux
    
jobs:
  include:
    - stage: compile
      script: bash scripts/compile.sh

    - stage: test
      script: bash scripts/test.sh

    - stage: deploy-prod
      if: branch = master AND type = push
      name: "Deploy to NuGet"
      script: bash scripts/push.sh

Comme vous pouvez le voir, nous avons trois étapes différentes compile, test et push, dont la dernière ne sera exécutée que lorsque le branch est master et qu’il ne s’agit pas d’un pull request, seulement d’un push.

Si vous ne comprenez pas cela, allez simplement dans la documentation et c’est expliqué assez simplement.

Dans cet esprit, tous les pull request ne transmettront rien au flux NuGet.

Définition de la clé API comme variable d’environnement

Accédez aux paramètres de construction de votre référentiel et ajoutez une nouvelle variable d’environnement, appelée NUGET_API_KEY, la valeur étant la clé API copiée à partir de la page NuGet.

Créer un pull request

Maintenant que tout est configuré, il est temps de créer un pull request et de vérifier si la compilation pour cette pull request ignore le dernier stage.

Vérifiez les builds

Dès que vous effectuez la pull request, une build sera mise en file d’attente dans le tableau de bord TravisCI, et comme vous pouvez le voir, nous y avons 2 builds différentes et non trois.

Acceptons maintenant le pull request et vérifions à nouveau la construction pour voir que nous avons maintenant trois tâches au lieu de deux.

Et dès que vous voyez la construction mise en file d’attente, vous pouvez voir les trois tâches, y compris le Deploy-prod à la fin.

Dès que cette version est entièrement terminée, vous pouvez voir dans les journaux que le package a été poussé vers les sources.

Et évidemment, vous pouvez le voir sur la page NuGet

C’est ça

Dans ce didacticiel, nous avons découvert comment automatiser la livraison de nos packages NuGet. Nous avons utilisé certains outils comme TravisCI, stages et dotnet nuget.

À mon avis, même si c’est quelque chose qui prendrait du temps à mettre en place correctement et qui pourrait s’avérer bien trop complexe dans certains cas. Investir du temps dans ce genre de techniques afin que tout soit parfait et automatisé en vaut la peine.

Vous pouvez trouver le code source, avec le fichier .travis.yml juste ici, si vous avez des questions, n’hésitez pas à me contacter sur mon twitter !