Azure DevOps Services | Azure DevOps Server 2022 | Azure DevOps Server 2020
发布包时，必须通过从上游源消费依赖项来确保该包的所有依赖项在您的源中可用。 一旦从上游源使用一个包，副本将保存到您的提要中。 这可确保即使上游源不可访问，副本仍可供你和源使用者使用。
上游如何构造可用包集
由于 Azure Artifacts 源可以有其他源作为上游，因此有可能创建上游源的循环，其中源 A 上游至源 B，B 上游至源 C，最终源 C 上游返回至源 A。如果这种循环管理不当，可能会导致包请求出现问题，形成一个无限循环：用户从源 A 请求包，A 向 B 请求，B 向 C 请求，最后 C 请求返回至 A，形成一个循环。
上游源旨在防止此类情况。 当订阅源从其上游源查找软件包时，它会在为该上游源配置的视图中接收软件包。 这意味着查询源 A 不会触发可传递查询来馈送 C （A -> B -> C），因为视图是只读的。 因此，源 A 将有权访问以前由用户保存到 B 中的 C 中的任何包，但不能访问 C 中提供的完整包集。
这会将责任置于馈送 B 上，以确保其本地包表示完整的依赖关系图。 通过这样做，通过其他源的上游使用 B 包的用户可以成功解决依赖关系图，并安装所需的B包，而不会遇到问题。
示例：构造可用包集
让我们考虑三个信息源：Fabrikam、Contoso 和 AdventureWorks。 在此图中，我们将在引入上游源时检查 Fabrikam 源的可用包。
最初，Fabrikam 没有上游源，这意味着连接到 Fabrikam 的用户只能安装小组件包的 1.0.0 和 2.0.0 版本。 同样，Contoso 没有上游源，将连接到 Contoso 的用户限制为仅安装 Gizmos 包的版本 1.0.0 和 3.0.0。 这同样适用于 AdventureWorks 源，其中连接用户只能安装小工具包的 1.0.0 和 2.0.0 版本或 Things 包的 1.0.0 版本。
现在，让我们探讨 Contoso 将 AdventureWorks 添加为上游源的方案。 当用户连接到 Contoso 时，他们可以访问更广泛的包。 他们可以安装任何版本的 Gizmos、小工具或事物。 例如，如果用户安装 Gadgets@2.0.0，此特定包版本将保存到 Contoso，其中包含指向 AdventureWorks 的链接。
现在，假设 Fabrikam 源将 Contoso 添加为上游源。 连接到 Fabrikam 的用户可以安装任何版本的小组件、任何版本的 Gizmos，但仅限于已保存的小工具版本（2.0.0）。
用户无法安装小工具版本 1.0.0 或任何版本的 Things，因为这些包版本尚未由 Contoso 用户保存到 Contoso。
