什么是源视图？
Azure DevOps Services | Azure DevOps Server 2022 - Azure DevOps Server 2019
源视图使开发人员能够与其使用者共享包版本的子集。 源视图的一种常见用途是共享已测试和验证的包版本，但会保留仍在开发中的包和/或不符合特定质量条。
默认视图
所有项目源都有三个视图：@local和@prerelease@release。 后两个是建议的视图，你可以根据需要重命名或删除。 @local是上游源中常用的默认视图。
该@local视图包含直接发布到源的所有包，以及从上游源保存的所有包。
源视图是只读的，这意味着连接到视图的用户只能使用发布到该视图和/或以前从上游源保存的包。 请参阅 包图 ，了解如何构造可用包。
注意
Azure Artifacts 仅支持在默认视图中发布和还原包 - @Local。
源视图和上游源
源视图和上游源旨在协同工作，以提供用于共享和使用包的企业级解决方案。 为了使其他 Azure Artifacts 源使用源作为上游源，必须将源的可见性设置为组织成员或 Microsoft Entra ID 的成员，具体取决于你的方案。 如果选择后者，则组织中的所有用户都可以访问源。 此外，组织中的所有源以及与同一个 Microsoft Entra 租户关联的其他组织都可以上游源。
注意
公共项目中的所有源视图都可供 Internet 上的每个人都访问。
包含源视图的发布包
创建发布包时，必须传达三条信息： 更改的性质 、 更改的风险 以及 更改的质量 。
更改的性质和风险
变化的性质和风险都与 更改本身有关，即你准备执行的操作，它们都是在工作开始时已知的。 如果要引入新功能、对现有功能进行更新或修补 bug;这是 更改的性质 。 如果仍在对应用程序的 API 部分进行更改;这是更改风险的一个方面。 许多 NuGet 用户使用 语义版本控制 （SemVer）表示法来传达这两条信息。 SemVer 是一种广泛使用的标准，能够很好地传达这种类型的信息。
更改质量
在 验证过程完成之前，通常不知道更改的质量 。 这是在生成和打包更改之后完成的。 由于此细节，无法传达版本号数字段（例如 1.2.3）变化的质量。 有一些解决方法可以预先验证（例如，在将包打包并发布到“调试”或“CI”环境之前直接使用生成的 DLL），然后验证并重新发布这些包到“发布”环境，但我们看到的一切都无法真正保证生成的包符合正确的质量标准。
可以将 @Release 视图用作传达更改质量的方法。 @Release使用视图，可以共享符合质量条的包，并允许使用者仅查看已测试、验证并已准备好使用的包版本的子集。
