Remarque
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de vous connecter ou de modifier des répertoires.
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de modifier des répertoires.
Azure DevOps Services | Azure DevOps Server | Azure DevOps Server 2022
Les sources en amont d’Azure Artifacts permettent aux développeurs de stocker des packages provenant de différentes origines dans un flux unique, y compris les packages publiés dans le flux et ceux installés à partir de registres publics tels que NuGet.org ou npmjs.com. Une fois les sources en amont activées, tout package installé à partir d’une source en amont est automatiquement enregistré dans votre flux.
Remarque
Pour enregistrer des packages à partir des flux en amont, vous devez disposer du rôle de Lecteur de flux en amont (Collaborateur) ou d'un rôle supérieur. Pour plus d’informations, consultez rôles de flux et autorisations .
Pourquoi utiliser des sources en amont ?
L’activation de sources en amont offre plusieurs avantages pour gérer les dépendances de votre produit au sein d’un seul flux :
Simplicité : le stockage de tous vos packages dans un seul flux simplifie vos fichiers de configuration tels queNuGet.config, npmrc ou settings.xml. Avec un seul flux dans votre fichier de configuration, vous réduisez la complexité de la configuration et réduisez les erreurs.
Builds cohérentes : votre flux résout les demandes de package dans un ordre défini, ce qui permet de garantir des builds prévisibles et fiables dans les environnements.
intégrité du package: votre flux conserve les métadonnées relatives aux packages enregistrés à partir de sources en amont, ce qui vous permet de vérifier leur authenticité et de vous assurer que vous utilisez les versions d’origine, et non les copies ou les versions potentiellement malveillantes.
Fiabilité: Les paquets installés à partir de sources en amont sont automatiquement enregistrés dans votre flux. Cela garantit l’accès continu même si la source en amont devient temporairement indisponible en raison d’une maintenance ou d’autres problèmes afin de continuer à développer et à créer en toute confiance.
Meilleures pratiques pour les consommateurs de packages
Pour tirer pleinement parti des avantages des sources en amont en tant que consommateur de packages, suivez les meilleures pratiques suivantes :
Utiliser un seul flux dans votre fichier de configuration
Pour que votre flux fournisse une restauration déterministe, assurez-vous que votre fichier de configuration (par exemple ,nuget.config ou npmrc) référence un seul flux avec des sources en amont activées.
Exemples :
registry=https://pkgs.dev.azure.com/fabrikam/_packaging/FabrikamFiber/npm/registry/ always-auth=true<packageSources> <clear /> <add key="FabrikamFiber" value="https://pkgs.dev.azure.com/fabrikam/_packaging/FabrikamFiber/nuget/v3/index.json" /> </packageSources>Remarque
NuGet compile plusieurs fichiers de configuration pour déterminer l’ensemble complet d’options à appliquer. L’utilisation de
<clear />garantit que toutes les autres sources de package spécifiées dans les fichiers de configuration de niveau supérieur sont ignorées.
Organiser de manière intentionnelle vos sources en amont
Si vous utilisez uniquement des registres publics comme NuGet.org ou npmjs.com, l’ordre des sources en amont n’affecte pas le comportement. Les demandes adressées au flux suivent la séquence décrite dans l’ordre de recherche section.
Toutefois, lors de la gestion de plusieurs sources, telles qu’une combinaison de flux et de registres publics, chaque source en amont est recherchée dans l’ordre défini dans les paramètres de configuration du flux. Dans ces cas, nous vous recommandons de placer d’abord les registres publics dans la liste des sources en amont.
Dans certains scénarios uniques, certaines organisations modifient des packages de logiciels open source (OSS) pour résoudre les problèmes de sécurité, améliorer les fonctionnalités ou répondre à des exigences internes spécifiques qui nécessitent la reconstruction interne du package plutôt que de l’obtenir directement à partir d’un référentiel public. Si votre organisation suit cette pratique, placez la source en amont contenant ces packages OSS personnalisés avant d’autres registres publics. Cela garantit que vos versions personnalisées sont utilisées au lieu des versions publiques.
Meilleures pratiques pour les propriétaires de flux et les éditeurs de package
Pour vous assurer que votre flux peut être facilement configuré en tant que source en amont, suivez les bonnes pratiques suivantes :
Utiliser la vue par défaut
Tous les flux nouvellement créés utilisent la @Local vue par défaut. Cette vue inclut les éléments suivants :
- Les packages sont publiés directement dans le flux.
- Packages enregistrés à partir de sources en amont.
Si vous souhaitez utiliser d’autres vues telles qu’une vue pour les versions de packages nouvellement publiées, vous pouvez promouvoir vos packages en vue @Release, puis rendre cette vue disponible pour vos consommateurs cibles. Pour plus d'informations, consultez la rubrique Vues des flux.
Construire un graphe de package
Pour construire un graphique de package, connectez-vous simplement à la vue par défaut du flux et installez le package que vous souhaitez partager. Une fois qu’un package est enregistré dans la vue par défaut, les utilisateurs qui souhaitent l’utiliser pourront résoudre le graphique du package et installer la version souhaitée. Les packages provenant de sources en amont sont affichés en fonction de la vue configurée pour la source en amont correspondante. Pour plus d’informations, consultez comment les sources amont construisent l’ensemble des packages disponibles.
Ordre de recherche
Pour les gestionnaires de packages publics qui prennent en charge plusieurs flux, tels que NuGet et Maven, l’ordre dans lequel les flux sont interrogés peut parfois être peu clair ou non déterministe. Par exemple, NuGet envoie des requêtes parallèles à tous les flux du fichier de configuration et traite les réponses selon un principe de premier entré, premier sorti (FIFO), ce qui peut entraîner des résultats inconsistants.
Les sources en amont d’Azure Artifacts éliminent cette incertitude en appliquant un ordre de recherche structuré, en recherchant le flux et ses sources en amont dans l’ordre suivant :
Les packages qui ont été publiés directement dans le flux.
Paquets sauvés à partir d’une source en amont.
Packages disponibles à partir de sources en amont. Chaque source en amont est recherchée dans l’ordre dans lequel elle est répertoriée dans la configuration du flux.
Remarque
Azure Artifacts ne prend pas en charge la recherche de packages dans des sources en amont à l’aide de l’Explorateur de packages NuGet dans Visual Studio.
Enregistrer des packages à partir de sources en amont
Lorsqu’une source en amont est activée sur votre flux, Azure Artifacts enregistre automatiquement une copie de tout package installé par un collaborateur ou une version ultérieure à partir de cette source en amont.
Par exemple, vous pouvez installer des packages directement à partir de la source en amont à l’aide d’une commande telle que npm install express. Vous pouvez également installer des packages dans le cadre de la résolution des dépendances. Par conséquent, l’installation d’express enregistrerait également ses dépendances, telles que les acceptations.
Les sources en amont offrent une protection critique pour vos consommateurs et votre infrastructure. Si le registre public subit un temps d’arrêt, une maintenance ou devient temporairement indisponible, vous pouvez toujours récupérer les packages nécessaires à partir de votre flux et poursuivre votre développement.
Remarque
Les sources en amont personnalisées sont uniquement prises en charge pour les packages npm.
Remplacer les packages provenant de sources en amont
Lorsque les sources en amont sont activées dans votre flux, vous ne pouvez pas publier une version de package qui existe déjà dans l’une de ces sources en amont. Par exemple, si le NuGet.org en amont est activé, vous ne pourrez pas publier Newtonsoft.Json 10.0.3 sur votre flux, car cette version est déjà disponible sur NuGet.org.
Pour remplacer une version de package à partir d’une source en amont :
Désactivez la source en amont appropriée.
Publiez la version de votre package souhaitée dans le flux.
Réactivez la source en amont.
Ce flux de travail vous permet de publier la version souhaitée tout en conservant l’intégrité de vos sources en amont.
Remarque
Les versions de package sont immuables. Les packages enregistrés restent dans le flux même si la source en amont est désactivée ou supprimée.
État d’intégrité des sources en amont
Si un flux a une source en amont défaillante, les métadonnées des packages utilisant le même protocole ne peuvent plus être actualisées. Pour vérifier l’état d’intégrité de vos sources en amont, procédez comme suit :
Connectez-vous à votre organisation Azure DevOps et accédez à votre projet.
Sélectionnez Artefacts, puis sélectionnez votre flux dans le menu déroulant.
Sélectionnez
pour ouvrir les paramètres de flux, puis sélectionnez Sources en amont.
Si des échecs se produisent, un message d’avertissement s’affiche. Sélectionnez l’état Échec pour afficher des informations détaillées, notamment la cause de l’échec et les étapes à résoudre.
Remarque
Pour les registres publics comme NuGet.org, il existe généralement un délai de 3 à 6 heures entre le moment où un package est envoyé au registre public et lorsqu’il devient disponible en téléchargement. Ce délai dépend du minutage du travail et de la propagation des données. Toutefois, lorsque la source en amont est un flux Azure Artifacts, la latence n’est généralement pas supérieure à quelques minutes.