构建和命名人工存储库的最佳实践

介绍

使用存储库管理器

JFrog Artifactory是一个通用二进制存储库管理器这是为了加快开发周期。这意味着它不仅存储库同时也是一个非常有能力的管理者，帮助组织多个存储库以简化分布式软件开发过程。

在为存储库定义指导方针和约定时，灵活性优于严格的规则。创建弹性指导方针为Artifactory管理员提供了足够的空间来根据需要定制规则。

命名约定和存储库结构密切相关。选择合适的名称并决定是需要单个存储库还是多个存储库总是一件困难的事情。您选择的组织结构必须与您的开发、测试、部署和分发流程在您的组织中如何工作相匹配，这一点很重要。这里表示的命名约定和组织结构主要基于许多相当常见的流程，但可能并不适合所有组织。但是，希望您可以使用此处列出的组织和命名方面的注意事项，使其适应您自己的命名约定。

创建命名约定

组织经常要处理多个问题项目，技术，生命周期,hth华体会最新官方网站，在多个存储库中生成。当你有一个以上的东西时，你需要给它命名。作为开发人员，在过去的几十年里，我们已经了解到一个名称要么可以澄清您正在做的事情，要么可以混淆它。

本白皮书讨论了存储库命名约定和管理。
有关工件命名约定的其他信息，请参见仓库布局．

在我们深入讨论细节之前，让我们回顾一下三个主要问题:

第一个是定义生成的存储库名称使用url．例如，由于Artifactory是区分大小写的，所以使用小写字母是一个好主意。更重要的是，避免在您的环境中使用需要URL编码的字符，例如' _ '字符。通过简化您的Artifactory实例的最终消费者的url，以及必须管理反向代理和负载平衡器的管理员，这将使事情变得更容易。

第二个问题应该是所有程序员都熟悉的:自记录代码!尽可能确保存储库名称是自文档化的。尽管有一个描述字段，但是当存储库名称清晰时，事情会变得容易得多。第三个问题是基于Artifactory UI．标识存储库的最相关的信息应该放在首位。通过这样做，在应用筛选器选项之后，根据名称组件的重要性，字母排序将在Artifactory树浏览器中将相似的存储库一个接一个地放在一起。

第四个问题是基于某些隐含的限制，无论您如何设计约定。例如，有一些特殊字符(' / '，' \\ '，':'，' | '，' ?’, ‘*’, ‘”‘, ‘’’, ‘<‘, ‘>’, ‘+’, 空间)是完全禁止的。该名称最多可达64个字符，远程存储库最多可达58个字符。还有一些保留的和不推荐的名字，比如“repo”和“trash”。附加单词“-cache”也被认为是保留的，因为它主要用于为远程存储库自动创建缓存。

命名结构基础

JFrog推荐四部分命名结构，最好按以下顺序。

1.团队或产品

项目密钥或团队名称是项目的主要标识符．您可以根据您的公司命名惯例选择定制缩写。使用JFrog Projects，会自动使用项目密钥，而不是使用整个产品名称。另一方面，存储库可以在项目外部创建并稍后分配给它，因此项目密钥不是强制性的，有些人更喜欢使用团队或产品名称。主要思想是选择一个相关且易于团队理解的名称．

例如:老虎

为命名约定的项目/团队/产品名称部分选择粒度级别是开发命名约定中最困难的部分之一。这将在本白皮书后面的存储库组织部分中进一步讨论。然而，由于有了虚拟存储库，如果需要的话，这也是可以在以后相当容易地更改的东西，所以不要太担心，而是选择一些容易理解和一致的东西，看看它是否适合您。

2.技术

技术在很大程度上是指工具或包的类型．Artifactory是一个通用的二进制存储库管理器，它的核心功能使它能够存储各种类型的包，包括Maven、NuGet和Docker等技术。每个存储库应该保存一种类型的二进制文件。

以我们的例子为基础:tiger-docker

高级用户
一般来说，只要存储库类型通过其api和索引响应单个工具或某些情况下的一系列工具，任何存储库类型都可能具有任何所需的二进制文件。因此，当您选择存储库类型时，您就反映了您计划使用什么工具来检索工件。这会影响Artifactory将计算的索引类型。如果除了get/put rest API命令之外没有使用任何工具，则可能需要考虑使用通用存储库，从而完全避免索引计算的开销。

在命名约定中包含工具或包名称的类型有助于开发人员识别工件，使其更容易根据类型浏览它们。在大多数情况下，这将准确地反映在存储库创建时选择的包类型，但是您可以选择更具体的类型。例如，如果您的通用存储库存储视频，则可以选择单词“video”作为技术类型。其他的例子是:用' centos '代替' rpm '或' rhel '， ' ubuntu '代替' deb '。

3.成熟

成熟度指的是包成熟度级别，例如开发、阶段和发布阶段。工件提升可以在Artifactory中以许多不同的方式完成。从较小事件的简单属性标记(例如“通过测试X”)，到工件通过的更大的质量检验关。为了讨论的目的，我们感兴趣的促销活动，其中工件从一个存储库移动或复制到另一个存储库。

那么我们为什么要这样做呢?通常，这是在工件更改其控件状态．在传统的开发模型中，这可能代表在软件生命周期的不同阶段拥有软件的实际团队。你可以有一个。”沙盒，当工件被开发人员在他们的办公桌上测试时，并且“dev"或"快照对于在初始提交时构建时发生在CI系统之外的构建。然后工件将移动到“质量保证”、“preprod"或"暂存存储库，最后到一个释放"或"刺激”库。当工件退役时，或者当它触发保留的某些法规需求时，工件及其可能的所有依赖项可以移动到“存档”．

那么在DevOps？根据DevOps原则，工件不应该被传递给新的团队，相反，它们应该在整个生命周期中由同一个团队拥有。从自动化的角度来看，控制状态不是关于公司内部的团队，而是基于不同的环境它们具有不同的权限模型，以确保不会过早地部署工件。

继续以我们的例子为基础:tiger-docker-release

虽然本白皮书的大部分内容都集中在命名约定上，但它实际上是关于工件的组织。没有什么比工件成熟度的概念更值得考虑的了。下图说明了一个典型的促销概念。如果满足质量要求，工件将从一个DevOps阶段进展到另一个DevOps阶段:

4.定位器

定位器本质上指的是物理拓扑结构你的文物．拓扑中的每个存储库必须是唯一的。局部存储库这是真正的本地，这意味着他们的内容是在本地管理/上传的，应该在”——“．作为其他地方管理的内容的复制活动目标的本地和远程存储库应该以其他服务的指示符结束。

例如,“波士顿”可以用于管理的工件吗一个数据中心在波士顿．为了一致性，访问外部位置的远程存储库应该以“-remote”结尾。这通常被忽略，特别是对于主要的中央存储库，假设用户熟悉“jcenter”和“npmjs”作为中央存储库的名称，但是这样的假设可能会导致混淆。

使用以下存储库名称完成我们的示例:tiger-docker-release-boston

存储库类型

Artifactory主办四场比赛存储库类型：当地的，远程和虚拟．本地和远程存储库是真正的物理存储库，而虚拟存储库实际上是它们的聚合，用于创建用于搜索和解析工件的受控域。

JFrog Distribution使您能够在整个SDLC中大规模加速部署和并发下载:从CI到CD，通过设备管理-跨越远程站点，混合基础设施，云，边缘，嵌入式设备和物联网车队。了解更多>

本节提供了关于如何应用上面概述的命名结构的指导方针，特别是针对每种存储库类型。

在不相关的情况下，命名约定的任何部分都可以是可选的，并且四部分命名约定的一般概念可以适用于初始约定中未解决的其他情况。

1.局部存储库

使用前一节中描述的四部分命名结构，我们可以处理本地存储库命名约定所需的所有考虑事项，包括:项目/组织(业务单元或产品);技术，成熟,定位器．如前所述，顺序代表了重要性。JFrog的建议是:<团队> - <科技> - <成熟度> - <定位器>，尽管在某些用例中可能适用其他顺序。

本地存储库有两种基本用例:第一个用例当您引用与您自己的组织构件相关的构件时。在这种情况下，定位器纯粹基于拓扑考虑，而且也相当不言自明。另一方面，团队和成熟变得更复杂一点，基本上取决于所需存储库的数量。团队取决于业务逻辑和权限。成熟度取决于门和工件所有权/配置。如果Artifactory实例关注于部署，而不是生成，那么考虑成熟度实际上比技术更重要是有好处的。但是，遵循统一的命名约定是优先考虑的。

局部存储库
本地存储库是物理的、本地管理的存储库，您可以在其中部署构件。通常，它们用于部署内部和外部版本以及开发构建，但它们也可以用于存储在公共存储库(如第三方商业组件)上不广泛可用的二进制文件。使用本地存储库，所有内部资源都可以从跨组织的单个访问点从一个公共URL获得。2022世界杯阿根廷预选赛赛程了解更多>

本地存储库的一个重要的次要用例是用于存储第三方工件。这通常包括以下两种情况:无论出于何种原因，您都无法远程访问第三方工件的源(要么是因为存在气隙，要么只是因为它没有http访问)，或者您正在实现白名单方法。在这两种情况下，总的来说，技术不变，但团队的名字应该是表明其来源位置的东西;例如tomcat或centos。由于这些存储库通常仍有一个拓扑结构，因此定位器的工作方式与其他本地存储库相同。成熟但是，现在不像发布/开发那样，而是反映了工件的信任级别。所以可能是“上传”或“白名单”。例如:tomcat-mvn-upload-local。如果您正在使用本地存储库对处于某个状态的远程快照，则这可能是一个日期。例如,“centos7-rpm-oct2017-local”。

2.远程存储库

远程存储库分为两类:

那些是Artifactory拓扑的一部分，在这种情况下，它们的命名约定应该与本地存储库和四个相关部分的命名约定保持一致，并使用指示要远程访问的源存储库的定位符。

远程存储库
远程存储库充当在远程站点(如ConanCenter)上管理的存储库的缓存代理。根据控制缓存和代理行为的各种配置参数，在远程存储库中存储和更新构件。了解更多>

那些是中央存储库．这些是您的工件正在从中提取的外部存储库，并且可以通过它们的源id来引用，例如ConanCenter．对于严格的一致性，您可以考虑以下模型:< central_name > - <技术>远程，其中默认的Artifactory命名行为使用源代码。通常，这有助于轻松地识别工件。

中央存储库
ConanCenter是C/ c++的中央存储库柯南包。

3.虚拟存储库

有两种类型的虚拟存储库名称。

大多数虚拟存储库不包含<定位器>，都是由<团队> - <科技> <成熟度>．在许多情况下，用户不需要了解拓扑实现细节。一般来说，最佳实践是通过虚拟存储库完成所有消费和写操作，而不是通过本地/远程存储库。这样可以省略尽可能多的实现细节，让用户使用一个众所周知的URL。此外，对于本地存储库的成熟度严格地与工件阶段有关，而对于虚拟存储库，您可以更多地考虑受众。例如，名称中包含“-dev”的虚拟存储库表示开发人员应该使用的虚拟存储库。最后，一个常见的用例是整个公司使用一个虚拟存储库，该存储库聚集了特定技术的所有存储库，比如Docker，用于解析和读取权限。虽然严格遵守命名约定会要求团队名称为“all”或类似的名称(例如all-mvn-release)，但更常见的是直接省略团队名称并使用诸如docker-stage之类的存储库名称。

虚拟存储库名称的另一种主要类型是一致性别名，例如，与外部工具或遗留自动化的需求一致。虚拟存储库允许您为单个或多个存储库创建别名。这可能是一个一致的名称，但如果您需要适应遗留构建过程或使用特定名称的特定工具，这也可能非常有用。例如，对于自制程序，有一个名为“瓶子”的虚拟存储库是很有用的。一般来说，这些名称不受标准实践的约束，尽管在可能的情况下，尽量避免在虚拟存储库看起来符合但实际上不符合的情况下完全违反标准实践。例如，由于自动化需求需要此存储库名称，因此将虚拟存储库称为“ci-files-local”;如果可以避免，显然不建议这样做。

虚拟存储库
虚拟存储库封装了任意数量的本地和远程存储库，并将它们表示为从单个URL访问的统一存储库。它为您提供了一种管理开发人员访问哪些存储库的方法，因为您可以自由地混合、匹配和修改虚拟存储库中包含的实际存储库。您还可以通过定义底层存储库顺序来优化工件解析，这样Artifactory将首先查看本地存储库，然后查看远程存储库缓存，然后Artifactory将通过网络并直接从远程资源请求工件。对于开发者来说，这很简单。只需请求包，Artifactory将根据您的组织策略安全且最佳地访问它。了解更多>

仓库的组织和管理

既然我们已经建立了基本的存储库命名结构，那么让我们回顾一下在JFrog Artifactory中组织存储库时需要考虑的不同事项。从本质上讲，存储库组织可以归结为三件事:安全，性能和可操作性．大多数情况下，这些考虑因素将决定您设置的粒度。”团队，在较小的程度上，你计算的粒度成熟的水平。

1.安全

人工权限目标允许在单个文件夹甚至文件级别通过包含/排除模式管理权限。通常，这里的最佳实践是在存储库级别管理权限。对于具有高度结构化组织的存储库(如Maven和RPM)，可以在文件夹级别实现大量粒度。然而，对于管理员来说，这仍然太复杂，无法跟踪(尽管)有效的权限分析可以有所帮助)。对于READ权限尤其如此，尽管它工作的那些技术的更细粒度可能用于写权限。

至少，当您的团队没有协作或共享数据时，您应该在相同的技术和成熟度级别中拥有单独的存储库，因此没有/需要对彼此的软件具有读取权限。您还可以根据写权限选择提供不同的存储库，并假设它们聚集在虚拟存储库中用于读取。这种基于写的存储库的选择在不能很好地按名称空间划分的存储库类型中尤其重要，比如默认的NuGet行为或没有作用域的npm存储库。

2.性能

另一个主要问题是性能．这因技术而异，但对于任何给定的技术，在该存储库中往往存在有意义的包的最大数量。在Maven中，这往往是数十万，并且更多地受到UI考虑的驱动。然而，在Yum/Debian中，这往往是成千上万的，并且更多地受到计算索引的总体方法和结果索引文件的大小以及它们对客户端性能的影响的驱动。

另一方面是清理政策。一个完全没有清理策略的人工服务器将会以非常快的速度增加存储使用量，并且通常大多数都不是您真正需要存储的东西。实现清理策略的机制是另一回事。有些可以在这里找到。根据组织的业务需求，不同的项目可能有不同的策略。其主要驱动因素是成熟度，如上所述。例如，开发沙盒码头工人注册表可能有一个政策，规定任何在过去两周内没有下载的Docker标签都应该被删除。另一方面，受管制的行业可能会有监管要求，即任何处于受管制生产环境中的物品必须保留十年。在生命周期的这些阶段到不同的存储库之间建立一个可靠的升级模型是至关重要的。但是，这些策略也可能并不适用于所有正在开发的应用程序。虽然在生产中处理库存交易的申请将受到监管，但同一家公司用于管理午餐订购的工具可能在其“生产”生命周期完成后不久就会被丢弃，但在实际使用时确实需要维护。

3.可操作性

当涉及到为特定环境中的特定团队管理工件存储库时，需要考虑其他基本的可操作性问题。一般来说，这些策略需要在存储库级别进行处理，因此在选择存储库结构时，这将是一个驱动因素。

第一个相当简单:确定业务价值。如果您正在管理跨越公司内多个大型项目和业务单元的Artifactory，那么除了上述考虑之外，您还希望能够确定这些不同的项目/单元如何使用Artifactory服务。这可能是为了明确的退款，或者仅仅是为了跟踪哪些单元导致了哪些类型的成本。一旦您想要单独跟踪公司中给定组织单元与其他组织的使用情况，它就应该有自己的存储库，并根据命名约定对其进行分解，以便于识别。

此外，一旦超出了业务能够成功协调命名约定和目录结构组织的范围，您至少必须拥有单独的存储库。也就是说，如果一个团队太大而无法在没有可怕的官僚流程的情况下成功地管理诸如组id /工件命名约定之类的东西，那么最好只是给它们单独的存储库，并且这种限制总是存在的规模。一般来说，写权限(甚至删除权限)应该合理地指定，以防止团队相互干扰工作。一般来说，删除权限应该只提供给基于策略的收割者之外的一个非常小的组(请参阅上面性能部分关于清理策略的讨论)。

考虑到所有这些因素，管理员通常倾向于更少的存储库。即使您的存储库管理过程自动化程度越高，它的重要性也就越小。例如，在强大的DevOps环境中，您最终可能会遇到这样的情况:每一个测试都可以被视为一次提升。虽然使用促进API对于每个测试，为几十个测试中的每一个都建立一个存储库可能是没有意义的，而是通过跟踪它属性，并为主要控制点保留单独的存储库

建议约定

下表总结了每种存储库类型的最佳实践命名约定和示例。

1.局部存储库

< projectKey /团队> - <科技> - <成熟度> - <定位器>

例子:

• rtfact-docker-dev-local(其中rtfact是Artifactory的项目密钥)
• tigerteam-docker-release-local

名称部分	建议
< projectKey /团队>	这是命名约定中最难的部分。它是基于您想要管理权限/性能/可操作性问题的粒度。 它也可以是一个产品名称，或者指向第三方库的源代码。 在JFrog项目中，它是项目存储库的唯一标识符。项目密钥作为前缀自动添加到项目中创建的资源中。2022世界杯阿根廷预选赛赛程
<技术>	内容类型。这通常是包类型，例如:mvn、rpm、docker。 它也可以是更具体的，比如centos或ubuntu。
<成熟度>	过程中的成熟度级别，无论是SDLC过程还是第三方工件的白名单/批准过程。 例如，以下系列: Scratch(用于开发人员从他们的系统中共享，例如docker) 开发(用于CI构建) QA(升级版本) 预产品(提升构建) Prod(用于提升的构建) 档案(为监管目的而保留的版本) 对于第三方库，它可能是这样的值: 上传 白名单 2018年1月(通常在快照远程存储库时使用)
<定位器>	基于物理位置/人工服务ID。对于实际写入的存储库，默认值是' local '，但在多推送复制的情况下，它可能是推送事件源的站点。 一般来说，除非通过复制，否则不应该写入没有“本地”指示符的存储库。

2.远程存储库

例子:

• tiger-mvn-release-boston
• rtfact-remote

存储库用例	建议
人工拓扑的一部分	要远程访问另一个人工服务器，请使用与本地存储库相同的命名约定，这取决于要远程访问的存储库。 在本例中，应该是远程工件的标识符。
中央存储库	< centralname >远程 " -remote "是可选的，但有助于避免与虚拟存储库命名约定混淆。 例如:jcenter-remote或者只是“jcenter”

3.虚拟存储库

< projectKey /团队> - <科技> <成熟度>

例子:

• rtfact-docker-dev
• tiger-docker-prod

名称部分	建议
< projectKey /团队>	共享读权限的组。 如果您使用虚拟写来控制写，那么您可以在写权限级别上控制它。
<技术>	包类型。
<成熟度>	这部分可以省略。但是，它通常用作写控制特性的一部分，或者专门用于生产。 与本地存储库中的<成熟度>不同，它更有可能从部署模型透视图而不是CI透视图进行控制。

结论

组织存储库和选择命名约定是JFrog Artifactory管理员需要做出的第一个也是最重要的决定之一。虽然良好地使用虚拟存储库可以允许以后进行更改，但最好事先选择一个命名约定。

本白皮书介绍了关于存储库组织和命名约定的各种注意事项，这些注意事项应该有助于您回答以下问题:“我需要多少个存储库?”它提供了一个由四部分组成的公约，< projectKey /团队> - <科技> - <成熟度> - <定位器>，它可以作为您的命名和组织结构的基本最佳实践指南。使用这个建议的约定，大多数组织问题变得相当清晰。

尽管团队粒度可能是一个挑战，但这种粒度通常是根据安全，性能和可操作性的担忧。虽然您可能需要随着时间的推移调整粒度，但是良好的命名约定与使用虚拟存储库相结合，可以使您的团队相对轻松地完成此过程。此外，您可以使用虚拟存储库别名来避免在继续进行构建时中断构建。

本白皮书中描述的约定将允许您跨全局拓扑扩展Artifactory。它将提供DevOps支持大型企业安装，为许多不同团队和项目的数千名开发人员提供服务。