在程式碼部署到雲端之前，Netflix 是如何做構建的？本篇文章將描述為 Netflix 服務8000萬用戶的微服務，是用什麼工具和技術構建出來的。

上圖描述了在 Netflix 的全球持續釋出平臺 Spinnaker 做釋出之前，仍然有幾個步驟需要執行，這些步驟就是將原始碼編譯、構建、測試打包的過程，這些過程包括:

·   程式碼在本地用 Nebula 進行構建和測試。

·   程式碼都會被提交到統一的中央 Git 程式碼庫。

·   使用 Jenkins 任務執行 Nebula 構建，測試並且執行打包應用。

·   構建被 “baked” 到 Amazon Machine Images（AMI）。

·   Spinnaker pipelines 用來部署和升級程式碼變更。

文化，雲端計算，微服務

在進入 Netflix 如果構建程式碼的細節之前, 先來看看 Netflix 最重要的關鍵元素：文化，雲端計算，微服務。

Netflix 的文化鼓勵員工使用任何他們認為最好的工具去完成任務。在 Netflix 內部功能風靡的工具，一定是很核心的，非常具有價值，為大部分程式設計師大幅提升效能的工具。團隊有選擇技術方案的自由，同時也承擔維護這些新方案的責任。

另外，在 2008 Netflix 開始將流媒體業務遷移到 AWS，也開始將巨石應用遷移到基於 Java 的微服務，微服務架構裡，服務之前鬆耦合，任何團隊可以按需的釋出程式碼變更。

構建

Netflix 建立了 Nebula, 一個精選了多個外掛的 Gradle 構建系統, 目的是為了全公司的 Java 服務提供統一的構建工具. Gradle 對應 Java 應用的構建，測試和打包支援的非常全面。為什麼選擇 Gradle？ 因為使用 Gradle編寫 外掛非常容易，同時大大減少每個專案的構建檔案。Nebula 繼承了 Gradle 健壯的自動化構建系統，並且繼承了一系列開源工具，支援依賴管理，釋出管理，打包等等。

一個簡單的 Java 專案 build.gradle 檔案：

上面的 ‘build.gradle’ Netflix 的一個典型的 Java 構建專案。這個構建檔案聲明瞭 Java 的依賴和4個應用的 Gradle 外掛。 其中，‘nebula’ 外掛是內部用於整合內部基礎服務的Gradle 外掛。‘Nebula.dependency-lock’ 外掛能夠為專案生成一個.lock 檔案，記錄所有依賴的圖譜，用於版本的重建。 ‘Netflix.ospackage-tomcat’ 外掛接下來會講到。

通過 Nebula 能夠實現可重用的構建能力，減少了專案框架構建檔案的數量。 Nebula 已經在 Github 開源，詳情可以去 Nebula 的官網檢視 the Nebula website。

整合

當代碼被 Nebula 本地構建，測試完成後，可以將它做持續整合和部署。第一步是將它提交到 Git 倉庫。

一旦程式碼提交，一個 Jenkins 被觸發。Netflix 使用一個巨大的Jenkins Master 排程 AWS 上的25個 Jenkins Master 節點。

一個 Jenkins 會配置 Neluba 的構建，測試和打包。如果目標包是一個庫，Nebula 會打包成 .jar 到 Artifactory 倉庫。如果目標包是一個應用， Nebula ospackage plugin 會被執行。使用 Nebula ospackage 外掛，一個應用會被部署到一個 Debian 或者 RPM 包，這些包的內容會被 Gradle 的 DSL 定義。Nebula 會發布這些映象檔案到包倉庫管理平臺，準備下一個環節 “baking”。

Bake

Netflix 的部署策略是集中式，不可變基礎設施為主導的模式。動態修改線上伺服器的內容是嚴令禁止的，目的是為了每次釋出是完成從程式碼提交開始。每次部署始於一個新的亞馬遜機器映象 Amazon Machine Image。從程式碼到生成 AMI就叫做 “the Bakery”.

Bakery 提供了全域性的建立 AMIs 的介面。 Bakery API 服務定時的去執行建立映象的任務，任務使用 Aminator 去建立映象。使用者只需要宣告需要安裝的依賴包，基礎映象，以及 Netflix 的上線基礎服務即可。

當 Jenkins 任務成功了，它會觸發一個 Spinnaker pipeline. Spinnaker 流水線可以被 Jenkins 任務觸發，或者被一個 git commit 觸發。Spinnaker 將會讀取 Nebula 構建處理的系統包，並且呼叫 Bakery API 去發起一次 bake。

部署

一旦 bake 完成，Spinnaker 將烘焙好的 AMI 成百上千臺伺服器裡。同樣的  AMI 可以被不同環境重複使用，Spinnaker 暴露一個執行時的 context，能夠進行執行時的環境變數注入。一個成功的 bake 會觸發下一個階段的 Spinnaker 流水線，一次部署到測試環境。從這裡，團隊會執行自動化的整合測試。在部署階段，團隊開始自定義自己的部署目標。可以使用 Spinnaker 管理多 Region 的部署，金絲雀釋出，藍綠部署等等。 Spinnaker pipelines 為團隊提供了足夠強大的能力去部署程式碼。

未來展望

總體來說，這些工具帶來了很高效的自動化能力。例如，Netflix 從程式碼提交，到部署到跨區域的雲伺服器的時間只需要16分鐘。

Netflix 一直在思考如何改進開發者的使用者體驗，如何做到更好，更快，更容易的交付軟體。

Netflix 一直受到如何管理包依賴問題的困擾。Nebula 提供了更方便的解析 Java 依賴的能力。例如 Nebula dependency-lock plugin 能夠為應用程式生成一個.lock 檔案，將所有依賴的檔案版本化起來。 Nebula resolution rules plugin 提供跨團隊的依賴解析規則，在所有 Nebula 的構建中生效。這些外掛可以將依賴管理變得更加容易。

另外一個挑戰，是 Bake 時間過長。在不久之前，16分鐘從程式碼提交到部署還是一個夢想，但隨著各個系統的時間都在縮短，這個時間變得越來越短。

隨著Netflix 的發展，支援非 JVM 語言的構建，測試工具鏈的需要越來越強烈，例如 JavaScript/Node.js, Python, Ruby and Go。目前推薦非 JVM 得語言使用 Nebula ospackage 外掛生成 Debian 包去做 baking，將構建和測試的階段交給團隊熟悉的工具。

原文地址：https://medium.com/netflix-techblog/how-we-build-code-at-netflix-c5d9bd727f15

掃碼關注我們！

關於JFrog

世界領先DevOps平臺

公司成立於2008年，在美國、以色列、法國、西班牙，以及中國北京市擁有超過200名員工。JFrog 擁有4000多個付費客戶，其中知名公司包括如騰訊、谷歌、思科、Netflix、亞馬遜、蘋果等。關注 JFrog，感受原汁原葉的矽谷技術！我們不僅僅提供最優秀的產品，也提供最優秀的持續交付平臺的解決方案，詳情請洽[email protected]