在 Azure Artifacts 中打包图形
Azure DevOps Services | Azure DevOps Server 2022 - Azure DevOps Server 2019
发布包时，必须通过从上游源中使用这些依赖项来确保该包的所有依赖项在源中可用。 从上游源使用包后，副本将保存到源。 这可确保即使上游源不可访问，副本仍可供你和源使用者使用。
如何上游构造可用包集
由于 Azure Artifacts 源可以有其他源作为上游，因此有可能创建上游源的周期，其中源 A 上游供 B，后者上游向 C 提供源，并最终将 C 上游馈送回源 A.这种循环（如果管理不当）可能会导致包请求出现问题，创建无限循环，其中用户从源 A 请求包，从 B 请求，从 C 请求，然后从 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。
