之前寫了一篇戾氣很重的文章，抱歉。
好久沒有更新了，再次抱歉。
最近在使用Jenkins弄CI，遇到了之前就遇到，但是沒當回事的三個概念，查了一些資料，發現了一些我個人認爲比較好的文章，整理了一下，在這裏記錄下。
順便安利一篇文章：你的微服務敢於持續交付嗎？
本文主要綜合了兩篇別人的文章：
https://www.jianshu.com/p/2c6ebe34744a，另一篇忘記了，如果有認出來的，麻煩告知。（圖片是自動水印。）
—————————————————————————————————————————————————
一. 持續集成
1. 概念
持續集成是指軟件個人研發的部分向軟件整體部分交付，頻繁進行集成以便更快地發現其中的錯誤。“持續集成”源自於極限編程（XP），是 XP 最初的 12 種實踐之一。
2. 目的
持續集成的目的，就是讓產品可以快速迭代，同時還能保持高質量。它的核心措施是，代碼集成到主幹之前，必須通過自動化測試。只要有一個測試用例失敗，就不能集成。
Martin Fowler 說過，”持續集成並不能消除 Bug，而是讓它們非常容易發現和改正。”
3. CI需要具備的條件：
- 全面的自動化測試。這是實踐持續集成&持續部署的基礎，同時，選擇合適的自動化測試工具也極其重要；
- 靈活的基礎設施。容器，虛擬機的存在讓開發人員和 QA 人員不必再大費周折；
- 版本控制工具。如 Git，CVS，SVN 等；
- 自動化的構建和軟件發佈流程的工具，如 Jenkins，flow.ci；
- 反饋機制。如構建/測試的失敗，可以快速地反饋到相關負責人，以儘快解決達到一個更穩定的版本。
4. 持續集成的優點
- “快速失敗”，在對產品沒有風險的情況下進行測試，並快速響應；
- 最大限度地減少風險，降低修復錯誤代碼的成本；
- 將重複性的手工流程自動化，讓工程師更加專注於代碼；
- 保持頻繁部署，快速生成可部署的軟件；
- 提高項目的能見度，方便團隊成員瞭解項目的進度和成熟度；
- 增強開發人員對軟件產品的信心，幫助建立更好的工程師文化。
5. 主要好處
兩個：
- 快速發現錯誤。每完成一點更新，就集成到主幹，可以快速發現錯誤，定位錯誤也比較容易。
- 防止分支大幅偏離主幹。如果不是經常集成，主幹又在不斷更新，會導致以後集成的難度變大，甚至難以集成。
6. 持續集成，該從何入手
最重要的一環是選擇合適的持續集成系統。是搭建私有部署還是選擇託管型持續集成系統，關鍵在於團隊運行的基礎設施，團隊對持續集成系統的資源投入力度。
對比一下私有部署和託管型持續集成系統，或許能幫助你更好地做出選擇。
Self Hosted CI 指的是將軟件部署在公司的機房或內網中，需要提供多臺服務器來完成 CI 系統的運轉，同時需要對不同機器之間進行環境配置。比如Maven 或 Gradle 或 Jenkins ，他們的特點是自由開源，且文檔支持廣泛。優點在於對構建環境有完全的控制權，能夠實現完全定製。但需要搭建環境和配置、維護成本高，需要買專門的機器，花費較多人力物力且更新遷移風險高；
Hosted CI 指的是由 SaaS 型的 CI 服務，全程在線進行構建配置，不需要考慮裝機器，裝軟件，環境搭建等成本。常見的有 CircleCI，Codeship 和TravisCI 等，還有國內最新的持續集成服務——flow.ci 。SaaS 型的 CI 的特點在於無需額外機器，幾分鐘就可以用起來。可以根據你的需要動態調度資源。省時，省心，省力。
整體而言，Jenkins過去一直是大部分公司的選擇，但這個現象正在發生改變，隨着公有云服務、Docker，SaaS 的普及，越來越多的企業開始選擇 Hosted CI，也就是託管型持續集成系統。
另外，在選擇合適的持續集成服務時，還需要考量系統的靈活度以適應公司不同階段的開發測試需求。
選擇持續集成系統只是持續集成應用的其中一步，還需要建立合適的持續集成文化比如代碼質量管控、測試文化等。做好持續集成，可爲持續交付與持續部署打好堅實基礎。
7. 流程
根據持續集成的設計，代碼從提交到生產，整個過程有以下幾步。
（1）提交
流程的第一步，是開發者向代碼倉庫提交代碼。所有後面的步驟都始於本地代碼的一次提交(commit)。
（2）測試(第一輪)
代碼倉庫對 commit 操作配置了鉤子(hook)，只要提交代碼或者合併進主幹，就會跑自動化測試。
測試有好幾種：
- 單元測試：針對函數或模塊的測試
- 集成測試：針對整體產品的某個功能的測試，又稱功能測試
- 端對端測試：從用戶界面直達數據庫的全鏈路測試
第一輪至少要跑單元測試。
（3）構建
通過第一輪測試，代碼就可以合併進主幹，就算可以交付了。
交付後，就先進行構建(build)，再進入第二輪測試。所謂構建，指的是將源碼轉換爲可以運行的實際代碼，比如安裝依賴，配置各種資源(樣式表、JS 腳本、圖片)等等。
常用的構建工具如下：
- Jenkins
- Travis
- Codeship
- Strider
Jenkins 和 Strider 是開源軟件，Travis 和 Codeship 對於開源項目可以免費使用。它們都會將構建和測試，在一次運行中執行完成。
（4）測試(第二輪)
構建完成，就要進行第二輪測試。如果第一輪已經涵蓋了所有測試內容，第二輪可以省略，當然，這時構建步驟也要移到第一輪測試前面。
第二輪是全面測試，單元測試和集成測試都會跑，有條件的話，也要做端對端測試。所有測試以自動化爲主，少數無法自動化的測試用例，就要人工跑。
需要強調的是，新版本的每一個更新點都必須測試到。如果測試的覆蓋率不高，進入後面的部署階段後，很可能會出現嚴重的問題。
（5）部署
通過了第二輪測試，當前代碼就是一個可以直接部署的版本(artifact)。將這個版本的所有文件打包( tar filename.tar * )存檔，發到生產服務器。
生產服務器將打包文件，解包成本地的一個目錄，再將運行路徑的符號鏈接(symlink)指向這個目錄，然後重新啓動應用。這方面的部署工具有 Ansible，Chef，Puppet等。
（6）回滾
一旦當前版本發生問題，就要回滾到上一個版本的構建結果。最簡單的做法就是修改一下符號鏈接，指向上一個版本的目錄。
*************************************************************************************************************
二. 持續交付
1.概念
持續交付在持續集成的基礎上，將集成後的代碼部署到更貼近真實運行環境的「類生產環境」中。給質量團隊或者用戶，以供評審。如果評審通過，代碼就進入生產階段。持續交付優先於整個產品生命週期的軟件部署，建立在高水平自動化持續集成之上。
2.目的
持續交付用來確保讓代碼能夠快速、安全的部署到產品環境中，它通過將每一次改動都提交到一個模擬產品環境中，使用嚴格的自動化測試，確保業務應用和服務能符合預期。
持續交付可以看作持續集成的下一步。它強調的是，不管怎麼更新，軟件是隨時隨地可以交付的。
試想想，如果說等到所有東西都完成了才向下個環節交付，導致所有的問題只能再最後才爆發出來，解決成本巨大甚至無法解決。比如，我們完成單元測試後，可以把代碼部署到連接數據庫的 Staging 環境中進行更多的自動化測試。如果代碼沒有問題，可以繼續手動部署到生產環境中。當然，持續交付並不是指軟件每一個改動都要儘快部署到產品環境中，它指的是任何的代碼修改都可以在任何時候實施部署。
3.持續交付的好處
持續交付和持續集成的優點非常相似：
- 快速發佈。能夠應對業務需求，並更快地實現軟件價值。
- 編碼->測試->上線->交付的頻繁迭代週期縮短，同時獲得迅速反饋；
- 高質量的軟件發佈標準。整個交付過程標準化、可重複、可靠，
- 整個交付過程進度可視化，方便團隊人員瞭解項目成熟度；
- 更先進的團隊協作方式。從需求分析、產品的用戶體驗到交互 設計、開發、測試、運維等角色密切協作，相比於傳統的瀑布式軟件團隊，更少浪費。
*************************************************************************************************************
三. 持續部署
1.概念
持續部署(continuous deployment)是持續交付的下一步或者說更高階段，指的是代碼通過評審以後（或者是通過自動化測試以後），自動部署到生產環境。持續部署是持續交付的最高階段。這意味着，所有通過了一系列的自動化測試的改動都將自動部署到生產環境。它也可以被稱爲“Continuous Release”。 大多數的公司如果沒有制度的約束或其它條件的影響，都應該以持續部署爲目標。
持續部署(continuous deployment)是持續交付的下一步，指的是代碼通過評審以後，自動部署到生產環境。
2.目標
持續部署的目標是，代碼在任何時刻都是可部署的，可以進入生產階段。
有很多的業務場景裏，一種業務需要等待另外的功能特徵出現才能上線，這使得持續部署成爲不可能。雖然使用功能切換能解決很多這樣的情況，但並不是每次都會這樣。所以，持續部署是否適合你的公司是基於你們的業務需求——而不是技術限制。
爲什麼說持續部署是理想的工作流程？
“開發人員提交代碼，持續集成服務器獲取代碼，執行單元測試，根據測試結果決定是否部署到預演環境，如果成功部署到預演環境，進行整體驗收測試，如果測試通過，自動部署到產品環境，全程自動化高效運轉。”
實際上，產品在從需求到部署的過程中，會經歷若干種不同的環境，例如 QA 環境、各種自動化測試運行環境、生產環境等。這些環境的搭建、配置、管理，產品在不同環 境中的具體部署，狀況是比較非常複雜的，從頭到尾地全自動持續部署的確困難。那麼，如果能做到持續交付，保證代碼在模擬環境沒問題，也許團隊成員做到真正的心理有數。
3.持續部署的優點
持續部署主要好處是，可以相對獨立地部署新的功能，並能快速地收集真實用戶的反饋。
“You build it, you run it”，這是 Amazon 一年可以完成 5000 萬次部署，平均每個工程師每天部署超過 50 次的核心祕籍。
4.持續部署和儲蓄交付區別
持續部署的前提是能自動化完成測試、構建、部署等步驟。它與持續交付的區別，可以參考下圖：
雖然持續部署並不適合所有公司，但持續交付絕對應該是每個公司需要追求的目標。
四. 最後
「持續集成（ContinuousIntegration）」、「持續交付（Continuous Delivery）」和「持續部署（Continuous Deployment）」提供了一個優秀的 DevOps 環境，對於整個團隊來說，好處與挑戰並行。無論如何，頻繁部署、快速交付以及開發測試流程自動化都將成爲未來軟件工程的重要組成部分。