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是否是由环境差异导致的非常有帮助。这让工程师可以专注于新特性。

本文转自d1net（转载）