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 vues de flux permettent aux développeurs de partager un sous-ensemble spécifique de versions de package avec les consommateurs. Cela est utile lorsque vous souhaitez fournir l’accès aux packages qui ont été testés et validés, tout en retenant ceux qui sont toujours en cours de développement ou qui ne répondent pas à vos normes de qualité.
Affichage par défaut
Chaque flux Artifacts comprend trois vues par défaut : @local, @prereleaseet @release. Les deux dernières sont des vues suggérées que vous pouvez renommer ou supprimer si nécessaire.
@local est la vue par défaut et est couramment utilisée dans les sources en amont. Vous pouvez modifier l’affichage par défaut dansles vues> du flux, mais notez que cela n’active pas la publication directe dans cette vue. Les packages ne peuvent être publiés que dans le flux de base, où ils seront disponibles dans la vue @Local.
La @local vue contient :
- Tous les packages publiés directement dans le flux.
- 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 graphiques de package pour découvrir comment les graphiques de package 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 afin de fournir une solution au niveau de l’entreprise pour le partage et la consommation de packages. Pour autoriser d’autres flux Azure Artifacts à utiliser votre flux en tant que source en 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 l’ID Microsoft Entra, toutes les personnes de votre organisation pourront accéder à votre flux, ainsi que tous les flux de votre organisation et d’autres organisations associées au même locataire Microsoft Entra pourront accéder en amont à votre flux.
Remarque
Toutes les vues de flux dans un flux public sont accessibles à tout le monde sur Internet.
Packages de déploiement avec vues de flux
Lors de la publication de packages, il est important de communiquer trois aspects clés :
Lors de la création de packages de mise en production, il est important de transmettre trois informations :
Nature du changement : quel type de changement est introduit.
Risque de changement : à quel point le changement pourrait être perturbateur ou nuisible.
Qualité de la modification : indique si le package répond à vos normes de validation.
Nature et risque du changement
La nature et le risque sont liés à l’intention du changement, connu au début du développement :
Nature : Ajoutez-vous de nouvelles fonctionnalités, mettez-vous à jour des fonctionnalités existantes ou corrigez-vous des bogues ?
Risque : La modification affecte-t-elle les composants critiques tels que les API ou introduit-elle des modifications disruptives ?
La plupart des équipes utilisent le contrôle de version sémantique (SemVer) pour transmettre ces informations. SemVer est largement adopté et efficace pour signaler la nature et le risque.
1.2.3
│ │ └─ Patch (bug fixes)
│ └── Minor (new features)
└──── Major (breaking changes)
Qualité du changement
La qualité du changement n'est généralement pas connue tant que le processus de validation n'est pas terminé. Cela est déterminé après validation, une fois le package généré et testé. En raison de cela, 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).
Bien que les solutions de contournement existent pour prévalider (par exemple, consommer les DLL de la build directement avant qu’elles soient empaquetées et publier les packages dans un environnement « débogage » ou « CI », puis valider et republier ces packages dans un environnement « release »), elles ne garantissent pas que le package final répond aux normes de qualité.
Au lieu de cela, vous pouvez utiliser des affichages de flux pour communiquer la qualité. À l’aide de la @Release vue, vous pouvez partager uniquement les packages qui ont passé la validation et qui ont atteint votre barre de qualité. Cela permet à vos consommateurs de voir uniquement le sous-ensemble de versions de package testées, validées et prêtes à être consommées. Cette approche garantit aux consommateurs l’accès à des packages stables et prêts pour la production. Pour plus d’informations, consultez Promouvoir les packages et gérer les vues de flux .