Vad är flödesvyer?
Azure DevOps Services | Azure DevOps Server 2022 – Azure DevOps Server 2019
Med Feed-vyer kan utvecklare dela en delmängd av paketversioner med sina konsumenter. En vanlig användning av flödesvyer är att dela paketversioner som har testats och verifierats men att utesluta paket som fortfarande är under utveckling och/eller inte uppfyller en viss kvalitetsnivå.
Standardvy
Alla artefaktflöden har tre vyer: @local, @prereleaseoch @release. De två senare är föreslagna vyer som du kan byta namn på eller ta bort efter behov.
@local är standardvyn som ofta används i överordnade källor. Du kan ändra standardvy i inställningarna för feed >Vyer, men om du gör det kommer direktpublicering till den vyn inte att aktiveras. Paket kan endast publiceras till basflödet, där de kommer att vara tillgängliga i @Local-vyn.
Vyn @local innehåller alla paket som publicerats direkt till feeden och alla paket som sparats från överordnade källor.
Flödesvyer är skrivskyddade, vilket innebär att användare som är anslutna till en vy endast kan använda paket som publiceras i den vyn och/eller paket som tidigare sparats från överordnade källor. Se paketdiagram för att lära dig hur tillgängliga paket konstrueras.
Notera
Azure Artifacts stöder endast publicering och återställning av paket från och till standardvyn – @Local.
Flödesvisningar och uppströmskällor
Feedvyer och överordnade källor är utformade för att fungera tillsammans för att tillhandahålla en lösning på företagsnivå för att dela och använda paket. För att andra Azure Artifacts-flöden ska kunna använda ditt flöde som en uppströmskälla måste du ställa in flödets synlighet till medlemmar i din organisationeller medlemmar i ditt Microsoft Entra ID, beroende på vilket scenario som gäller. Om du väljer det senare kommer alla personer i din organisation att kunna komma åt ditt flöde. Dessutom kommer alla flöden i din organisation samt i andra organisationer som är associerade med samma Microsoft Entra-klientorganisation att kunna överföras till ditt flöde.
Not
Alla feedvyer i ett offentligt projekt är tillgängliga för alla på Internet.
Släppa paket med flödesvyer
När du skapar versionspaket är det viktigt att förmedla tre typer av information: ändringens natur, risken med ändringen, och kvaliteten på ändringen.
Natur och risk för förändringen
Både arten och risken för ändringen gäller själva ändringen, det vill säga vad du vill göra, de är båda kända i början av arbetet. Om du introducerar nya funktioner, gör uppdateringar av befintliga funktioner eller korrigerar buggar. Detta är den naturen av din förändring. Om du fortfarande gör ändringar i API-delen av ditt program är detta en aspekt av risk av din ändring. Många NuGet-användare använder Semantic Versioning (SemVer) notation för att förmedla dessa två delar av informationen. SemVer är en allmänt använd standard och gör ett bra jobb med att kommunicera den här typen av information.
Förändringens kvalitet
Den kvaliteten på ändringen är inte allmänt känt tills valideringsprocessen är slutförd. Detta kommer efter att din ändring har skapats och paketerats. På grund av den här informationen är det inte möjligt att kommunicera kvaliteten på ändringen i det numeriska segmentet av versionsnumret (t.ex. 1.2.3). Det finns lösningar för att förbekräffa (t.ex. förbruka byggets DLL:er direkt innan de paketeras och publicera paketen till en "felsökningsmiljö" eller "CI"-miljö och sedan validera och publicera om dessa paket till en "versionsmiljö" men ingen som vi har sett kan verkligen garantera att det skapade paketet uppfyller rätt kvalitetsstandard.
Du kan använda vyn @Release som ett sätt att förmedla kvaliteten på dina ändringar. Med hjälp av vyn @Release kan du dela paket som uppfyller kvalitetsfältet och låta dina konsumenter endast se delmängden av paketversioner som har testats, verifierats och är redo att användas.
