Qu’est-ce que les vues de flux ?

  • Article

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, mais qui sont conservées sur des packages toujours en cours de développement et/ou qui ne répondent pas à une certaine barre de qualité.

Vue par défaut

Tous les flux Artefacts sont fournis avec trois vues : @local, @prereleaseet @release. Les deux dernières sont des vues suggérées que vous pouvez renommer ou supprimer selon vos besoins. @localest la vue par défaut couramment utilisée dans les sources amont.

La @local vue contient tous les packages publiés directement dans le flux et tous les packages enregistrés à partir de sources 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 amont. Consultez les graphiques de package pour découvrir comment les packages 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 de amont

Les vues de flux et les sources 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 utilisent votre flux en tant que source amont, vous devez définir la visibilité de votre flux sur les membres de votre organisation ou les membres de votre ID Microsoft Entra, en fonction de votre scénario. 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 amont à votre flux.

Remarque

Toutes les vues de flux d’un projet public sont accessibles à tous sur Internet.

Packages de mise en production 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 de modification et la qualité du changement.

La répartition sémantique de la version : 1.2.3 représente la nature du changement et la version bêta2 représente la qualité de la modification.

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 avez défini à faire, ils sont tous les deux connus au 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 NuGet utilisent la notation SemVer (Semantic Versioning ) 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é de la modification n’est généralement pas connue tant que le processus de validation n’est pas terminé. Cela vient après la génération et l’empaquetage de votre modification. 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.

workflow des packages de publication

Vous pouvez utiliser la @Release vue comme moyen de transmettre la qualité de vos modifications. À l’aide de la @Release vue, 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.

version sémantique du déploiement