Siva Mandadi 是来自奔驰北美研发中心的用户交互部门的一名 DevOps 工程师，他在一次分享中介绍了奔驰通过 DevOps 落地，加速打造未来汽车的实践。本文根据视频资料整理而来，原视频地址：

h

背景介绍

奔驰对于未来汽车的定义涵盖了很多方面，包括车载音乐、导航、自动驾驶等等，涉及到的实现技术也是多方面的，如机器学习、物联网等前沿技术。这些技术表现在实际应用上，便有了一种“未来感”。举个例子，未来汽车可以根据天气情况，切换车内的主题，比如颜色、音乐等，让车主时刻都保持舒适的状态；或者，如果车主开车回家，在离家还有半小时车程的时候，可以通过车给家里的厨房电器发消息，开始准备煮一顿可口的饭菜。

最开始，整个用户交互部门（视频主讲人所在部门）大约有 300 名工程师，他们来自不同国家，分布在美国、德国和印度等不同地域；团队每天大约会执行 60 次构建任务；每周有超过 1000 个、约 1TB 数据量的自研件产生；平均 CI 构建时长为 6 小时。

面临的挑战

随着业务的发展，团队面临着巨大的挑战，主要是在工件的存储与共享、依赖管理、编排、持续构建和仓库不同等方面：

• 自研件存储：每周会产生超过 1000 个自研件，需要耗费近 ITB 存储空间，随着时间推移现有的存储资源很快就出现枯竭。

  
  

• 自研件共享：团队成员分布在世界各地，上传和下载的速度成为瓶颈，开发与 QA 人员通常会抱怨下载速度太慢。比如印度和德国的开发者需要上传，美国这边的 QA 需要下载进行测试就会遇到这种情况。

  
  

• 依赖管理：庞大研发团队的依赖管理也是一个非常头疼的问题，某些功能依赖的软件包在不同的模块中存在着不同的版本，而维护复杂的依赖关系是非常有挑战的一件事情。团队主要使用 Java 和 C++ 开发，并且使用了 maven、conan 作为依赖管理工具。

  
  

• 持续集成：持续集成对于这样一个大团队是必须的，每一次的提交都必须通过持续集成（CI）确保提交不会带来任何问题。团队使用了 Jenkins 和 Bamboo 做一些持续集成相关的事情，值得一提的是使用了 Docker Container 作为 Jenkins Agent，通过配置文件根据负载动态创建 Build Agent。然而，由于 Docker 镜像非常大，而且处于不同的地域，导致整个过程也效率较低。

  
  

在遇到上述挑战的同时，在 CI 构建阶段，下载依赖的时候达到 5-6 个小时，这也是难以接受的，并且由于 Artifact 非常大，也会使得整个系统运行缓慢。一种解决方案就是使用 NAS 存储。但是依然存在一些新的挑战：

• 价格昂贵。

  
  

• NAS 存储虽然能在一定程度上解决问题，但是相关的设备和维护费用非常昂贵。

  
  

• 构建次数的限制：由于构建的自研件增长非常快，然而存储空间是相对有限的，所以，实际情况下需要限制 10 次构建。

  
  

• 共享：共享的问题依然难以解决，尤其是跨地域的共享。

  
  

解决方案

在对挑战进行分析之后，认为有如下两种可选的解决方案。一种是增加存储，另外一种方式是采用 Nexus，但需要高可用架构和 REST API 的支持。

这两种选择无疑都需要一个强大的 DevOps 工具。对于跨国研发团队来说，高可用是非常重要的特性，多语言的仓库也是必须的，增加存储显然难以解决根本问题。Nexus 有多语言支持，但是在高可用和 REST API 方面都需要额外的维护。在调研了众多相关产品之后，奔驰的研发团队认为 JFrog Artifactory 是非常不错的选择。

JFrog Artifactory 提供了非常丰富的功能，比如统一的仓库、一致的 UI、企业级高可用支持、基于 YAML 的预定义配置、丰富的 REST API 支持以及良好的客户支持等等。Artifactory 对开源工具均可以无缝对接，尤其是 Jenkins，因此用户原有的习惯几乎不需要改变，使用之后，整个 DevOps 环境有了很显著的变化。

除此之外，Artifactory 还有诸多非常强大的特性，如 DevOps 全生命周期元数据记录、AQL(Artifactory Query Language) 查询语言、跨语言的服务正向和反向依赖解析、结合 Xray 的漏洞扫描及影响力分析等等。

奔驰通过 Artifactory 实现了统一的依赖管理和集中式的软件包仓库，结合其强大的正反向依赖解析，轻松解决了依赖关系不清晰的问题。Artifactory 的异地同步复制解决了软件包上传和下载的性能瓶颈问题，由于具有缓存机制，使得虽然每天的构建频率增长十倍，但是构建时间却大幅下降。在自研件存储方面，通过 Artifactory 的存储优化节省了大量存储空间，且通过自动清理机制，减少了很多管理成本，也降低了人为操作的风险。

全球分布的研发中心和人员的角色变更，使得权限的管控变得异常复杂，由于 Artifactory 集中管理了所有语言的二进制包，奔驰在使用 Artifactroy 后轻松地实现了对各地研发人员的细粒度权限管控，在团队内共享也可以很方面地控制相关权限，确保始终满足最小权限模型的要求。

从数据我们可以看出，每日构建的次数增长了 10 倍，每周产生的工件也增长了 10 倍，但是存储只增加了 2 倍，存储优化十分显著。最明显的效果是 CI 构建的时间减少了 3600%，这是非常惊人的。当然，这些都是直观的效果，还有一些是潜在的收益，比如新人熟悉整个项目的时间更短了、开发的周期更短、权限控制更加准确，相应地安全性也大幅提升。

总结

奔驰所面临的挑战在很多企业中都存在，尤其是大型的跨国开发团队。企业级的高可用，多语言的集中式仓库，跨地域的复制分发以及强大的依赖管理功能都是必须要满足的需求，JFrog Artifactory 在奔驰的实践中提供了切实可行的解决方案，实现了 DevOps 的平稳落地，具有借鉴意义。

原创：付辉，JFrog 资深工程师，专注软件系统架构及企业 IT 转型，曾在 HPE 担任云计算技术顾问、容器架构师、DevOps 架构师等，曾服务客户中石油及中石化、摩托罗拉、阿尔卡特 - 朗讯、华为等等。擅长容器及容器编排技术，熟悉混合云架构、微服务架构、持续集成及交付、DevOps 等。长期参与开源社区开发及翻译工作。

Siva Mandadi 是来自奔驰北美研发中心的用户交互部门的一名 DevOps 工程师，他在一次分享中介绍了奔驰通过 DevOps 落地，加速打造未来汽车的实践。本文根据视频资料整理而来，原视频地址：

h

背景介绍

奔驰对于未来汽车的定义涵盖了很多方面，包括车载音乐、导航、自动驾驶等等，涉及到的实现技术也是多方面的，如机器学习、物联网等前沿技术。这些技术表现在实际应用上，便有了一种“未来感”。举个例子，未来汽车可以根据天气情况，切换车内的主题，比如颜色、音乐等，让车主时刻都保持舒适的状态；或者，如果车主开车回家，在离家还有半小时车程的时候，可以通过车给家里的厨房电器发消息，开始准备煮一顿可口的饭菜。

最开始，整个用户交互部门（视频主讲人所在部门）大约有 300 名工程师，他们来自不同国家，分布在美国、德国和印度等不同地域；团队每天大约会执行 60 次构建任务；每周有超过 1000 个、约 1TB 数据量的自研件产生；平均 CI 构建时长为 6 小时。

面临的挑战

随着业务的发展，团队面临着巨大的挑战，主要是在工件的存储与共享、依赖管理、编排、持续构建和仓库不同等方面：

• 自研件存储：每周会产生超过 1000 个自研件，需要耗费近 ITB 存储空间，随着时间推移现有的存储资源很快就出现枯竭。

  
  

• 自研件共享：团队成员分布在世界各地，上传和下载的速度成为瓶颈，开发与 QA 人员通常会抱怨下载速度太慢。比如印度和德国的开发者需要上传，美国这边的 QA 需要下载进行测试就会遇到这种情况。

  
  

• 依赖管理：庞大研发团队的依赖管理也是一个非常头疼的问题，某些功能依赖的软件包在不同的模块中存在着不同的版本，而维护复杂的依赖关系是非常有挑战的一件事情。团队主要使用 Java 和 C++ 开发，并且使用了 maven、conan 作为依赖管理工具。

  
  

• 持续集成：持续集成对于这样一个大团队是必须的，每一次的提交都必须通过持续集成（CI）确保提交不会带来任何问题。团队使用了 Jenkins 和 Bamboo 做一些持续集成相关的事情，值得一提的是使用了 Docker Container 作为 Jenkins Agent，通过配置文件根据负载动态创建 Build Agent。然而，由于 Docker 镜像非常大，而且处于不同的地域，导致整个过程也效率较低。

  
  

在遇到上述挑战的同时，在 CI 构建阶段，下载依赖的时候达到 5-6 个小时，这也是难以接受的，并且由于 Artifact 非常大，也会使得整个系统运行缓慢。一种解决方案就是使用 NAS 存储。但是依然存在一些新的挑战：

• 价格昂贵。

  
  

• NAS 存储虽然能在一定程度上解决问题，但是相关的设备和维护费用非常昂贵。

  
  

• 构建次数的限制：由于构建的自研件增长非常快，然而存储空间是相对有限的，所以，实际情况下需要限制 10 次构建。

  
  

• 共享：共享的问题依然难以解决，尤其是跨地域的共享。

  
  

解决方案

在对挑战进行分析之后，认为有如下两种可选的解决方案。一种是增加存储，另外一种方式是采用 Nexus，但需要高可用架构和 REST API 的支持。

这两种选择无疑都需要一个强大的 DevOps 工具。对于跨国研发团队来说，高可用是非常重要的特性，多语言的仓库也是必须的，增加存储显然难以解决根本问题。Nexus 有多语言支持，但是在高可用和 REST API 方面都需要额外的维护。在调研了众多相关产品之后，奔驰的研发团队认为 JFrog Artifactory 是非常不错的选择。

JFrog Artifactory 提供了非常丰富的功能，比如统一的仓库、一致的 UI、企业级高可用支持、基于 YAML 的预定义配置、丰富的 REST API 支持以及良好的客户支持等等。Artifactory 对开源工具均可以无缝对接，尤其是 Jenkins，因此用户原有的习惯几乎不需要改变，使用之后，整个 DevOps 环境有了很显著的变化。

除此之外，Artifactory 还有诸多非常强大的特性，如 DevOps 全生命周期元数据记录、AQL(Artifactory Query Language) 查询语言、跨语言的服务正向和反向依赖解析、结合 Xray 的漏洞扫描及影响力分析等等。

奔驰通过 Artifactory 实现了统一的依赖管理和集中式的软件包仓库，结合其强大的正反向依赖解析，轻松解决了依赖关系不清晰的问题。Artifactory 的异地同步复制解决了软件包上传和下载的性能瓶颈问题，由于具有缓存机制，使得虽然每天的构建频率增长十倍，但是构建时间却大幅下降。在自研件存储方面，通过 Artifactory 的存储优化节省了大量存储空间，且通过自动清理机制，减少了很多管理成本，也降低了人为操作的风险。

全球分布的研发中心和人员的角色变更，使得权限的管控变得异常复杂，由于 Artifactory 集中管理了所有语言的二进制包，奔驰在使用 Artifactroy 后轻松地实现了对各地研发人员的细粒度权限管控，在团队内共享也可以很方面地控制相关权限，确保始终满足最小权限模型的要求。

从数据我们可以看出，每日构建的次数增长了 10 倍，每周产生的工件也增长了 10 倍，但是存储只增加了 2 倍，存储优化十分显著。最明显的效果是 CI 构建的时间减少了 3600%，这是非常惊人的。当然，这些都是直观的效果，还有一些是潜在的收益，比如新人熟悉整个项目的时间更短了、开发的周期更短、权限控制更加准确，相应地安全性也大幅提升。

总结

奔驰所面临的挑战在很多企业中都存在，尤其是大型的跨国开发团队。企业级的高可用，多语言的集中式仓库，跨地域的复制分发以及强大的依赖管理功能都是必须要满足的需求，JFrog Artifactory 在奔驰的实践中提供了切实可行的解决方案，实现了 DevOps 的平稳落地，具有借鉴意义。

原创：付辉，JFrog 资深工程师，专注软件系统架构及企业 IT 转型，曾在 HPE 担任云计算技术顾问、容器架构师、DevOps 架构师等，曾服务客户中石油及中石化、摩托罗拉、阿尔卡特 - 朗讯、华为等等。擅长容器及容器编排技术，熟悉混合云架构、微服务架构、持续集成及交付、DevOps 等。长期参与开源社区开发及翻译工作。