之前寫了一篇戾氣很重的文章，抱歉。

       好久沒有更新了，再次抱歉。

       最近在使用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 環境，對於整個團隊來說，好處與挑戰並行。無論如何，頻繁部署、快速交付以及開發測試流程自動化都將成為未來軟體工程的重要組成部分。