Azure DevOps 服務 |Azure DevOps Server |Azure DevOps Server 2022
開發者可以利用饋送視圖與使用者分享特定的一組套件版本。 當你想提供已測試與驗證的套件存取權，同時保留仍在開發中或不符合品質標準的套件時，這非常有用。
默認檢視
每個 Artifacts 訂閱源預設包含三個檢視：@local、@prerelease和@release。 後面兩個是建議的視圖，你可以根據需要重新命名或刪除。
@local 是預設視角，且常用於上游來源。 你可以在 動態設定>檢視中更改預設視圖，但請注意這不會啟用直接發佈到該視圖。 套件只能發佈至基本供應源，它們會在 @Local 視圖中可供使用。
該 @local 視圖包含：
- 所有套件都直接發佈到動態。
- 所有套件都是從 上游來源儲存的。
訂閱視窗是 唯讀的，意即連接到檢視的使用者只能使用已發佈到該檢視的套件和/或先前從上游來源儲存的套件。 請參閱 套件圖 以了解套件圖的構造方式。
注意
Azure Artifacts 僅支援從預設檢視 @Local 發佈與還原套件。
資訊流檢視和上游來源
訂閱檢視與上游來源設計為協同運作，提供企業級的套件共享與消費解決方案。 若要讓其他 Azure Artifacts 摘要使用您的摘要作為上游來源，您必須根據情境將摘要的可見性設定為 您的組織成員，或 您的 Microsoft Entra ID 成員。
如果你選擇 Microsoft Entra ID，組織中所有人都能存取你的資訊流，而且你組織內及其他與同一 Microsoft Entra 租戶相關的組織，也能將其資訊流上傳到你的資訊流。
注意
公開資料流中的所有的資料流檢視都可以被互聯網上的所有人存取。
含資料流視圖的發行套件
在發布套件時，溝通三個關鍵面向非常重要：
在建立發佈套件時，傳達三個資訊非常重要：
變更性質：將引入何種類型的變更。
變革的風險：變革可能帶來的顛覆性或破壞性。
變更品質：套件是否符合您的驗證標準。
變更的性質和風險
本質與風險都與變更的意圖相關，這在開發初期即已知：
Nature：你們是在新增功能、更新現有功能，或是修正錯誤嗎？
風險：這項變更是否會影響像 API 這類關鍵元件，或引入破壞性的變更？
大多數團隊使用 Semantic Versioning （SemVer）來傳達這些資訊。 SemVer 被廣泛採用，且能有效表示性質與風險。
1.2.3
│ │ └─ Patch (bug fixes)
│ └── Minor (new features)
└──── Major (breaking changes)
變更的品質
在驗證流程完成之前，通常不會知道變更的 品質。 這是在驗證後，套件建置並測試完成後決定的。 因此，無法在版本號的數值區段（例如 1.2.3）中傳達變更的品質。
雖然有變通方法可以預先驗證（例如，在套件封裝前直接取用建置的 DLL，並將套件發佈到「除錯」或「CI」環境，再驗證並重新發布到「發佈」環境），但這些方法無法保證最終套件符合品質標準。
相反地，你可以用資料流視圖來傳達品質。 透過檢視 @Release ，你只能分享通過驗證且符合品質標準的套件。 這讓消費者只能看到經過測試、驗證並準備使用的套件版本子集。 此方法確保消費者能取得穩定且可生產的套件。 詳情請參見 推廣套件與管理訂閱視圖 。