原文：How We Build Code at Netflix
作者：Ed Bukoski, Brian Moyles and Mike McGarr
譯者：杰微刊兼職翻譯劉曉鵬
Netflix在部署到云環(huán)境之前是如何構(gòu)建代碼的？過去我們已經(jīng)討論過這個(gè)問題的部分內(nèi)容，現(xiàn)在是到分享更多細(xì)節(jié)的時(shí)候了。在這篇文章中，我們將描述這個(gè)為7500,0000 全球Netflix成員提供電影和TV播放的應(yīng)用是如何實(shí)現(xiàn)從源代碼到服務(wù)部署的。
上面的圖表是對Spinnaker（我們的全球持續(xù)交互平臺(tái)）之前發(fā)布博文的擴(kuò)展。每一行代碼在進(jìn)入Spinnaker之前，都需要經(jīng)過很多的步驟：
1、代碼構(gòu)建并使用 Nebula進(jìn)行本地測試。
2、將修改的代碼提交到git中心倉庫。
3、 Jenkins任務(wù)執(zhí)行 Nebula，包括構(gòu)建，測試以及應(yīng)用程序的打包。
4、將新的版本放到AMI（Amazon Machine Image，亞馬遜虛擬機(jī)鏡像）上“烘烤”。
5、 通過Spinnaker流水線部署和升級修改后的代碼。
本文剩余部分將演示每個(gè)階段所使用的工具和處理過程，以及為什么我們要采用這樣的方式。通過分享一些我們現(xiàn)在正處理的挑戰(zhàn)，我們將變得更加密切。在Netflix 構(gòu)建和部署代碼的過程中使用了很多工具，也遇到了很多挑戰(zhàn)。你們可以期待這是描述這些工具和挑戰(zhàn)細(xì)節(jié)的第一篇文章。
文化，云與微服務(wù)
在深入 Netflix如何構(gòu)建代碼之前，有必要強(qiáng)調(diào)幾個(gè)驅(qū)動(dòng)和塑造我們解決方案的關(guān)鍵要素：我們的文化，云及微服務(wù)。
Netflix的文化是自由與責(zé)任，這種文化使得工程師可以采用任何他們認(rèn)為最適合任務(wù)的工具來創(chuàng)建解決方案。根據(jù)我們的經(jīng)驗(yàn)，如果一個(gè)工具被廣泛使用，那它一定是令人信服的，具有巨大價(jià)值的，并能減少絕大部分 Netflix工程師認(rèn)知負(fù)擔(dān)的。團(tuán)隊(duì)可以自由的修改實(shí)現(xiàn)方案，但同時(shí)也有責(zé)任來維護(hù)這些方案。Netflix核心團(tuán)隊(duì)提供的工具本被認(rèn)為是這條“柏油路”的一部分。我們今天所關(guān)注的僅僅是這條“柏油路”上支持的引擎工具（Engineering Tool）。
此外，2008 年，Netflix開始將流服務(wù)移植到AWS上，并將基于Java 應(yīng)用的龐大數(shù)據(jù)中心轉(zhuǎn)換為基于 Java微服務(wù)的云。我們微服務(wù)架構(gòu)允許 Netflix團(tuán)隊(duì)以松耦合的方式存在，并以他們認(rèn)為合適的速度來構(gòu)建和推進(jìn)更新。
構(gòu)建
自然，部署一個(gè)應(yīng)用或一個(gè)服務(wù)的第一步就是構(gòu)建。我們創(chuàng)建了 Nebula（一個(gè) Gradle構(gòu)建系統(tǒng)上的可選插件集）來輔助繁重的構(gòu)建任務(wù)。Gradle為構(gòu)建，測試及打包 Java應(yīng)用（這包含了我們大部分的代碼）提供一流的支持。之所以選擇 Gradle是因?yàn)樗子诰帉懣蓽y試的插件，同時(shí)降低了項(xiàng)目構(gòu)建文件的大小。Nubula繼承了 Gradle 健壯的自動(dòng)化構(gòu)建功能，包括一系列開源的依賴管理插件，版本管理、打包等等。
上面的“build.gradle”文件展示了在Netflix中是如何定義構(gòu)建一個(gè)簡單Java應(yīng)用的。該項(xiàng)目的構(gòu)建文件聲明了幾個(gè) Java依賴，同時(shí)使用了 4 個(gè)Gradle插件，其中3個(gè)要么是Nebula的一部分，要么是應(yīng)用在Nebula上的內(nèi)部插件。“nebula”插件是一個(gè)只在內(nèi)部使用的Gradle插件，為整合我們的基礎(chǔ)架構(gòu)提供規(guī)則和必要的配置。“nebula.dependency-lock”插件可以使項(xiàng)目生成一個(gè)基于版本的.lock的文件，用于解決依賴和重復(fù)構(gòu)建問題?！皀etflix.ospackage-tomcat”插件及ospackage塊將在下文中接觸到。
通過Nebula，我們提供可重用和一致的構(gòu)建功能，其目標(biāo)是減少每個(gè)應(yīng)用程序構(gòu)建文件中的樣板文件。在以后的技術(shù)博客中將更加深入的討論 Nebula及其特性（我們已經(jīng)將其開源）。現(xiàn)在，我們可以通過Nebula 網(wǎng)站來獲取源碼。
整合
當(dāng)一行代碼構(gòu)建完成并通過了本地 Nebula的測試，就準(zhǔn)備對其進(jìn)行持續(xù)集成和部署了。第一步是將更新過的源碼推送到git倉庫。團(tuán)隊(duì)可以自由尋找git工作流。一旦提交了更新，就會(huì)觸發(fā)一個(gè)Jenkins的任務(wù)。我們使用 Jenkins進(jìn)行持續(xù)集成已經(jīng)有好幾年了。一開始，數(shù)據(jù)中心使用的是一個(gè)大的 Jenkins master ，現(xiàn)在，在AWS上已經(jīng)發(fā)展成為 25 個(gè)Jenkinsmaster了。在整個(gè) Netflix上，Jenkins主要用于各種自動(dòng)化測試的任務(wù)，以上提到的只是簡單的持續(xù)集成。
一個(gè)Jenkins任務(wù)是可配置的，涉及構(gòu)建、測試和應(yīng)用程序代碼的打包。如果被構(gòu)建的倉庫是一個(gè)庫文件，Nebula將發(fā)布.jar 到我們的歸檔倉庫。如果倉庫是一個(gè)應(yīng)用，Nebulaospackage插件就會(huì)執(zhí)行。使用 Nebula ospackage（操作系統(tǒng)包的簡稱）插件，一個(gè)應(yīng)用構(gòu)建出的歸檔文件就會(huì)綁定到 Debian或RPM包上，它們的內(nèi)容通過一個(gè)簡單的基于DSL的Gradle來定義。然后，Nebula將會(huì)發(fā)布 Debian 文件到一個(gè)包倉庫，這個(gè)倉庫對處理流程的下一個(gè)階段——烘烤是有用的。
烘烤
我們的部署策略是以不可變服務(wù)器為中心的模式。為了減少配置漂移，確保源代碼可重復(fù)部署，強(qiáng)力反對在線修改實(shí)例。Netflix的每次部署首先都會(huì)創(chuàng)建一個(gè)新的AMI。為了從源頭生成 AMI，我們創(chuàng)建了一個(gè)“Bakery”。
當(dāng)一個(gè)Jenkins任務(wù)執(zhí)行成功后，通常會(huì)觸發(fā)一個(gè) Spinnaker流水線。Spinnaker流水線可被一個(gè)Jenkins 任務(wù)或一次 Git提交觸發(fā)。Spinnaker將讀取由Nebula生成的操作系統(tǒng)的包，然后調(diào)用Bakery API來進(jìn)行烘烤。
部署
一旦烘烤完成，Spinnaker使得最終的AMI可以部署數(shù)十、數(shù)百甚至數(shù)千個(gè)實(shí)例。由于 Spinnaker對實(shí)例暴露的運(yùn)行時(shí)環(huán)境是允許應(yīng)用在運(yùn)行時(shí)自由配置的，這樣就使得的AMI可以跨多個(gè)環(huán)境。一次成功的烘烤將觸發(fā) Spinnaker流水線的下一個(gè)階段——部署到測試環(huán)境。從這起，團(tuán)隊(duì)通常會(huì)使用一連串的自動(dòng)化集成測試來執(zhí)行部署。從這一點(diǎn)開始，特定應(yīng)用程序的部署流水線將變得非常定制化。團(tuán)隊(duì)將使用 Spinnaker來管理多區(qū)域部署，Canary 版本、紅/黑部署等等?？梢赃@么說，Spinnaker流水線為團(tuán)隊(duì)如何控制部署代碼提供了極大的靈活性。
未來之路
總之，這些工具使得諸多工作變得高效和自動(dòng)化。例如，我們只需要 16 分鐘，就可以完成對云彈性計(jì)算和維護(hù)服務(wù)（JanitorMonkey）從代碼檢出到多區(qū)域部署的過程。
也就是說，我們一直在努力提高開發(fā)者經(jīng)驗(yàn)，不斷的挑戰(zhàn)我們自己，以便做到更好，更快，同時(shí)更簡單。
我們正積極應(yīng)對的一個(gè)挑戰(zhàn)是如何在Netflix中管理二進(jìn)制依賴。Nebula 提供的工具側(cè)重于簡化 Java的依賴管理。例如，Nebuladependency-lock插件可以生成一個(gè)基于版本的.lock文件，從而使得應(yīng)用程序解決它們完整的二進(jìn)制依賴。Nubularesolutionrules 插件允許我們發(fā)布整個(gè)組織的依賴規(guī)則，從而影響整個(gè)Nebula的構(gòu)建。這些工具使得二進(jìn)制依賴管理更加簡單，但是還是沒有將“痛苦”減少到可以接受的范圍。
另一個(gè)挑戰(zhàn)我們正在處理的是烘烤時(shí)間。不久之前，16 分鐘完成從代碼提交到部署只是一個(gè)夢想。但是現(xiàn)在，由于系統(tǒng)其它部分都變得更快了，這反而成為快速創(chuàng)新的一個(gè)障礙。從上面部署SimianArmy的例子可以看出，烘烤的過程花了 7 分鐘，烘烤占據(jù)了整個(gè)部署時(shí)間的 44%。我們發(fā)現(xiàn)烘烤時(shí)間中最耗時(shí)間的操作是安裝包（包括依賴解決）和 AWS快照自身的處理。
隨著Netflix的成長和發(fā)展，存在一個(gè)不斷增長的需求，就是我們的構(gòu)建和部署工具需要為非 JVM語言提供很好的支持，如JavaScript/Node.js, Python, Ruby和 Go。對非 JVM應(yīng)用，我們當(dāng)前推薦的的方式是使用 Nebulaospackage插件來生成 Debian包，以便對其進(jìn)行烘烤，對工程師來說，如果跳過構(gòu)建和測試，平臺(tái)是其首選的工具。這雖然解決了團(tuán)隊(duì)當(dāng)前的需求，但是還是需要擴(kuò)展其成為語言無關(guān)的工具。
容器為最后兩個(gè)挑戰(zhàn)提供了一個(gè)有趣的可能的解決方案，我們正在探索如何通過容器來幫助我們改善構(gòu)建、烘烤和部署的過程。如果我們能夠提供一個(gè)基于容器的本地環(huán)境，就能更類似的模擬云環(huán)境，從而可能減少開發(fā)和測試過程中的所需的烘烤次數(shù)，提高開發(fā)者的生產(chǎn)力，加速整個(gè)開發(fā)過程。如果容器可以部署在本地，這樣在服務(wù)器上就不需要進(jìn)行修改，從而減少認(rèn)知的負(fù)擔(dān)，工程師就只需關(guān)注問題的解決和創(chuàng)新，而不是糾結(jié)bug的產(chǎn)生是不是因?yàn)榄h(huán)境的差異。
你可以期待在以后的文章中提供我們?nèi)绻鉀Q這些問題的更新。如果聽到這些挑戰(zhàn)讓你感到興奮，請加入我們的工程工具團(tuán)隊(duì)。你可以查看我們現(xiàn)在開放的職位，并馬上申請！
