GitLab vs JFrog:谁有正确的东西?
就像历史上的太空竞赛一样，为DevOps插上旗帜的竞争正在迅速展开，这对社区来说是一个激动人心的时刻。根据市场情报公司IDC的数据，全球企业将在数字化转型上投资6.8万亿美元到2023年。然而，研究也表明70%的人将无法实现他们的目标，因为低效的协作和跨团队的合作。
正如当今许多F1000公司和开发组织告诉我们的那样，规模是DevOps面临的下一个巨大挑战——如果人员和工具不能很好地协同工作，你就无法实现规模。正如所有代码回购公司和GitLab自己指出的那样:“[组织]想要更快的周期时间，提高效率，降低风险。”这在现代世界中越来越明显，有时每天构建和发布多次软件，需要跨公司的可伸缩、安全、灵活的工具DevOps满足需求的基础设施。
这意味着为了满足今天和明天的需求，必须处理软件生命周期的所有方面。代码管理系统，包管理，持续安全和软件分发必须集成，高度可扩展，并完全同步工作，以驱动转型。在JFrog这里，我们的许多客户正在实现这一点:将他们选择的风投工具(如GitHub, GitLab, Atlassian等)与世界杯2022赛程时间表 和软件交付专业知识JFrog平台提供了。
但是由于JFrog和GitLab都打着“DevOps平台”的标签，让我们来看看如何快速、安全、无畏地完成DevOps工作，将软件推向市场。
平台或组合
GitLab是一个优秀的风投平台——甚至我们JFrog的一些使用过它的开发人员也会证明这一点。GitLab的专业知识在最左边软件开发生命周期(SDLC)帮助他们创造了创新功能——比如代码库项目-支持设计和编码。
通过一种独特透明的、开源的开发模型，GitLab已经迅速扩展了它的订阅，包括帮助自动完成SDLC的一些正确任务的工具，例如2022世界杯预选赛 ，包管理、静态测试、动态测试等等。
成熟吗?
尽管GitLab的产品范围令人印象深刻，但大多数产品目前还远远不够成熟。在40多个右边的项目中，与源代码或CI/CD无关GitLab的成熟度图表，只有3个是“完整的”。剩下的近一半仍然是“最少的”。
统一的吗?
GitLab套件提供了一个通用的用户界面，他们强调一个核心价值，那就是只有通过UI才能控制的特性才算完整。
虽然这提供了一个统一平台的外观，但它掩盖了一个事实，即许多GitLab工具并没有真正地相互集成。在用户体验的幕后，很少有部件能够顺利地互操作——通常甚至不共享一个公共元数据模型。即使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回购结合起来，作为一个单一的虚拟存储库，为开发人员提供方便，并由管理员管理可以访问的内容。
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 Distribution为安全交付经过验证的应用程序和更新到服务器、桌面和设备提供了企业准备的解决方案。从Artifactory存储库中的二进制文件中，创建已签名的发布包，以交付到Artifactory边缘节点。
GitLab根本没有提供分发解决方案，这与他们宣称的端到端DevOps平台相去甚远。
连接和自动化
要做到全能，你的DevOps平台需要能够支持你的开发团队使用的所有技术，并与你需要的工具无缝融合。
| JFrog | GitLab | |
|---|---|---|
| CI / CD自动化 | ✅ | ✅ |
| 预构建(本机)步骤和扩展 | ✅ | X |
| 模板 | ✅ | ✅ |
| 简单的CI/CD创建 | ✅ | ✅ |
| 条件执行和复杂管道 | ✅ | ✅ |
| 管道编辑器 | X | ✅ |
| 签署了管道 | ✅ | X |
| Linux构建 | ✅ | ✅ |
| Windows Server构建 | ✅ | 部分 |
| 自动伸缩构建基础设施支持 | 3. | 2 |
| REST api | ✅ | ✅ |
CI / CD自动化
就像vc提供的源代码一样，GitLab的CI/CD也非常成熟并得到了广泛的应用。GitLab管道是通过YAML中的描述创建的，开发人员可以在YAML中定义管道阶段和操作。
类似地，JFrog pipeline也使用YAML定义管道。但有一些重要的区别:
- 本机的步骤
虽然GitLab的CI/CD与GitLab源代码库紧密集成，但每个用于构建、测试和部署的工具都必须在shell脚本中通过各自的命令行接口调用。
JFrog pipeline自然地与JFrog平台的所有关键任务部分集成在一起——不仅仅是Artifactory，还有Xray和Distribution。管道的本机步骤通过启用许多通用操作(例如码头工人形象通过声明性YAML中定义的预构建步骤来实现构建、安全扫描或发布捆绑)。
管道原生步骤可以与通用步骤混合使用，以执行shell命令，或者通过创建自己的pipeline Extensions进行扩展，这些Extensions可以隐藏底层的复杂性，并在团队、部门或组织之间共享。
- 简单的CI/CD创建
GitLab的自动DevOps特性可以根据源代码自动为您设置管道和集成，从而帮助您开始使用CI。JFrog pipeline通过声明式本机步骤和自定义扩展显著降低了复杂性，因此您可以专注于您想要做什么，而不是如何完成它。此外，您还可以使用管道的模板为常见操作快速创建管道。我们提供了几个内置的，您可以添加您自己的，以帮助确保您的团队遵循最佳CI/CD实践。
- 复杂的管道
GitLab的父-子管道使管道的行为更加动态，根据另一个管道的结果自动选择启动(或不启动)子管道。
类似地，在pipeline中，任何管道或步骤都可以是配置为触发在各种事件上，包括成功完成另一条管道的输出，或人员控制的审批门。管道的图形视图提供了所有相互连接的管道和资源(您的“管道中的管道”)的组合的实时状态视图，以了解它们之间的依赖关系。2022世界杯阿根廷预选赛赛程
- 签署了管道
作为统一JFrog平台的一部分，pipes创建了一个类似区块链的加密签名账本对于管道的每次运行。它还将增强的元数据添加到构建和发布包中，包括到生成它的运行的链接。如果构建/发布包不能被链接运行所创建，客户就可以阻止下游操作，如构建推广、发布包创建、部署等。这种“零信任”方法通过保证包的真实性和使管道防篡改提供了额外的安全层。
api、CLI和集成
GitLab和JFrog各自提供REST api启用集成。回顾一下它们——我们认为您会发现JFrog为多功能自动化提供了更全面的集合。
JFrog CLI提供了一种从命令行访问Artifactory存储库或从shell脚本实现自动化的现成方法。GitLab的订阅完全不提供CLI。
GitLab CI/CD与GitLab源代码控制库紧密耦合。虽然JFrog平台提供了端到端的管道DevOps，你也可以使用Artifactory与CI/CD工具你可能更喜欢——无论是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引擎。集装箱扫描为目前尚未整合Docker映像只能通过GitLab CI/CD中的单独作业进行扫描。推送到注册表的图像不会自动扫描。
JFrog Xray可以配置为连续扫描注册表中的Docker映像(包括符合oci的映像和谷歌disroless映像)，以查找漏洞和许可证策略违反，就像它可以扫描Xray支持的18种包类型中的任何一种一样。
自动执行策略
GitLab的依赖性扫描、容器扫描、许可证遵从和其他安全工具都提供了必须由操作员阅读、评估和操作的报告——这是一组高摩擦的手动步骤，阻碍了软件的快速交付。
JFrog Xray SCA工具授权安全团队配置规则和策略对于漏洞严重程度和许可证冲突，和设置自动手表检测违规行为并在扫描后执行这些策略。通过JFrog合作伙伴集成，您还可以通过分析工具报告违规情况，例如Splunk或DataDog，或通过事件报告通知团队PagerDuty,松*，或者MS-Teams。*
*目前处于测试阶段
影响分析
JFrog Xray通过影响图揭示了对整个二进制生态系统的风险影响，这些影响图显示了构建清单中任何漏洞或策略违反的全部范围。GitLab没有提供类似的设施。
IDE集成
任何一个流行ide的Xray插件，你可以左移安全提醒开发人员，甚至在代码提交之前就标记和修复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云(SaaS)可用于对所有主要云提供商的托管进行管理(AWS、GCP和Azure)，使您能够选择自己的云平台，或维护多个云平台以实现多云策略。JFrog平台的所有订阅级别(专业版、团队版、企业版、企业版)均可自托管或就地托管，并可与任何JFrog云帐户结合，通过存储库地理复制构建企业级混合系统。
无限的用户
当你的授权费用是基于用户帐号的数量时，这便会显著增加扩展或收购的费用。有了JFrog的无限用户授权，你根本不需要考虑这个问题;在不增加成本的情况下，尽可能多地添加安装所能支持的用户帐户。
专用配电网
您可以将来自Artifactory单一真实源的发布分发到Artifactory边缘节点，这些节点可以连接到一个多节点拓扑中，以形成一个跨越全球的安全、高速、私有分发网络(PDN)。通过JFrog创新的点对点网络技术，您可以克服较差的网络连接、延迟和跨界障碍，以最快的速度安全地在全球范围内交付大型签名发布包。
如上所述，GitLab不提供交付或分发解决方案。
一旦向前一跃，就不会后退
从许多依赖GitLab进行源代码管理的组织可以明显看出，GitLab作为风险投资和项目经理的优势。事实上，JFrog的许多客户都是这样做的，他们使用JFrog的通用CLI和api与他们选择的CI/CD集成，无论是GitLab、Jenkins还是其他工具。在GitLab最近提交的S-1表格中，超过一半的客户也是JFrog的客户!
凭借其广泛的工具组合，GitLab的产品要求您用来自单一供应商的工具链替换最佳工具链。但除非供应商能给你提供更好的成功机会，否则这是一笔有风险的交易。
在JFrog，我们的使命很简单:通过提供快速、安全、持续发布版本的最佳解决方案，让每个软件开发者都获得成功。
根据他们的说法，GitLab的野心当然很大使命宣言．“未来30年，我们的BHAG将成为所有行业中最受欢迎的知识工作者协作工具。”
为什么要等三十年?JFrog DevOps平台由业界最流行的二进制文件管理工具提供支持，现在已经可以使用了免费开始！
