Vad är flödesvyer?
Azure DevOps Services | Azure DevOps Server 2022 – Azure DevOps Server 2019
Med feedvyer kan utvecklare dela en delmängd paketversioner med sina konsumenter. En vanlig användning av flödesvyer är att dela paketversioner som har testats och verifierats men som håller tillbaka paket som fortfarande är under utveckling och/eller inte uppfyller ett visst kvalitetsfält.
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.
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 skapas.
Kommentar
Azure Artifacts stöder endast publicering och återställning av paket från och till standardvyn – @Local.
Feedvyer och överordnade kä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-feeds ska kunna använda ditt flöde som en uppströmskälla måste du ange feedens synlighet för medlemmar i din organisation eller medlemmar i ditt Microsoft Entra-ID, beroende på ditt scenario. Om du väljer det senare kommer alla personer i din organisation att kunna komma åt ditt flöde. Dessutom kommer alla feeds i din organisation och andra organisationer som är associerade med samma Microsoft Entra-klientorganisation att kunna uppströms till ditt flöde.
Kommentar
Alla feedvyer i ett offentligt projekt är tillgängliga för alla på Internet.
Versionspaket med flödesvyer
När du skapar versionspaket är det viktigt att förmedla tre typer av information: ändringens art , risken för ändringen och ändringens kvalitet .
Natur och risk för förändringen
Både arten och risken för förändringen gäller själva förä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 naturen av din förändring. Om du fortfarande gör ändringar i API-delen av ditt program; Detta är en aspekt av risken för din förändring. Många NuGet-användare använder semantisk versionshantering (SemVer) för att förmedla dessa två informationsdelar. 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
Kvaliteten på ändringen är inte allmänt känd förrän valideringsprocessen är klar. 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 @Release vyn som ett sätt att förmedla kvaliteten på dina ändringar. Med hjälp @Release av vyn 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.
