持續整合、持續交付、持續部署
1.持續整合
網際網路軟體的開發和釋出,已經形成了一套標準流程,最重要的組成部分就是持續整合(Continuous integration,簡稱CI)。
持續整合指的是,頻繁地(一天多次)將程式碼整合到主幹。
它的好處主要有兩個:
- 快速發現錯誤。
- 防止分支大幅度偏離主幹。
持續整合的目的,就是讓產品可以快速迭代,同時還能保持高質量。它的核心措施是,程式碼整合到主幹之前,必須通過自動化測試。只要有一個測試用例失敗,就不能整合。
Martin Fowler說過,“持續整合並不能消除Bug,而是讓它們非常容易發現和改正。”
2.持續交付
持續交付(Continuous delivery)指的是,頻繁地軟體版本地新版本,交付給質量團隊或者使用者,以供評審。如果評審通過,程式碼就進入生產階段。
持續交付可以看作持續整合的下一步。它強調的是,不管怎麼更新,軟體是隨時隨地可以交付的。
3.持續部署
持續部署(continuous deployment)是持續交付的下一步,指的是程式碼通過評審以後,自動部署到市場環境。
持續部署的目標是,程式碼在任何時刻都是可部署的,可以進入生產階段。
持續部署的前提是能自動化完成測試、構建、部署等步驟。它與持續交付的區別,可以參考下圖。
4.流程
根據持續整合的設計,程式碼從提交到生產,整個過程有以下幾步。
4.1提交
流程的第一步,是開發者向程式碼倉庫提交程式碼。所有後面的步驟都始於原生代碼的一次提交(commit)。
4.2測試(第一輪)
程式碼倉庫對commit操作配置了鉤子(hook),只要提交程式碼或者合併進主幹,就會跑自動化測試。
測試有好幾種。
- 單元測試:針對函式或模組的測試
- 整合測試:針對整體產品的某個功能的測試,又稱功能測試
- 端對端測試:從使用者介面直達資料庫的全鏈路測試
第一輪至少要跑單元測試。
4.3構建
通過第一輪測試,程式碼就可以合併進主幹,就算可以交付了。
交付後,就先進行構建(build),再進入第二輪測試。所謂構建,指的是將原始碼轉換為可以執行的實際程式碼,比如安裝依賴,配置各種資源(樣式表、JS指令碼、圖片)等等。
常用構建工具如下。
- Jenkins
- Travis
- Codeship
- Strider
Jenkins和Strider是開源軟體,Travis和Codeship對於開源專案可以免費使用。它們都會將構建和測試,在一次執行中執行完成。
4.4測試(第二輪)
構建完成,就要進行第二輪測試。如果第一輪已經涵蓋了所有測試內容,第二輪可以省略,當然,這時構建步驟也要移到第一輪測試前面。
第二輪是全面測試,單元測試和整合測試都會跑,有條件的話,也要做端對端測試。所有測試以自動化為主,少數無法自動化的測試用例,就要人工跑。
需要強調的是,新版本的每一個更新點都必須測試到。如果測試的覆蓋率不高,進入後面的部署階段後,很可能會出現嚴重的問題。
4.5部署
通過了第二輪測試,當前程式碼就是一個可以直接部署的版本(artifact)。將這個版本的所有檔案打包( tar filename.tar * )存檔,發到生產伺服器。
生產伺服器將打包檔案,解包成本地的一個目錄,再將執行路徑的符號連結(symlink)指向這個目錄,然後重新啟動應用。這方面的部署工具有Ansible,Chef,Puppet等。
4.6回滾
一旦當前版本發生問題,就要回滾到上一個版本的構建結果。最簡單的做法就是修改一下符號連結,指向上一個版本的目錄。