Netflix 是如何构建代码的

三名 Netflix 工程师 Ed Bukoski 、 Brian Moyles 和 Mike McGarr 在一篇博文中解释了Netflix 如何持续交付向7500 万观众提供电视节目和电影的代码。

Immutable Server 模式是 Netflix 部署的基础。每次部署都会创建一个全新的亚马逊机器镜像（AMI）。

Netflix 的微服务架构让 Netflix 团队可以松耦合。变更推送速度让每个团队都很舒服。

Netflix 不要求任何团队使用任何工具集，但他们要负责维护他们实现的工具。在 Netflix，有团队会集中提供工具，作为“铺好的路”的一部分，以减少大多数 Netflix 工程师的认知负担。

这个“铺好路”的代码交付过程由几个步骤组成。代码使用 Nebula 在本地构建和测试。变更提交到中心 Git 版本库。一个 Jenkins 作业构建、测试并打包应用程序用于部署。这些程序包使用 Netflix 的全球持续交付平台 Spinnaker 部署到亚马逊机器镜像（AMI）。

构建

Nebula 是 Gradle 构建系统的一组插件，它可以构建、测试并打包 Java 应用程序。Netflix 的大多数代码都是用 Java 编写的。这些插件扩展了 Gradle 的自动化功能，包括依赖管理、发布管理以及打包。一个项目的构建文件声明了用到的依赖和插件。

集成

下一步是将本地构建、测试并打包的源代码推送到 Git 版本库。具体的流程由团队选择。

提交完成后，会触发一个 Jenkins 作业构建、测试并打包代码用于部署。程序包类型会根据构建对象是一个库还是一个应用程序作出恰当的选择。

部署

Netflix “Bakery”暴露了一个 API 用于创建 AMI。具体的镜像使用 Aminator 创建。用户指明将什么基础镜像和程序包放入该 AMI。基础镜像是一个 Linux 环境，包含与 Netflix 生态系统集成所需的约定、工具和服务。

当 Jenkins 集成任务执行成功后，它会触发 Spinnaker 管道。Spinnaker 读取 Nebula 程序包，并使用 Bakery API 创建 AMI。

然后，Spinnaker 会向数以十计、百计或千计的实例提供该 AMMI。

第一次部署是到测试环境，部署会执行自动化集成测试。在通过这些测试后，Spinnaker 为团队提供了自定义生产环境部署过程的灵活性，例如多区域部署、金丝雀发布或者红/ 黑部署。

该自动化过程非常高效，举例来说， Janitor Monkey 云弹性和维护服务从代码检入到多区域部署只要 16 分钟就可以完成。

未来方向

在 Netflix，语言无关的需求与日俱增。非 JVM 语言需要包含进构建过程。

部署时间有一大部分是“烘焙（baking）”过程，Netflix 正设法减少这部分时间。

此外，Netflix 还在研究容器是否能够帮助他们应对上述两个挑战。

容器还可以改进当前的构建、烘焙和部署过程，进而改善开发测试周期。可以在本地部署的容器，无需修改就可以部署到生产环境，这对于确定一个 Bug 是否是由环境差异导致的非常有帮助。这让工程师可以专注于新特性。

查看英文原文： How Code is Built at Netflix