Artifactory 仓库架构和命名最佳实践（下）

Artifactory 允许通过包含/排除模式在单个文件夹甚至文件级别进行管理权限。一般来说，这里的最佳做法是在仓库级别管理权限。对于具有高度结构化的仓库（如 Maven 和 RPM），可以在文件夹级别实现细粒度的控制。但是，对于管理员来说，这仍然可能过于复杂。尤其是关于那些需要细粒度的写权限的高度结构化的仓库来说。

当你的团队之间没有合作或没有共享数据且彼此的软件间不需要读取权限时，就应该在相同的技术和成熟度级别设置不同的仓库。你也可以根据写入权限选择提供不同的仓库，并假设它们被聚合在虚拟仓库中供读取。这种基于写入的仓库的选择在仓库类型中非常重要，这些仓库类型没有被 Namespacing 划分得很好，比如默认的 NuGet 行为或者没有设置好的的 Npm 仓库。

另一个应该考虑的是性能。尽管技术上的差异有所不同，但对于任何给定的技术来说，清楚知道仓库中包的最大数量是有意义的。在 Maven 中，这往往是成千上万的，并且更多地应该考虑 UI 界面的性能。然而在 Yum / Debian 中，这是数以千计的，而更多的是计算索引和索引文件大小，它们对客户端的性能会有很大影响。

另一方面是清理策略。一个完全没有清理策略的 Artifactory 服务器将会快速地增加存储的使用率，而且一般来说，大部分并不是你真正需要存储的东西。实施清理策略的机制有很多种。根据公司的业务需求，不同的项目可能有不同的策略。例如，Dev-sandbox-docker 仓库可能有一个策略，该策略规定应删除最近两周内未下载的任何 Docker Tag。另一方面，受监管的行业可能会有监管要求，即任何在受监管的生产环境中的产物都必须保留十年。生命周期的各个阶段之间的产物提升对于不同的仓库是至关重要的。但是这些策略对于正在开发的应用程序来说也可能不一样。

当在特定环境中为特定团队管理工件仓库时，其他基本可操作性注意事项均适用。一般而言，这些策略应该在仓库级别进行处理，因此这将成为选择仓库结构的决定性因素。

首先是一个相当简单的：确定商业价值。如果你正在管理跨越公司内多个大型项目和业务单位的 Artifactory，除了上述考虑之外，你还需要确定这些不同的项目/单位如何使用 Artifactory 服务。这可能是为了明确使用效益，或者仅仅是为了追踪哪些单位导致了什么样的成本。只要你想跟踪公司内某个特定单位的使用情况并与其他组织分开使用，则这个单位应该有自己的仓库，并根据命名规则进行细分，以便于识别。

此外，只要你不能成功的协调命名约定和目录结构组织，那么应该分仓库进行管理。也就是说，一个大团队如果没有严格的规范，那将无法成功地管理像工件组的 ID 命名约定，那么最好给他们单独的仓库，并且设置一个最大存储的限制。一般而言，写入权限，甚至更多的删除权限，应该具有合理的特定性，以防止团队干扰彼此的工作。一般而言，删除权限只应提供给非策略清理之外的一个非常小的组（请参阅上述性能部分的清理策略讨论）。

考虑到这一切，管理员通常更喜欢更少的仓库。仓库管理流程的自动化程度越高，其实际影响就越小。例如，在一个强大的 DevOps 环境中，你可能会遇到一种情况，即每一个测试都可以被看作是一种提升。虽然对于每个测试使用 Promotion API 可能会更好，但是对于几十个测试中的每一个都有一个仓库是没有意义的，而是应该通过属性跟踪这些结果，并为主要控制点保留单独的仓库。

下面总结了各种仓库类型的最佳实践命名约定的示例：

1. 本地仓库

team-tech-maturity-locator

例子:

• tigerteam-docker-dev-local

• tigerteam-docker-release-local

2. 远程仓库

例子：

• tiger-mvn-release-boston

• jcenter-remote

3. 虚拟仓库

<team>-<tech>-<maturity>

例子：

• tiger-docker-dev

• tiger-docker-prod

4. 分发仓库

例子：

• artifactorypro-product-jfrog-dist

• examples-jfrogtraining-dist

管理仓库并选择命名约定是 JFrog Artifactory 管理员需要做出的第一个也是最重要的决定之一。尽管虚拟仓库的使用可以在以后进行更改，但最好先选择一个命名约定。

本文针对仓库结构和命名约定总结了最佳实践经验，以帮助你回答以下问题：“我需要多少仓库？”。它提供了一个由四部分组成的约定<team> - <tech> - <maturity> - <locator>，它可以用作命名和组织结构的基本最佳实践指南。使用这个建议的惯例，大多数组织问题变得相当清楚。

本文中描述的约定将允许你在全局拓扑中扩展你的 Artifactory。它将支持大型企业的 DevOps 平台建设，为众多不同团队和项目的数千名开发人员提供服务。