Artifactory仓库架构和命名最佳实践（上）
背景
为公司设计正确的仓库命名规范是⾄关重要的。为产品开发创建正确的仓库结构，在产品扩展性⽅⾯发挥着⾄关重要的作⽤。它不仅可以减少创建管理仓库的开销，还可帮助团队意识到仓库规范管理的好处，帮助组织内部各个团队清楚的了解软件交付物的命名规范。
使⽤ Artifactory 作为仓库管理平台，将所有不同类型的⼆进制⽂件存放在⼀个地⽅，并将企业级功能完全集成到软件开发⽣命周期中。
软件开发涉及到不断更新和迭代的过程。 通过参与产品开发的各个团队，以最⾼精度维护仓库结构成为该过程的重要任务之⼀。 我们⾯临的挑战是，没有清晰的命名约定或创建仓库结构的指导原则可以遵循。
JFrog 建议使⽤四部分的命名结构，其中包括：
1. Team —— 产品或团队名称作为项⽬的主要标识符
2. Technology —— 使⽤的技术，⼯具或包的类型。电话机的英文
greverbal
3. Maturity —— 软件包⽣命周期，例如开发，测试和发布阶段。
4. Locator —— 定位，⼯件的物理拓扑。
泰文翻译
lively是什么意思此结构会⽣成以下推荐的仓库命名结构，该结构应在整个公司中使⽤：<Team> - <Technology> - <Maturity> - <Locator>。
其他准则适⽤于四种不同的 Artifactory 仓库类型，包括：本地，远程，虚拟和分发。 本地仓库命名约定由两部分组成。第⼀个是存储的⽂件是你们⾃⼰的，第⼆个是第三⽅的。 远程仓库是 Artifactory 拓扑的⼀部分，它们的命名规则应与本地仓库定义的规则保持⼀致，或者如果是提供给其他⼈使⽤的，建议给它们稍微不同的命名约定。虚拟仓库是对外透明的，封装了内部细节，所以不需要定位器结构字段。最后重要的⼀点是，分发仓库⽀持多种技术类型，通常以“-Dist”结尾。
为仓库设置命名约定时，需要考虑的三个主要类别是：安全，性能和可操作性。
当使⽤ Artifactory 作为仓库时，最好的做法是在仓库级别管理安全权限。这样公司中不同的团队将会管理不同的仓库。
性能问题因技术⽽异，为了确保仓库效率最⾼，应该执⾏清理策略。此外，在仓库结构中应⽤的可操作性应考虑效益问题以及团队结构。尽管管理员偏好较少的仓库，但有时创建单独的仓库，并具有不
同的读/写/删除权限，以防⽌团队间的彼此⼲扰是最好的⽅式。
本⽂涵盖的所有这些考虑事项将使你能够在全球拓扑中管理你的 Artifactory，并为安装了企业版 Artifactory 的公司提供所需的 DevOps ⽀持。
使⽤仓库管理平台
JFrog Artifactory 是为加速开发周期⽽创建的通⽤⼆进制仓库管理平台。这意味着它不仅是⼀个仓库，⽽且还是⼀个功能强⼤的管理平台，有助于管理多个仓库以简化分布式软件开发流程。
绅士的英文在为仓库定义准则和约定时，灵活性优于严格的规则。创建弹性的规范能够为 Artifactory 管理员提供⾜够的空间来根据需要量⾝定制规则。
命名约定和仓库结构是同样重要的。选择合适的名称和⽤⼀个仓库还是多个仓库⼀直是棘⼿的问题。选择的组织结构应该与你们现在的开发，测试，部署和分发流程⼀致，这⼀点⾮常重要。这⾥所描述的命名约定和组织结构主要基于当前主流的流程，但可能并不适⽤于所有公司。然⽽，希望你可以使⽤这⾥列出的组织和命名中的注意事项来将其适应于你⾃⼰的命名约定。
创建命名约定
公司通常需要处理在多个仓库中产⽣的多种技术，⽣命周期和产品。当你有不⽌⼀个产品的时候，你需要给它起个名字。作为开发⼈员，在过去的⼏⼗年⾥，我们已经了解到⼀个名字可以清晰地表明你正在做什么。
JFrog 认为最佳实践应该包含以下四点：
最佳实践1：定义⽣成可⽤ URL 的仓库名称。例如，由于 Artifactory 是区分⼤⼩写的，所以建议使⽤⼩写字母。更重要的是，避免在你的环境中使⽤需要 URL 编码的字符，例如”_”字符。通过简化 URL，这将使你的 Artifactory 实例的最终使⽤者以及管理反向代理和负载均衡的管理员更容易理解和使⽤。俄罗斯9岁模特
lf documenting code! 尽可能确保你的仓库名称是⾃描述。虽然是⼀个描述字段，但是当仓库最佳实践2：所有编码⼈员都熟悉的：lf documenting code!
名称清晰时，它使事情变得更加容易。
Artifactory UI 界⾯搜索展⽰的问题。你的仓库名字的描述应该放到⾸位。通过这样做，在应⽤过滤器选项之后，将根据名最佳实践3：Artifactory UI
Artifactory 树型浏览器中将相似的仓库放在⼀起。
少儿培训
尚艺美容美发称组件的重要性在 Artifactory
最佳实践4：要注意⼀些特殊的规则。例如，有⼀些特殊字符（'/'，'\\'，'：'，'|'，'？'，'*'，'''，'''，'<'，'>'' ，'+'，空格）应当被禁⽌。名称最多可以包含64个字符，远程仓库可以包含58个字符。还有⼀些保留的和不推荐的名称，如'Repo'和'Trash'。附加单词'-Cache'也被认为是保留的，因为它主要⽤于为远程仓库⾃动创建缓存。
仓库命名基础结构
JFrog 推荐⼀个四部分命名结构，最好是按以下顺序。
1.产品或团队
产品或团队名称是项⽬的主要标识。你可以根据企业命名约定选择缩写。例如，⼀些组织喜欢使⽤产品缩写⽽不是使⽤整个产品名称。另⼀⽅⾯，有些⼈更喜欢使⽤团队名称和产品名称。主要的想法是选择⼀个与你的团队相关且容易理解的名字。
例如：JFrog
为命名约定选择团队/产品名称的粒度级别是开发命名约定中最困难的部分之⼀。这将在本⽂后⾯的仓库组织部分进⼀步讨论。但是，由于存在虚拟仓库，这也可以在晚些时候相当容易地更改，所以不要太担⼼，所以应选择易于理解和⼀致的东西，并查看它是否适⽤于你。
2.技术
技术是指⼯具或包装的类型。Artifactory 是⼀个通⽤的⼆进制仓库管理平台，其核⼼功能使其能够存储各种类型的包，这些包涵盖了Maven，NuGet 和 Docker 等技术。每个仓库应该保存同⼀种类型的⼆进制⽂件。
继续上⾯的⽰例，例如：JFrog-Docker
在命名约定中加⼊⼯具或软件包名称的类型可帮助开发⼈员识别⼯件，使其更容易根据其类型进⾏浏览。在⼤多数情况下，这将精确反映在创建仓库时选择的软件包类型，但你可以选择更具体。例如，如果你的通⽤仓库存储视频，则可以选择“Video”⼀词作为技术类型。其他例⼦有：使⽤'Centos'⽽不是'Rpm'或'Rhel'，'Ubuntu'⽽不是'Deb'。
3．成熟度
Maturity 指的是软件包开发的成熟度，如开发，测试和发布阶段。包的Promotion 可以在 Artifactory
中以多种不同的⽅式完成。从较⼩事件的简单属性标记（例如“通过测试”）到⼯件已经通过的较多的质量检测，其中⼯件将从⼀个仓库移动或复制到另⼀个仓库。
那么，为什么我们要这样做呢？通常情况下，在传统的开发模式中，当⼯件改变其状态时，这可能代表了在其成熟度的不同阶段。你可能有⼀个“ 沙箱 ”，对于在初始提交构建的“ Dev ”或“ Snapshot ” 产⽣的⼯件正在由开发⼈员在他们的办公电脑上进⾏测试。然后⼯件将移动到“ Qa ”，“ Preprod ”或“ Staging ”仓库，最后转到“ Relea”或“ Prod “仓库。当⼯件完成时，或者当它触发了保留的某些监管要求时，⼯件及其可能的所有依赖关系可以移动到“ Archive”。
在 DevOps 中怎么做呢？根据 DevOps 原则，⼯件不应该传递给新团队，⽽应该在整个⽣命周期中由同⼀团队拥有。从⾃动化的⾓度来看，控制状态不是关于公司内的团队，⽽是基于具有不同权限模型的不同环境，以确保⼯件不会过早部署。
继续上⾯的⽰例，例如：JFrog-Docker-Relea
下图说明了⼀个典型的 Promotion 概念。如果满⾜质量要求，⼯件从⼀个 DevOps 阶段传递到另⼀个阶段：
chic
4.定位
定位实质上是指你的⼯件的物理拓扑结构。拓扑中的每个仓库都必须是唯⼀的。真正本地的本地仓库，意味着它们的内容在本地进⾏管理/上传，应以“Local”结尾。作为其他地⽅管理的内容和远程仓库应以其他服务的指⽰符结尾。
例如，“bj” 可以⽤于在北京的数据中⼼管理的⼯件。为了符合要求，访问外部位置的远程仓库应以“-Remote”结尾。这通常被省略，特别是对于主要的中央仓库，假设⽤户熟悉“Jcenter”和“Npmjs”作为中央仓库的名称，但是这样的假设可能导致混淆。
panty
使⽤以下仓库名称完成我们的⽰例：JFrog-Docker-Relea-bj
仓库类型
Artifactory 拥有四种仓库类型：本地，远程，虚拟和分发。本地和远程仓库是真正的物理仓库，⽽虚拟仓库实际上是它们的集合，⽤于创建搜索和解决⼯件的受控域。分发仓库是将数据从 Artifactory 导出到 JFrog Bintray 的特例。
JFrog Bintray 是⼀个通⽤的分发平台。它是⼀个云平台，可让你完全控制发布，存储，升级和分发软件的⽅式。
本节提供了有关针对每个仓库类型如何应⽤上述命名结构的指导原则。
命名约定的任何部分在不相关时都可以是可选的，并且四部分命名约定的⼀般概念可以适⽤于初始约定中未涉及的其他情况。
1.本地仓库
使⽤前⼀节中描述的四部分命名结构，我们可以解决本地仓库命名约定的所有必需注意事项，包括：团队/组织（业务单位或产品），技术，成熟度和定位。正如所讨论的，顺序代表了重要性。JFrog 的建议是：<Team> - <Tech> - <Maturity> - <Locator>，但其他命名⽅式可能适⽤于某些情况。
本地仓库有两个基本的使⽤场景：第⼀个场景是当你引⽤与你⾃⼰的组织⼯件相关的⼯件时。在这种情况下，定位完全基于拓扑考虑。另⼀⽅⾯，团队和成熟度稍微复杂⼀些，主要取决于所需的仓库数量。团队取决于业务逻辑和权限。成熟度取决于⼯件的所有权/处置。如果⼀个 Artifactory 实例专注于部署⽽不是开发，那么考虑成熟度实际上⽐技术更重要。但是，优先符合统⼀的命名约定。
本地仓库的第⼆个使⽤场景是⽤于存储第三⽅⼯件的时候。这通常包括⼀种场景，⽆论是什么原因，你⽆法远程代理某第三⽅依赖源（⽆论是因为防⽕墙还是仅仅因为它没有 http 访问权限），或者你正在实施⼀个⽩名单。总的来说，在这两种场景下，技术类型结构定义还是⼀样的，但团队名称应该是
指明其来源地的东西; 例如，Tomcat 或 Centos。由于通常还有这些拓扑，所以定位的⽅式与其他本地仓库的⼯作⽅式相同。然⽽，成熟度现在不是像 Relea / Dev 这样的东西，⽽是反映了⼯件的信任级别。所以它可能
是“Upload”或“Whitelist”。例如，“Tomcat-Mvn-Upload-Local”。如果你使⽤本地仓库在某个状态下对远程进⾏快照，则可能是⽇期。例如，“Centos7-Rpm-Oct2017-Local”。
2.远程仓库
远程仓库分为两类：
⼀些是 Artifactory 拓扑的⼀部分，在这种情况下，它们的命名约定应该与本地储存库和四个相关部分的命名约定⼀致，并且定位指⽰源储存库被远程访问。
⼀些是中央储存库。这些是你的⼯件正在从中依赖的外部仓库，可以通过它们的源 ID 引⽤，如 JCenter。对于严格的⼀致性，你可以考虑以下模型，<Center_Name> - <Technology> --Remote，默认的 Artifactory 命名⾏为使⽤源。通常，这有助于轻松识别⼯件。
3.虚拟仓库
⼤多数虚拟仓库不包含<Locator>，并且由<Team> - <Tech> - <Maturity>组成。在很多情况下，⽤户不需要知道拓扑实现细节。通常，所有消费和写⼊都是通过虚拟仓库完成的，⽽不是本地/远程仓库。这样尽可能多的实现细节可以省略，让⽤户使⽤⼀个众所周知的 URL。此外，尽管本地仓库的成熟度严格限于⼯件阶段，但对于虚拟仓库，你可能会更多地考虑受众。例如，名称中包含“-Dev”的虚拟仓库指⽰开发⼈员应该使⽤的虚拟仓库。最后，⼀个常见的使⽤案例是整个公司使⽤⼀个虚拟仓库，该仓库将特定技术的所有仓库（例如 Docker）聚合为解析和读取权限。
4.分发仓库
分发仓库在这个约定中有些异乎寻常，因为它们可以⽀持多种技术类型，并且通常没有成熟度的区别，因为你只应该分发稳定的⼯件。⼀般来说，它们应该以“-dist”作为定位符结束。分发产品的分发仓库应使⽤以下约定：<productname> -product- <orgname> -dist。更通⽤的分发仓库应该使⽤像<rulet> - <orgname> -dist这样的约定为其配置的规则集的某个名称标识符。如果你的组织不具有多个 Bintray 组织，则这种组织名称可以省略，这是⽐较常见的。但是，必须将不同的分发仓库分发给不同的组织，并且额外的组织（例如⽀持开源项⽬）也不是前所未闻的。有些前瞻性规划不会损失任何功能，这就是为什么它包含在推荐的约定中的原因。
未完。请关注下篇：Artifactory 仓库架构和命名最佳实践（下）
