Ruby需要一个成熟的二进制存储库吗?
在某个时间点，Ruby开发人员意识到需要在专用网络中提供宝石。主要原因:
- 你不能依赖在RubyGems.org
- 你需要一个存放宝石的地方，在RubyGems中是不可用的。那些可以有两种口味:
- 某物没有举办在RubyGems。例如,流浪的．
- 一些内部的东西(既不是开源的也不是公共）;你想和你的同事分享，但作为宝石而不是来源。
那么问题来了——这些宝石可以存放在哪里呢?自然答:Git（集线器)或任何其他源代码控制。所以…
源代码控制是共享文件的方式，对吧?不，它不是。
当然，源代码控制工作得很好的来源-我们已经用了很久了。但是宝石不是源文件，它们是二进制文件。源码控制是针对源码的。那又怎样?为什么不合身?一些原因包括:- 首先，也是最重要的一个版本控制系统(VCS)不是一个gem存储库!它不能计算服务器上的索引，也不支持任何动态REST API，比如Bundler使用的依赖解析API(这使得解析速度更快)。
- 版本控制不匹配。源文件为版本化通过他们的内容。人来说知道如何区分它们，并了解发生了什么变化。另一方面，二进制通常是版本化用他们的名字。从VCS的角度来看，它们是不同的条目，每个条目都没有任何版本历史记录。
- 一些非常流行的vcs(如Subversion)不能删除文件。这意味着，一旦添加了一个文件，它将永远留在存储库中。对于小的源文件来说，这不是一个大问题，但当涉及到过时的大型二进制文件时，就会变得相当麻烦。
- 源代码控制知道如何搜索源代码。当然，最重要的搜索类型是内容搜索。然而，搜索二进制文件是不同的:最重要的是文件元数据、位置、文件名的结构，如果是存档工件，则是存档的内容。
- 的权限为客户量身定制的风险服务中心方案版本控制来源(再一次)。例如，没有覆盖权限。这是因为重写源文件是我们在VCS中一直在做的事情——这与添加一个新的源文件具有相同的安全级别。然而，二进制文件的情况就大不相同了。虽然添加新的二进制文件是可以的，但重写已发布的二进制文件是不应该做的(应该有一个特殊的许可为它)。
- 分布式vcs(是的，Git，我在看着你!)它们本身就很棒，但尤其不适合处理大的二进制文件．当将远程存储库克隆到您的计算机时，您将带来其文件的所有历史记录．现在想想那些巨大的二进制文件……
到目前为止，您应该已经确信源代码控制不是二进制文件的好地方。我们真正需要的是一个可安装的RubyGems服务器!你猜怎么着?这里有几个选项:
去找一个RubyGems服务器吧
- 宝石在盒子里是一个Sinatra应用程序，它提供了一个宝石服务器。这很好，但有点幼稚:没有内置的身份验证，没有授权，没有存储库分离，也没有其他服务器(如RubyGems.org)代理。
- GemFury是一个非常基本的、基于订阅的云托管gems服务器。你得到一个私有的存储库，用一个模糊的URL保护。同样，这里是非常基本的东西——没有RubyGems.org的代理(或其他任何代理)回购)，没有协作者的身份验证模型，也没有存储库的虚拟聚合(以防有多个存储库)。
我能说什么呢?当涉及到管理二进制文件时，Ruby世界并不是非常复杂——这没关系(毕竟，Ruby是关于源代码的，通常是开源的)。但是Ruby社区可以从“黑暗的Java企业”方面借鉴一些东西——适当的二进制存储库。我们可以提供一个…
欢迎来到黑暗的一面，看到光明。与Artifactory见面，有RubyGems支持:
让我们从基础开始。二进制存储库有两个主要目标:
- 远程RubyGems存储库代理。首先，RubyGems.org;但也任何GemFury, Gem in a Box等实例。出在那里。这些被称为“远程存储库”。
- 宝石的部署目标。任何你不想放在RubyGems.org上的东西，任何你需要但其他存储库没有的东西。这些被称为“本地存储库”。
除此之外，我们还要加上:
- 虚拟存储库在单个URL下聚合任意数量的远程、本地和虚拟存储库。
- 认证和授权允许控制每个用户和/或组对存储库的权限的方案，包括与外部授权服务的集成。
- 搜索和浏览托管和远程宝石。
- REST API与信息，搜索，依赖列表和Yank命令。
- 强大的用户插件框架．
你可以把所有这些优点都安装上去您的服务器还是在云中与Artifactory在线，在那里JFrog将照看它，升级它，并保持它运行。
如何开始使用支持RubyGems的Artifactory ?简单!完整的文档可以在我们的用户指南中找到:
