web-dev-qa-db-fra.com

Comment utiliser Nuget pour le développement d'entreprise interne?

Nous utilisons Nuget pour notre développement interne afin de nous permettre de partager le code entre les équipes. Nous rencontrons toutefois des problèmes lorsqu'une seule personne travaille sur du code qui sera déployé simultanément sur plusieurs paquets de nugets. Par exemple

A dépend de B qui dépend de C. 

Les artefacts de A, B et C sont transférés dans Nuget et c’est ainsi que nous gérons les dépendances entre A, B et C. Le problème que nous constatons est que si un développeur souhaite apporter des modifications à C et les voir rapidement, doivent passer par le processus suivant.

  1. Faire du changement en C.
  2. Pousser le changement jusqu'à git
  3. CI prend en charge les modifications apportées à C et crée et déploie un nouveau package de nuget.
  4. Allez dans B et mettez à jour la référence à C en utilisant une commande de package de mise à jour de nuget.
  5. Poussez la modification dans le fichier packages.config jusqu'à git
  6. CI prend en compte les modifications apportées à B, crée et déploie un nouveau paquet de nuget pour B
  7. Maintenant, ouvrez A et changez les références en paquet de mise à jour B et nuget
  8. Apportez des modifications dans A pour accompagner les modifications dans B (et transitoirement C)

Cela semble extrêmement pénible et amène certains de nos développeurs à s'interroger sur le choix de Nuget pour notre code développé en interne. Tout le monde aime encore le fait de consommer des paquets externes.

Existe-t-il un meilleur flux de travail pour utiliser Nuget en interne? 

nuget
59
Jonathan Beerhalter

Dans notre société, nous avons résolu le problème des mises à jour en cascade avec la configuration suivante. Nous avons d’abord la configuration suivante pour nos référentiels NuGet et notre serveur de construction.

  • Il existe un référentiel NuGet interne qui contient tous les packages publiés pour la société. Ce référentiel est juste un répertoire partagé sur l'un de nos serveurs.

  • Chaque développeur peut avoir (mais n’a pas besoin de) un ou plusieurs répertoires sur sa propre machine qui sert de référentiel de paquet NuGet local. En utilisant un NuGet configuration spécifique à l'utilisateur, le développeur peut contrôler l'ordre dans lequel NuGet cherche dans les référentiels de paquets pour trouver les paquets.

    <?xml version="1.0" encoding="utf-8"?>
<configuration>
  <packageRestore>
    <add key="enabled" value="True" />
  </packageRestore>
  <packageSources>
    <add key="Dev" value="D:\dev\testpackages" />
    <add key="Company" value="<UNC_ADDRESS_COMPANY_REPOSITORY>" />
    <add key="NuGet official package source" value="https://nuget.org/api/v2/" />
  </packageSources>
  <disabledPackageSources />
  <activePackageSource>
    <add key="All" value="(Aggregate source)" />
  </activePackageSource>
</configuration>

  • La restauration automatique des packages est activée sur toutes les solutions, ce qui évite de les appliquer à notre système de contrôle de version.

  • Les développeurs ne contrôlent que 3 des 4 numéros de version, par exemple. Si la version est <MAJOR>.<MINOR>.<BUILD>.<REVISION>, les développeurs ne peuvent modifier que les numéros majeur, mineur et de construction. Le numéro de révision est défini sur 0, sauf dans les versions effectuées par le serveur de génération où il correspond au numéro de version de la version. Ceci est important car cela signifie que pour une version donnée comprenant un numéro majeur, mineur et de build, le serveur de build produira toujours le numéro de version le plus élevé. Cela signifie encore une fois que NuGet préférera utiliser la version du paquet provenant du référentiel de paquets de la société (qui obtient uniquement les paquets via le serveur de construction).

Afin de modifier l'une des bibliothèques de base, deux processus sont utilisés. Le premier processus est:

  1. Apportez les modifications à la bibliothèque de base (A). Mettez à jour la version de (A) si nécessaire. 
  2. Exécutez le script MsBuild pour créer les fichiers binaires et créer les packages NuGet de (A)
  3. Copiez les nouveaux packages NuGet dans le référentiel de packages sur la machine locale.
  4. Dans le projet dépendant (B), effectuez une mise à niveau vers les nouveaux packages de (A) qui viennent d'être placés dans le référentiel de packages de l'ordinateur local (qui doit être d'une version supérieure à celle disponible dans le référentiel à l'échelle de la société ou sur NuGet.org).
  5. Apportez les modifications à (B).

Si des modifications supplémentaires sont nécessaires en (A), répétez les étapes 1, 2 et 3, puis supprimez le package de (A) du répertoire de travail de (B). La prochaine fois que la compilation sera exécutée, NuGet recherchera la version spécifique de (A), la trouvera dans le référentiel de la machine locale et la récupérera. Notez que le cache NuGet peut parfois entraver ce processus, bien que il semble que NuGet ne puisse pas mettre en cache les paquets provenant de la même machine (?). 

Une fois les modifications terminées, nous:

  1. Validez les modifications en (A). Le serveur de génération exécutera la construction d'intégration pour vérifier que tout fonctionne.
  2. Indiquez au serveur de génération d'exécuter la version finale, qui crée les fichiers binaires et transfère les packages NuGet vers le référentiel NuGet de l'entreprise.
  3. Dans (B), effectuez une mise à niveau vers la dernière version de (A) (qui devrait avoir un numéro de version supérieur à celui du package de test, car celui-ci devrait avoir la version abc0, tandis que la version nouvellement construite dans le référentiel à l'échelle de l'entreprise devrait être abc > 0
  4. Validez les modifications en (B). Attendez que le serveur de compilation termine les tests d'intégration
  5. Indiquez au serveur de compilation d'exécuter la version de compilation pour (B).

Une autre façon de faire le travail de développement est de prendre les mesures suivantes

  1. Apportez les modifications à la bibliothèque de base (A). Mettez à jour la version de (A) si nécessaire.
  2. Construire les binaires
  3. Copiez les fichiers binaires sur l'emplacement où NuGet décompresse le package de (A) pour le projet (B) (par exemple, c:\mysource\projectB\packages\ProjectA.1.2.3.4).
  4. Apportez les modifications requises au projet (B)

Le processus de validation reste le même, le projet (A) doit être préalablement engagé et dans le projet (B), la référence NuGet à (A) doit être mise à niveau. 

La première approche est légèrement plus judicieuse car ce processus avertit également s’il existe des erreurs dans le package NuGet de (A) (par exemple, il est oublié d’ajouter un nouvel assemblage), tandis que dans la seconde procédure, le développeur ne le saura qu'après le package (A ) a été publié.

39
Petrik

Vous avez deux choix ici:

  1. Exécutez une instance de NuGet Gallery au sein de votre organisation. C'est le code qui exécute nuget.org
  2. Obtenez une licence pour Artifactory Pro , qui prend en charge Nuget et joue le rôle de référentiel Nuget.

J’ai utilisé les deux, et le n ° 1 est un choix raisonnable au départ, mais NuGet Galley est optimisé et conçu pour nuget.org, et non pour une utilisation sur site ou en entreprise. ). 

Je dirais que vous devriez payer les frais de licence (bas) pour Artifactory Pro - c'est un excellent produit, et l'équipe JFrog est vraiment enthousiaste et branchée.

Vous ne devriez pas utiliser nuget.org pour les packages internes/d'entreprise; nuget.org est conçu pour les bibliothèques tierces/open source, pas pour les dépendances de construction internes.

EDIT: en termes de flux de travail, pourquoi mettez-vous le code shared dans plusieurs packages? Si le code doit être partagé, il doit figurer dans son propre package séparé.

EDIT 2: pour accélérer le flux de travail de modification du code pour le développeur, vous pouvez utiliser nuget.exe (le client en ligne de commande) et des versions accessibles en ligne de commande afin de cibler une exécution de "développeur". Ensuite, dans votre version "développeur" (par opposition à la version CI), spécifiez -Source en tant que chemin local (par exemple, nuget install B -Source C:\Code\B) lorsque vous souhaitez extraire la B nouvellement mise à jour comme dépendance et la construire en fonction de celle-ci; de même pour C ou d'autres packages locaux récemment mis à jour. Ensuite, lorsque A, B et C se génèrent correctement, vous pouvez git Push tous (dans l’ordre de dépendance inverse) et laisser CI faire son travail.

Cependant, vous devriez aussi vous demander si la séparation de vos paquets est vraiment appropriée si vous devez souvent construire cela «danser», car cela suggère que tout le code devrait être dans un seul paquet, ou éventuellement divisé en différentes lignes dans paquets séparés. Une caractéristique clé d'un paquet bien défini est qu'il devrait pas provoquer des effets d'entraînement sur les autres paquets, surtout si vous utilisez Version sémantique de manière efficace.

Edit 3 Certaines précisions demandées par marcelo-oliveira: "Les versions accessibles en ligne de commande" sont des versions qui peuvent être exécutées entièrement à partir de la ligne de commande, sans utiliser Visual Studio, généralement via des fichiers de traitement par lots. Une "version développeur" est une version qu'un développeur exécute à partir de son poste de travail, par opposition à la génération CI qui s'exécute sur le serveur CI (les deux versions doivent être essentiellement les mêmes).

7
Matthew Skelton

Si A, B et C font partie de la même solution, vous pouvez créer des packages NuGet pour eux dans une même construction.

Assurez-vous simplement que le paquet using a le nouveau numéro de version (en supposant que votre construction ne le change pas au hasard) du paquet dont il dépend.

Si A, B et C sont intentionnellement sous différentes solutions par ex. A est sous une solution d'infrastructure et B est sous une solution de produit, la seule suggestion que je puisse vous faire est de définir vos générations de CI exécutées à l'enregistrement et non périodiquement.


Modifier:

Une autre option consiste à créer un package Push pre-release (par exemple, version 1.0.0-alpha) sur votre serveur NuGet lors de la génération locale, afin que les développeurs puissent expérimenter le package avant de créer une version.

2
Danny Varod

Nuget a été conçu pour partager des bibliothèques tierces. Nous prévoyons d'utiliser Nuget en interne pour tout code commun pouvant être partagé entre des projets. Des éléments tels qu'une couche de données commune, une chaîne et d'autres fonctions d'expressions régulières, des composants de messagerie et d'autres artefacts similaires. 

La seule façon dont je vois l'aide de Nuget est lorsque les composants, le code ou les artefacts que vous partagez entre les équipes/projets sont stables et que leur propre cycle de publication diffère de celui de votre projet. Pour vos besoins, Nuget est une overkill. Vous pourriez avoir une meilleure productivité reliant tous ces projets au sein de la même solution. Votre structure de solution doit inclure les trois projets A, B et C en tant que projets dépendants référencés en interne si nécessaire.

0
user20358