使用開源工具構建DevOps流水線的初學者指南
如果你是 DevOps 新人，請查看這 5 個步驟來構建你的第一個 DevOps 流水線。
DevOps 已經成為解決軟件開發過程中出現的緩慢、孤立或者其他故障的默認方式。但是當你剛接觸 DevOps 并且不確定從哪開始時，就意義不大了。本文探索了什么是 DevOps 流水線并且提供了創建它的 5 個步驟。盡管這個教程并不全面，但可以給你以后上手和擴展打下基礎。首先，插入一個小故事。
我的 DevOps 之旅
我曾經在花旗集團的云小組工作，開發基礎設施即服務網頁應用來管理花旗的云基礎設施，但我經常對研究如何讓開發流水線更加高效以及如何帶給團隊積極的文化感興趣。我在 Greg Lavender 推薦的書中找到了答案。Greg Lavender 是花旗的云架構和基礎設施工程（即 Phoenix 項目）的 CTO。這本書盡管解釋的是 DevOps 原理，但它讀起來像一本小說。
書后面的一張表展示了不同公司部署在發布環境上的頻率：
| 公司 | 部署頻率 |
|---|---|
| Amazon | 23,000 次/天 |
| 5,500 次/天 | |
| Netflix | 500 次/天 |
| 1 次/天 | |
| 3 次/周 | |
| 典型企業 | 1 次/9 個月 |
Amazon、Google、Netflix 怎么能做到如此之頻繁？那是因為這些公司弄清楚了如何去實現一個近乎完美的 DevOps 流水線。
但在花旗實施 DevOps 之前，情況并非如此。那時候，我的團隊擁有不同構建階段的環境，但是在開發服務器上的部署非常手工。所有的開發人員都只能訪問一個基于 IBM WebSphere Application 社區版的開發環境服務器。問題是當多個用戶同時嘗試部署時，服務器就會宕機，因此開發人員在部署時就得互相通知，這一點相當痛苦。此外，還存在代碼測試覆蓋率低、手動部署過程繁瑣以及無法根據定義的任務或用戶需求跟蹤代碼部署的問題。
我意識到必須做些事情，同時也找到了一個有同樣感受的同事。我們決定合作去構建一個初始的 DevOps 流水線 —— 他設置了一個虛擬機和一個 Tomcat 服務器，而我則架設了 Jenkins，集成了 Atlassian Jira、BitBucket 和代碼覆蓋率測試。這個業余項目非常成功：我們近乎全自動化了開發流水線，并在開發服務器上實現了幾乎 100% 的正常運行，我們可以追蹤并改進代碼覆蓋率測試，并且 Git 分支能夠與部署任務和 jira 任務關聯在一起。此外，大多數用來構建 DevOps 所使用的工具都是開源的。
現在我意識到了我們的 DevOps 流水線是多么的原始，因為我們沒有利用像 Jenkins 文件或 Ansible 這樣的高級設置。然而，這個簡單的過程運作良好，這也許是因為 Pareto 原則（也被稱作 80/20 法則）。
DevOps 和 CI/CD 流水線的簡要介紹
如果你問一些人，“什么是 DevOps？”，你或許會得到一些不同的回答。DevOps，就像敏捷，已經發展到涵蓋著諸多不同的學科，但大多數人至少會同意這些：DevOps 是一個軟件開發實踐或一個軟件開發生命周期（SDLC），并且它的核心原則是一種文化上的變革 —— 開發人員與非開發人員呼吸著同一片天空的氣息，之前手工的事情變得自動化；每個人做著自己擅長的事；同一時間的部署變得更加頻繁；吞吐量提升；靈活度增加。
雖然擁有正確的軟件工具并非實現 DevOps 環境所需的唯一東西，但一些工具卻是必要的。最關鍵的一個便是持續集成和持續部署（CI/CD）。在流水線環境中，擁有不同的構建階段（例如：DEV、INT、TST、QA、UAT、STG、PROD），手動的工作能實現自動化，開發人員可以實現高質量的代碼，靈活而且大量部署。
這篇文章描述了一個構建 DevOps 流水線的五步方法，就像下圖所展示的那樣，使用開源的工具實現。
Complete DevOps pipeline
閑話少說，讓我們開始吧。
第一步：CI/CD 框架
首先你需要的是一個 CI/CD 工具，Jenkins，是一個基于 Java 的 MIT 許可下的開源 CI/CD 工具，它是推廣 DevOps 運動的工具，并已成為了事實標準。
所以，什么是 Jenkins？想象它是一種神奇的萬能遙控，能夠和許多不同的服務器和工具打交道，并且能夠將它們統一安排起來。就本身而言，像 Jenkins 這樣的 CI/CD 工具本身是沒有用的，但隨著接入不同的工具與服務器時會變得非常強大。
Jenkins 僅是眾多構建 DevOps 流水線的開源 CI/CD 工具之一。
| 名稱 | 許可證 |
|---|---|
| Jenkins | Creative Commons 和 MIT |
| Travis CI | MIT |
| CruiseControl | BSD |
| Buildbot | GPL |
| Apache Gump | Apache 2.0 |
| Cabie | GNU |
下面就是使用 CI/CD 工具時 DevOps 看起來的樣子。
CI/CD tool
你的 CI/CD 工具在本地主機上運行，但目前你還不能夠做些別的。讓我們緊隨 DevOps 之旅的腳步。
第二步：源代碼控制管理
驗證 CI/CD 工具可以執行某些魔術的最佳（也可能是最簡單）方法是與源代碼控制管理（SCM）工具集成。為什么需要源代碼控制？假設你在開發一個應用。無論你什么時候構建應用，無論你使用的是 Java、Python、C++、Go、Ruby、JavaScript 或任意一種語言，你都在編程。你所編寫的程序代碼稱為源代碼。在一開始，特別是只有你一個人工作時，將所有的東西放進本地文件夾里或許都是可以的。但是當項目變得龐大并且邀請其他人協作后，你就需要一種方式來避免共享代碼修改時的合并沖突。你也需要一種方式來恢復一個之前的版本——備份、復制并粘貼的方式已經過時了。你（和你的團隊）想要更好的解決方式。
這就是 SCM 變得不可或缺的原因。SCM 工具通過在倉庫中保存代碼來幫助進行版本控制與多人協作。
盡管這里有許多 SCM 工具，但 Git 是最標準恰當的。我極力推薦使用 Git，但如果你喜歡這里仍有其他的開源工具。
| 名稱 | 許可證 |
|---|---|
| Git | GPLv2 & LGPL v2.1 |
| Subversion | Apache 2.0 |
| Concurrent Versions System (CVS) | GNU |
| Vesta | LGPL |
| Mercurial | GNU GPL v2+ |
擁有 SCM 之后，DevOps 流水線看起來就像這樣。
Source control management
CI/CD 工具能夠自動化進行源代碼檢入檢出以及完成成員之間的協作。還不錯吧？但是，如何才能把它變成可工作的應用程序，使得數十億人來使用并欣賞它呢？
第三步：自動化構建工具
真棒！現在你可以檢出代碼并將修改提交到源代碼控制，并且可以邀請你的朋友就源代碼控制進行協作。但是到目前為止你還沒有構建出應用。要想讓它成為一個網頁應用，必須將其編譯并打包成可部署的包或可執行程序（注意，像 JavaScript 或 PHP 這樣的解釋型編程語言不需要進行編譯）。
于是就引出了自動化構建工具。無論你決定使用哪一款構建工具，它們都有一個共同的目標：將源代碼構建成某種想要的格式，并且將清理、編譯、測試、部署到某個位置這些任務自動化。構建工具會根據你的編程語言而有不同，但這里有一些通常使用的開源工具值得考慮。
| 名稱 | 許可證 | 編程語言 |
|---|---|---|
| Maven | Apache 2.0 | Java |
| Ant | Apache 2.0 | Java |
| Gradle | Apache 2.0 | Java |
| Bazel | Apache 2.0 | Java |
| Make | GNU | N/A |
| Grunt | MIT | JavaScript |
| Gulp | MIT | JavaScript |
| Buildr | Apache | Ruby |
| Rake | MIT | Ruby |
| A-A-P | GNU | Python |
| SCons | MIT | Python |
| BitBake | GPLv2 | Python |
| Cake | MIT | C# |
| ASDF | Expat (MIT) | LISP |
| Cabal | BSD | Haskell |
太棒了！現在你可以將自動化構建工具的配置文件放進源代碼控制管理系統中，并讓你的 CI/CD 工具構建它。
Build automation tool
一切都如此美好，對吧？但是在哪里部署它呢？
第四步：網頁應用服務器
到目前為止，你有了一個可執行或可部署的打包文件。對任何真正有用的應用程序來說，它必須提供某種服務或者接口，所以你需要一個容器來發布你的應用。
對于網頁應用，網頁應用服務器就是容器。應用程序服務器提供了環境，讓可部署包中的編程邏輯能夠被檢測到、呈現界面，并通過打開套接字為外部世界提供網頁服務。在其他環境下你也需要一個 HTTP 服務器（比如虛擬機）來安裝服務應用。現在，我假設你將會自己學習這些東西（盡管我會在下面討論容器）。
這里有許多開源的網頁應用服務器。
| 名稱 | 協議 | 編程語言 |
|---|---|---|
| Tomcat | Apache 2.0 | Java |
| Jetty | Apache 2.0 | Java |
| WildFly | GNU Lesser Public | Java |
| GlassFish | CDDL & GNU Less Public | Java |
| Django | 3-Clause BSD | Python |
| Tornado | Apache 2.0 | Python |
| Gunicorn | MIT | Python |
| Python Paste | MIT | Python |
| Rails | MIT | Ruby |
| Node.js | MIT | Javascript |
現在 DevOps 流水線差不多能用了，干得好！
Web application server
盡管你可以在這里停下來并進行進一步的集成，但是代碼質量對于應用開發者來說是一件非常重要的事情。
第五步：代碼覆蓋測試
實現代碼測試件可能是另一個麻煩的需求，但是開發者需要盡早地捕捉程序中的所有錯誤并提升代碼質量來保證最終用戶滿意度。幸運的是，這里有許多開源工具來測試你的代碼并提出改善質量的建議。甚至更好的，大部分 CI/CD 工具能夠集成這些工具并將測試過程自動化進行。
代碼測試分為兩個部分：“代碼測試框架”幫助進行編寫與運行測試，“代碼質量改進工具”幫助提升代碼的質量。
代碼測試框架
| 名稱 | 許可證 | 編程語言 |
|---|---|---|
| JUnit | Eclipse Public License | Java |
| EasyMock | Apache | Java |
| Mockito | MIT | Java |
| PowerMock | Apache 2.0 | Java |
| Pytest | MIT | Python |
| Hypothesis | Mozilla | Python |
| Tox | MIT | Python |
代碼質量改進工具
| 名稱 | 許可證 | 編程語言 |
|---|---|---|
| Cobertura | GNU | Java |
| CodeCover | Eclipse Public (EPL) | Java |
| Coverage.py | Apache 2.0 | Python |
| Emma | Common Public License | Java |
| JaCoCo | Eclipse Public License | Java |
| Hypothesis | Mozilla | Python |
| Tox | MIT | Python |
| Jasmine | MIT | JavaScript |
| Karma | MIT | JavaScript |
| Mocha | MIT | JavaScript |
| Jest | MIT | JavaScript |
注意，之前提到的大多數工具和框架都是為 Java、Python、JavaScript 寫的，因為 C++ 和 C# 是專有編程語言（盡管 GCC 是開源的）。
現在你已經運用了代碼覆蓋測試工具，你的 DevOps 流水線應該就像教程開始那幅圖中展示的那樣了。
可選步驟
容器
正如我之前所說，你可以在虛擬機（VM）或服務器上發布你的應用，但是容器是一個更好的解決方法。
什么是容器？簡要的介紹就是 VM 需要占用操作系統大量的資源，它提升了應用程序的大小，而容器僅僅需要一些庫和配置來運行應用程序。顯然，VM 仍有重要的用途，但容器對于發布應用（包括應用程序服務器）來說是一個更為輕量的解決方式。
盡管對于容器來說也有其他的選擇，但是 Docker 和 Kubernetes 更為廣泛。
| 名稱 | 許可證 |
|---|---|
| Docker | Apache 2.0 |
| Kubernetes | Apache 2.0 |
了解更多信息，請查看 Opensource.com 上關于 Docker 和 Kubernetes 的其它文章：
中間件自動化工具
我們的 DevOps 流水線大部分集中在協作構建與部署應用上，但你也可以用 DevOps 工具完成許多其他的事情。其中之一便是利用它實現基礎設施管理（IaC）工具，這也是熟知的中間件自動化工具。這些工具幫助完成中間件的自動化安裝、管理和其他任務。例如，自動化工具可以用正確的配置下拉應用程序，例如網頁服務器、數據庫和監控工具，并且部署它們到應用服務器上。
這里有幾個開源的中間件自動化工具值得考慮：
| 名稱 | 許可證 |
|---|---|
| Ansible | GNU Public |
| SaltStack | Apache 2.0 |
| Chef | Apache 2.0 |
| Puppet | Apache or GPL |
獲取更多中間件自動化工具，查看 Opensource.com 上的其它文章：
之后的發展
這只是一個完整 DevOps 流水線的冰山一角。從 CI/CD 工具開始并且探索其他可以自動化的東西來使你的團隊更加輕松的工作。并且，尋找開源通訊工具可以幫助你的團隊一起工作的更好。
