GitLab vs JFrog:谁有正确的东西?
就像历史上的太空竞赛一样，插上DevOps旗帜的竞争也在迅速展开，这对社区来说是一个激动人心的时刻。根据市场情报公司IDC的数据，全球企业将在数字化转型上投资6.8万亿美元到2023年。然而，研究也表明70%的人无法实现他们的目标，这是由于低效的协作和跨团队协作。
正如当今许多F1000级公司和开发组织告诉我们的那样，规模化是DevOps面临的下一个巨大挑战——如果人员和工具不能很好地协同工作，就无法实现规模化。正如所有代码回购公司所建议的那样，GitLab自己也指出:“[组织]希望更快的周期时间、更高的效率和更低的风险。”这一点在现代世界中越来越明显，有时每天都要多次构建和发布软件，需要跨公司的可伸缩、安全、灵活的工具DevOps满足需求的基础设施。
这意味着必须解决软件生命周期的所有方面，以满足今天和明天的需求。代码管理系统，包管理，持续安全软件分发必须是集成的，高度可伸缩的，并完全同步工作，以驱动转型。在JFrog，我们的许多客户正在实现这一点:将他们选择的风险投资工具(如GitHub, GitLab, Atlassian和其他)与二元管理和软件交付专业知识JFrog平台提供了。
但是由于JFrog和GitLab都标榜着“DevOps平台”的标签，让我们来看看如何快速、安全、无畏地完成DevOps工作，将软件推向市场。
平台或组合
GitLab是一个优秀的风投平台——甚至我们JFrog的一些开发人员也会用它来证明这一点。GitLab的专业知识在最左边软件开发生命周期(SDLC)帮助他们开发了创新功能——比如代码库项目-支持设计和编码。
通过一个独特的透明的开源开发模型，GitLab已经迅速扩展了它的订阅，包括帮助自动化SDLC的一些右向任务的工具，例如CI / CD，包管理、静态测试、动态测试等等。
成熟吗?
虽然范围令人印象深刻，但GitLab的大部分产品目前还远远不够成熟。在向右的40多个项目中，与源代码或CI/CD无关GitLab的成熟度图，只有3个是“完整的”。剩下的近一半仍然是“最小的”。
统一的吗?
GitLab套件提供了一个通用的用户界面，他们强调的核心价值是，除非可以通过UI进行控制，否则任何特性都不被认为是完整的。
虽然这提供了一个统一平台的外观，但它掩盖了一个事实，即许多GitLab工具并没有真正地相互集成。在UX背后，很少有部件能够顺利地进行互操作——通常甚至不共享一个公共元数据模型。即使DevOps试图打破竖井，许多GitLab的DevOps和DevSecOps解决方案仍然彼此隔离。
愿景?
成功的DevOps不是来自一次解决一个单独的问题。成功来自于应用正确的方法，这些方法已经被数百个其他组织证明有效。你的DevOps的工具需要启用帮助您加速高质量软件发布的最佳实践并将它们安全地传输到客户的桌面和设备上。
虽然GitLab试图为DevOps提供端到端工具，但他们并没有为DevOps的成功提供端到端方法。
说到DevOps，投资组合不是一个平台．我们在DevOps方面的长期经验表明，数字转换的成功在于管理二进制文件，而不仅仅是代码。
正确的内容:开发vs交付
我们数以千计的成功客户证明了一个事实:获得DevOps的成功完全取决于你的二进制文件。
软件发展是关于源代码的，而高质量的代码来自于那些知道如何编写代码的聪明人。
软件交付是关于二进制文件的——确保高质量的构建，并将它们快速地导入到客户的设备中。高质量的二进制文件来自知道如何管理和分发它们的智能系统。
作为领先VCS的供应商，GitLab在使软件开发人员能够创建和管理源代码的必要任务方面是专家。但是DevOps的目标是实现交付开发人员以最高速度发布的高质量版本。
以二进制文件为中心的方法——JFrog的专长——是成功实现现代组织软件生命周期自动化的唯一方法，可以确保信任和交付速度。
要做到这一点，你需要达到这些关键的里程碑:
释放的速度
加速发布需要一个加速的二进制工作流程来创建信任。
| JFrog | GitLab | |
|---|---|---|
| 包类型 | 30 + | 11 + |
| 代理存储库缓存 | ✅ | 仅Docker Hub |
| 自动化:本机集成CI/CD | ✅ | ✅ |
| 为SBOM和可追溯性构建元数据 | ✅ | X |
| 为发布阶段构建推广 | ✅ | X |
| 高级查询语言 | ✅ | X |
| 分布解决方案 | ✅ | X |
包类型
JFrog内部数据显示，平均来说，一个Artifactory安装维护至少7种不同包类型的存储库。企业级用户的需求甚至更多，其中一半用户使用12种或更多的包类型。
通过这些措施，GitLab目前对11种包类型的本地存储库支持提供了一个坚实的开端——尽管远远少于超过30种包装类型由Artifactory本土支持。像Artifactory一样，GItLab也提供了一个通用回购类型，使用户能够集中管理作为其发行版一部分的其他文件类型，如图像、zip文件、文档等等。
| 语言或操作系统 | JFrog Artifactory(部分) | GitLab包注册表(完整) |
|---|---|---|
| Java | Apache Maven | Apache Maven |
| Java | Gradle | Gradle |
| Javascript | npm /纱 | npm /纱 |
| Javascript | 鲍尔 | |
| Python | 皮普/线 | 皮普/线 |
| net | Nuget | Nuget |
| Golang | 去模块 | 去模块 |
| 码头工人 | 码头工人 | 码头工人 |
| 舵 | 执掌图表 | - * |
| C / c++ | 柯南 | 柯南 |
| iOS | CocoaPods | |
| PHP | PHP的作曲家 | PHP的作曲家 |
| Ruby | RubyGems | RubyGems |
| 生锈 | 货物 | |
| Linux,百胜 | RPM | |
| GNU Linux | Debian | |
| Hashicorp | 起程拓殖(很快) | 起程拓殖 |
＊使用Helm v3, GitLab用户可以使用容器注册表来存储Helm图表。然而，由于Docker传递和存储元数据的方式，GitLab不可能解析这些数据并满足性能标准。
代理存储库缓存
超过92%的应用程序使用来自公共存储库的开源代码，这通常代表每个应用程序中60-90%的代码。
Artifactory的远程存储库允许您在代理回购中缓存那些开源包，强制版本不可变性，提供本地速度并确保防止任何连接中断。您可以在逻辑上将它们与本地Artifactory repo组合为一个单一的虚拟存储库，为开发人员和管理员管理可以访问的内容提供便利。
GitLab的依赖代理提供了类似的功能——但目前仅对容器注册表可用，而且仅对代理可用码头工人中心．
为SBOM和可追溯性构建元数据
应用程序的每一个构建都由许许多多工件(软件的构建块)组成，从您的包和配置文件到作为应用程序可部署运行时组件的二进制文件。
当你实现了每天多个构建的DevOps目标时，它会迅速累积起来。我们的企业客户各维护一个平均2000万件独特的文物，每年增加130%．
Artifactory存储扩展元数据——我们称之为“构建信息”——与您从任何构建工具进行的每个构建一起，链接到您的开源和专有依赖的包元数据，以及构建工件和环境设置。通过详细的构建信息，您可以跟踪每个可部署二进制文件的来源，以及它为服务而部署的每个地方。
您的构建信息也是软件材料清单(SBOM)的基础，这是一份机器可读的清单，详细描述了应用程序中包含的所有项目及其来源，适用于每个投入生产或交付给客户的版本。随着越来越多的政府和受监管的行业需要SBOM来帮助对抗网络攻击，Artifactory是您的快速交钥匙解决方案。
GitLab没有与Artifactory的构建信息类似的功能．GitLab CI/CD提供了一些类似于他们称之为“构建”的东西部署．这使您能够使用源代码存储构建事件的记录，以及它曾经(或者对于手动部署，将会)部署的位置。但是，此数据描述的是事件，而不是部署的二进制文件，并且不包括生成SBOM或复制确定性构建所需的任何元数据。此外，由于是GitLab CI/CD的独家特性，这种跟踪机制不能扩展到您的遗留CI/CD管道，例如Jenkins。
而不是元数据，GitLab的依赖列表函数只与依赖项扫描工具一起工作，通过解析GitLab VCS中的源来生成依赖项数据。因此,GitLab不能从可部署二进制文件生成绝对可靠的SBOM-他们只能重建本来的样子可能在你的二进制中，从源代码中推断出来。
构建推广和发布阶段
每个新的软件版本都必须通过SDLC中的几个质量检验关。但什么通过这些大门将决定玩家是快速还是缓慢地释放游戏。
Artifactory使建立促销，其中一个不可变的二进制文件贯穿整个SDLC。使用每个SDLC阶段的存储库，只需将其元数据转移到下一个回购，就可以促进构建。
在这种“构建一次并升级”的方法中，相同的构建在每个阶段都要进行评估，确保DevOps管道的绝对一致性。一旦不需要执行自己的确定性构建，团队就可以利用恢复的时间进行更详尽的测试并更快地交付反馈。
构建提升是内置在Artifactory的DNA中——一个简单的API操作就可以将一个构建从一个回购提升到下一个回购，而Artifactory基于校验和的存储可以保证给定的构建及其元数据在存储的所有回购中都是相同的。
虽然GitLab为通用工件提供了回购，如发布二进制文件和Docker映像的容器注册表，GitLab根本不提供构建升级的内置支持．虽然GitLab CI/CD支持在GitLab项目中记录部署到已定义环境的情况，但此特性不能与其他自动化工具一起使用。
分布解决方案
通过JFrog云存储库，您可以通过Amazon的CloudFront CDN解决方案在多个位置分发大量软件。JFrog发行版提供了企业就绪的解决方案，用于安全交付经过验证的应用程序和更新到服务器、桌面和设备，在那里它们可以投入使用。从Artifactory存储库中的二进制文件中，创建已签名的发布包，以便交付到Artifactory边缘节点。
GitLab根本不提供分发解决方案，这与他们宣称的端到端DevOps平台相去甚远。
连接和自动化
为了做到多用途，你的DevOps平台需要能够支持你的开发团队使用的所有技术，以便与你需要的工具无缝融合。
| JFrog | GitLab | |
|---|---|---|
| CI / CD自动化 | ✅ | ✅ |
| 预构建(本机)步骤和扩展 | ✅ | X |
| 模板 | ✅ | ✅ |
| 简单的CI/CD创建 | ✅ | ✅ |
| 条件执行和复杂管道 | ✅ | ✅ |
| 管道编辑器 | X | ✅ |
| 签署了管道 | ✅ | X |
| Linux构建 | ✅ | ✅ |
| Windows Server Build | ✅ | 部分 |
| 自动伸缩构建基础设施支持 | 3. | 2 |
| REST api | ✅ | ✅ |
CI / CD自动化
就像他们提供源代码的VCS一样，GitLab的CI/CD是成熟的并且被广泛使用。GitLab管道是通过YAML中的描述创建的，开发人员可以在YAML中定义管道阶段和操作。
类似地，JFrog管线也使用YAML来定义管线。但有一些重要的区别:
- 本机的步骤
虽然GitLab的CI/CD与GitLab源代码库紧密集成，但每个用于构建、测试和部署的工具都必须通过shell脚本中各自的命令行接口调用。
JFrog管线自然地集成了JFrog平台的所有关键任务部分——不仅仅是Artifactory，还有Xray和Distribution。管道的本机步骤通过启用许多常见操作(例如码头工人形象通过声明性YAML中定义的预构建步骤来实现构建、安全扫描或发布捆绑)。
管道本机步骤可以与通用步骤混合使用以执行shell命令，或者通过创建您自己的管道扩展进行扩展，这些扩展可以隐藏低层次的复杂性，并在团队、部门或组织之间共享。
- 简单的CI/CD创建
GitLab的Auto DevOps特性通过基于源代码自动设置管道和集成来帮助您开始使用CI。JFrog pipeline通过声明式本机步骤和自定义扩展显著降低了复杂性，因此您可以专注于想要完成什么，而不是如何完成它。此外，您可以快速开始创建CI/CD管道的模板为常见操作快速创建管道。我们提供了一些内置的，您可以添加自己的，以帮助确保您的团队遵循最佳的CI/CD实践。
- 复杂的管道
GitLab的父-子管道使管道的行为更加动态，可以根据另一个子管道的结果自动选择启动(或不启动)子管道。
类似地，在管道中，任何管道或步骤都可以配置为触发在各种事件中，包括成功完成另一个管道的输出，或人员控制的审批门。管道的图形视图提供所有相互连接的管道和资源(您的“管道中的管道”)的组合实时状态视图，以了解它们之间的依赖关系。2022世界杯阿根廷预选赛赛程
- 签署了管道
作为统一的JFrog平台的一部分，管线创建了一个类似区块链的加密签名账本对于管道的每一次运行。它还将增强的元数据添加到构建和发布包中，包括到生成元数据的运行的链接。然后，如果构建/发布包不能被验证为由链接运行创建，客户可以阻止下游操作，如构建推广、发布包创建、部署等等。这种“零信任”方法通过保证包的真实性和使管道防篡改提供了额外的安全层。
api、CLI和集成
GitLab和JFrog都提供REST api启用集成。回顾一下它们——我们认为您会发现JFrog为多功能自动化提供了更全面的集合。
JFrog CLI提供了一种从命令行访问Artifactory存储库或从shell脚本自动化的现成方法。GitLab的订阅根本不提供CLI。
GitLab CI/CD与GitLab源代码控制存储库紧密耦合。虽然JFrog平台提供了端到端DevOps管道，你也可以在CI/CD工具中使用Artifactory你可能更喜欢——无论是Jenkins、CircleCI，还是GitLab CI/CD。JFrog提供了一些开箱即用的集成，或者从一大堆技术合作伙伴集成中进行选择。
保护您的业务
练习强DevSecOps意味着拥有最好的风险数据，并能够解释结果，以保持安全和法规合规性。它还意味着使软件生产过程中的每个人都能意识到安全性。
| JFrog | GitLab | |
|---|---|---|
| 软件组合分析(SCA)扫描 | ✅ | 有限的 |
| 集装箱扫描 | ✅ | 有限的 |
| 许可遵从性 | ✅ | ✅ |
| 自动执行策略 | ✅ | X |
| 影响分析 | ✅ | X |
| IDE集成到左移安全性 | ✅ | X |
SCA扫描
GitLab依赖扫描该工具与GitLab源代码控制存储库和GitLab CI/CD紧密集成(且只能使用)，用于识别源代码中脆弱的开源依赖引用。它从CI/CD管道中扫描源代码;关于发现的漏洞及其严重程度的信息将在合并请求中报告，因此开发人员可以采取行动进行补救。GitLab确实不在GitLab包注册表扫描包。
JFrog Xray对您的包和二进制文件执行深度递归SCA扫描，利用您的Artifactory元数据直接从构建中识别开源组件。这提供了更大的确定性、持续的警惕性和能力标记已经部署的二进制文件中的零日漏洞．
为了提高左移安全性，开发人员还可以调用Xray来扫描本地目录中源代码中的依赖项，使他们能够在将代码提交到分支之前进行补救。
集装箱扫描
GitLab容器扫描使用GitLab 14.0版的开源Trivy引擎。容器扫描为目前未集成进入GitLab容器注册流程- Docker映像只能通过GitLab CI/CD中的单独作业进行扫描。推送到注册表的图像不会自动扫描。
JFrog Xray可以配置为连续扫描注册表中的Docker映像(包括oci兼容的映像和谷歌disroless映像)以查找漏洞和许可证策略违规，就像它可以支持任何18种包类型Xray一样。
自动执行策略
GitLab的依赖扫描、容器扫描、许可证遵从性和其他安全工具都提供了必须由人工操作员阅读、评估和执行的报告——这是一组高摩擦的手动步骤，阻碍了软件的快速交付。
JFrog x射线SCA工具授权安全团队配置规则和策略针对漏洞严重程度和许可证冲突设置自动手表检测违规行为并在扫描后执行这些策略。通过JFrog合作伙伴集成，您还可以通过分析工具报告违规行为，例如Splunk或DataDog，或将事故报告通知各小组PagerDuty,松＊，或MS-Teams。＊
＊目前处于测试阶段
影响分析
JFrog Xray通过影响图揭示了对整个二进制生态系统的风险影响，该影响图显示了构建清单中任何漏洞或策略违反的全部范围。GitLab没有提供类似的设施。
IDE集成
任何一个流行ide的x射线插件，你可以左移安全开发人员的意识，甚至在代码提交之前标记和补救OSS依赖中的漏洞。
如上所述，GitLab依赖项扫描是通过GitLab CI/CD驱动的。GitLab目前没有可用的IDE插件。
缩放到无穷大
你的生意不能停滞不前;它必须能够抓住每一个全球增长的机会。没有限制，无论你从哪里开始，你的工具必须跟上。您的关键路径操作必须满足您今天的需求，但也要使业务敏捷性能够不间断地满足您明天的需求。
| JFrog | GitLab | |
|---|---|---|
| 可扩展的高可用性 | ✅ | ✅ |
| 区域Geo-Replication | ✅ | 有限的 |
| Multicloud提供 | ✅ | X |
| 混合解决方案 | ✅ | 有限的 |
| 用户数不限 | ✅ | X |
| 专用配电网 | ✅ | X |
可扩展的高可用性
同时支持GitLab和JFrog高可用性(HA，也称为“集群”)部署，使用多个负载平衡的实例来帮助确保快速响应时间，同时在执行升级时启用故障转移保护和零停机时间。
区域Geo-Replication
GitLab地理通过从单个主GitLab站点到只读辅助站点的单向镜像，支持有限的站点复制。我们认为这不足以支持全球开发团队协作的方式。
JFrog平台支持多种复制拓扑，最容易通过联合存储库，这是一种创新的双向镜像技术，它使地理上分布的团队能够集体生产并共享带有元数据的工件。在每个联合存储库中，对一个站点上的构件或存储库配置所做的更改将自动同步到其他成员站点(最多10个)。
多云和混合
GitLab在单一云平台上托管所有云(SaaS)服务，美国的GCP,使多重云冗余是不可能的。尽管GitLab同时提供SaaS服务和自管理安装选项，但它们是分开的，用户不能在它们之间或跨它们工作。
JFrog Cloud (SaaS)可用于在所有主要云提供商上管理托管(AWS、GCP和Azure)，使您能够选择您的云平台或维护多个多云策略。JFrog平台的所有订阅级别(专业版、团队版、企业版、企业版+版)均可用于自托管或内部部署，并可与任何JFrog云帐户结合使用，通过存储库地理复制构建企业级混合系统。
无限的用户
当你的授权费用是基于用户帐号的数量时，这便会显著增加扩展或收购的费用。有了JFrog的无限用户授权，这就不是你需要考虑的事情;添加尽可能多的用户帐户，您的安装实际上可以支持，没有额外的成本。
专用配电网
您可以将发布从Artifactory单一真实源分发到Artifactory边缘节点，这些节点可以连接到一个多节点拓扑结构中，以形成一个安全、高速、横跨全球的专用分发网络(PDN)。通过JFrog创新的点对点网络技术，您可以克服糟糕的网络连接、延迟和跨境障碍，以最快的速度在全球安全地交付大型签名发布包。
如上所述，GitLab不提供交付或分发解决方案。
一旦你向前一跃，你就不会回头
从许多依赖GitLab进行源代码管理的组织来看，GitLab作为vc和项目经理的优势是显而易见的。事实上，JFrog的许多客户都这样做，他们使用JFrog的通用CLI和api与他们选择的CI/CD集成，无论是GitLab、Jenkins还是其他工具。在GitLab最近提交的S-1表格中，超过一半的客户也是JFrog的客户!
凭借其广泛的工具组合，GitLab的产品要求您将最佳工具链替换为来自单一供应商的工具链。但除非卖家能给你提供更好的成功机会，否则这是一笔有风险的交易。
在JFrog，我们的使命很简单:通过提供最好的解决方案来快速、安全、持续地发布版本，让每个软件开发者都获得成功。
根据他们的说法，GitLab的野心当然很大使命宣言．“未来30年，我们的BHAG将成为各行业知识工作者最受欢迎的协作工具。”
为什么要等三十年呢?JFrog DevOps平台由业界最流行的二进制文件管理工具提供支持，今天就可以使用免费开始！
