Qu'est-ce que l'affichage des flux ?
Azure DevOps Services | Azure DevOps Server 2022 - Azure DevOps Server 2019
Les vues de flux permettent aux développeurs de partager un sous-ensemble de versions de package avec leurs consommateurs. Une utilisation courante des vues de flux consiste à partager des versions de package qui ont été testées et validées, tout en retenant les packages toujours en cours de développement et/ou qui ne répondent pas à un certain niveau de qualité.
Affichage par défaut
Tous les flux d'artefacts sont accompagnés de trois vues : @local, @prerelease et @release. Les deux dernières sont des vues suggérées que vous pouvez renommer ou supprimer selon vos besoins. @local est la vue par défaut couramment utilisée dans les sources en amont. Vous pouvez changer la vue par défaut dans les paramètres de votre flux >Vues, mais cela n’active pas la publication directe sur cette vue. Les packages ne peuvent être publiés que dans le flux de base, où ils seront disponibles dans la vue @Local.
La vue @local contient tous les packages publiés directement dans le flux et tous les packages enregistrés à partir de sources en amont.
Les vues de flux sont en lecture seule, ce qui signifie que les utilisateurs connectés à une vue peuvent uniquement utiliser des packages publiés dans cette vue et/ou des packages précédemment enregistrés à partir de sources en amont. Consultez les diagrammes des paquets à pour savoir comment les paquets disponibles sont construits.
Remarque
Azure Artifacts prend uniquement en charge la publication et la restauration de packages depuis et vers la vue par défaut - @Local.
Vues de flux et sources en amont
Les vues de flux et les sources en amont sont conçues pour fonctionner ensemble pour fournir une solution au niveau de l’entreprise pour partager et consommer des packages. Pour que d'autres flux Azure Artifacts puissent utiliser votre flux comme source en amont, vous devez définir la visibilité de votre flux pour les membres de votre organisation, ou pour les membres de votre identifiant Microsoft Entra, selon votre situation. Si vous choisissez ce dernier, toutes les personnes de votre organisation pourront accéder à votre flux. En outre, tous les flux de votre organisation et d’autres organisations associés au même locataire Microsoft Entra pourront accéder en amont à votre flux.
Remarque
Toutes les vues de flux d’un projet public sont accessibles à tout le monde sur Internet.
Packages de déploiement avec vues de flux
Lors de la création de packages de mise en production, il est important de transmettre trois informations : la nature du changement, le risque du changement et la qualité du changement.
Nature et risque du changement
La nature et le risque du changement se rapportent tous deux au changement lui-même , c’est-à-dire ce que vous vous êtes fixé de faire, ils sont tous les deux connus dès le début du travail. Si vous introduisez de nouvelles fonctionnalités, apportez des mises à jour aux fonctionnalités existantes ou corrigez les bogues ; c’est la nature de votre changement. Si vous apportez toujours des modifications à la partie API de votre application ; il s’agit d’une facette du risque de votre changement. De nombreux utilisateurs de NuGet utilisent la notation Semantic Versioning (SemVer) pour transmettre ces deux informations. SemVer est une norme largement utilisée et fait un bon travail de communication de ce type d’information.
Qualité du changement
La qualité du changement n'est généralement pas connue tant que le processus de validation n'est pas terminé. Cette étape intervient après la construction et le package de votre changement. En raison de ce détail, il n’est pas possible de communiquer la qualité du changement dans le segment numérique du numéro de version (par exemple, 1.2.3). Il existe des solutions de contournement pour pré-valider (par exemple, consommer les DLL de la build directement avant qu’elles ne soient empaquetées et publier les packages dans un environnement « débogage » ou « CI », puis valider et republier ces packages dans un environnement « release ») mais aucune que nous n’avons vu ne peut vraiment garantir que le package généré répond à la norme de qualité correcte.
Vous pouvez utiliser la vue @Release comme moyen de transmettre la qualité de vos modifications. À l’aide de la vue @Release, vous pouvez partager des packages qui répondent à votre barre de qualité et permettre à vos consommateurs de voir uniquement le sous-ensemble des versions de package testées, validées et prêtes à être consommées.
