在上篇文章中，我们已经建立了基本的仓库命名结构，在 JFrog Artifactory 中，仓库管理的最佳实践应该考虑三个因素：安全性，性能和可操作性。大多数情况下，这些因素跟你的团队规模密切相关，在较小程度上跟仓库成熟度等级的粒度划分有一定的关系。
Artifactory 仓库架构和命名最佳实践（下）
在上篇文章中，我们已经建立了基本的仓库命名结构，在 JFrog 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 平台建设，为众多不同团队和项目的数千名开发人员提供服务。
原文地址：http://blog.51cto.com/jfrogchina/2120997
时间： 2024-08-02 21:51:58
Artifactory 仓库架构和命名最佳实践（下）的相关文章
自己总结的C#编码规范--3.特定场景下的命名最佳实践
特定场景下的命名最佳实践 命名空间 要使用PascalCasing,并用点号来分隔名字空间中的各个部分. 如Microsof.Office.PowerPoint 要用公司名作为命名空间的前缀,这样就可以避免与另外一家公司使用相同的名字. 要用稳定的,与版本无关的产品名称作为命名空间的第二层 不要使用公司的组织架构来决定命名空间的层次结构,因为内部组织结构经常改变. 不要用相同的名字来命名命名空间和该空间内的类型. 例如,不要先将命名空间命名为Debug,然后又在该空间中提供Debug类.大部分编
python高级编程之选择好名称:pepe8和命名最佳实践
# # -*- coding: utf-8 -*- # # python:2.x # __author__ = 'Administrator' # my_list=['a','b','c','d'] # """ # 大部分标准程序加在构建时都不会忽略可用性,看下面的例子理解下这句话的含义 # """ # if 'e' not in my_list: # my_list.append('e') # print my_list # #['a'
Atitit. 软件设计 模式 变量 方法 命名最佳实践 vp820 attilax总结命名表大全
Atitit. 软件设计 模式 变量 方法 命名最佳实践 vp820 attilax总结命名表大全 1. #====提升抽象层次 1 2. #----使用通用单词 1 3. #===使用术语.. 1 4. #===使用缩写 2 5. #====自己最孰的语言(diaglog??) 2 6. 2 7. #====normal naming + anno 2 8. #----jsp页面的名称,最好不个mod_list.jsp 2 9. 名词优先与动词 2 10. 变量的常用前缀 2 11. 常用命
【Spring Cloud】Spring Cloud之整合Spring Cloud Bus以及最佳实践
一.整合步骤 1)加入Maven坐标 <!-- actuator监控模块 --> <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-actuator</artifactId> <version>2.0.3.RELEASE</version> </dependency> &l
分布式服务框架下，如何做到服务化最佳实践？
“升级服务框架后,性能.可靠性等问题日益明显.服务化之后面临的诸多挑战,怎样分析才能给出实践最优解? 在服务化之前,业务通常都是本地API调用,本地方法调用性能损耗较小.服务化之后,服务提供者和消费者之间采用远程网络通信,增加了额外的性能损耗,业务调用的时延将增大,同时由于网络闪断等原因,分布式调用失败的风险也增大.如果服务框架没有足够的容错能力,业务失败率将会大幅提升. 除了性能.可靠性等问题,跨节点的事务一致性问题.分布式调用带来的故障定界困难.海量微服务运维成本增加等也是分布式服务框架必须
App 后台架构设计方案 设计思想与最佳实践
转载请注明出处:http://blog.csdn.net/smartbetter/article/details/53933096 做App做的久了,就想研究一下与之相关的App后台,发现也是蛮有趣的.App后台的两个重要作用就是 远程存储数据 和 消息中转.这里面的知识体系也是相当复杂,做好一个App后台也是需要长期锤炼的.本篇文章从 App 后台架构 的角度介绍.好了,下面进入正题: 说起架构,我们先看一下何为架构,百度百科是这样说的:架构,又名软件架构,是有关软件整体结构与组件的抽象描述,
读生产环境下go语言最佳实践有感
最近看了一篇关于go产品开发最佳实践的文章,go-in-procution.作者总结了他们在用go开发过程中的很多实际经验,我们很多其实也用到了,鉴于此,这里就简单的写写读后感,后续我也争取能将这篇文章翻译出来.后面我用soundcloud来指代原作者. 开发环境 在soundcloud,每个人使用一个独立的GOPATH,并且在GOPATH直接按照go规定的代码路径方式clone代码. $ mkdir -p $GOPATH/src/github.com/soundcloud $ cd $GOPA
基于AWS的云服务架构最佳实践
ZZ from: http://blog.csdn.net/wireless_com/article/details/43305701 近年来,对于打造高度可扩展的应用程序,软件架构师们挖掘了若干相关理念,并以最佳实践的方式加以实施.在今天的"信息时代",这些理念更加适用于不断增长的数据集,不可预知的流量模式,以及快速响应时间的需求.本文将强调并重申其中的一些传统观念,并讨论他们如何在融合云计算的发展,还将讨论由于云计算的动态性而产生的一些前所未有的概念(如弹性). 本文的目标是面向云
Cocos2d-x下Lua调用自定义C++类和函数的最佳实践
原文地址:http://segmentfault.com/a/1190000000631630 关于cocos2d-x下Lua调用C++的文档看了不少,但没有一篇真正把这事给讲明白了,我自己也是个初学者,摸索了半天,总结如下: cocos2d-x下Lua调用C++这事之所以看起来这么复杂.网上所有的文档都没讲清楚,是因为存在5个层面的知识点: 1.在纯C环境下,把C函数注册进Lua环境,理解Lua和C之间可以互相调用的本质2.在cocos2d-x项目里,把纯C函数注册进Lua环境,理解cocos