你真的懂持續整合、持續交付、持續部署嗎？！
阿新 • • 發佈：2020-11-19
什麼是整合？
在傳統的軟體開發中，整合通常是在每個人完成工作後的專案結束時進行
實際栗子
- 現在有一個電商平臺需要開發
- 由於電商平臺模組眾多，需要不同的開發人員開發不同的模組【本地開發】
- 最後將所有人開發好的程式碼整合到一個系統中【提交程式碼到遠端倉庫】
- 整合完成後需要對其進行部署上線
- 隨著時間的推移，該系統無論是 Bug 修復，還是新功能開發，後續都需要對系統進行不斷的更新迭代
- 重點：所有人最終開發完才整合
什麼是持續整合 CI？
- 持續整合指的是，頻繁地（一天多次）將所有開發者的程式碼整合到主幹
- 簡單理解：重複整合的工作
持續整合的流程
- 開發人員（10101）提交程式碼到 Source Repository （原始碼倉庫，如 Gitlab）
- 有程式碼更新到程式碼倉庫後，會通過 WebHook 觸發 CI Server（持續整合伺服器，如 Jenkins）的相關功能，執行編譯-測試-輸出結果的流程
- CI Server 會將執行結果返回給開發人員
注意
這裡的測試並不是常規的功能測試，而是針對程式碼的單元測試
持續整合的好處
快速發現錯誤
- 每完成一點更新，就整合到主幹，相當於將一個複雜的模組細分成一個個小模組
- 每次小模組整合後再進行測試，可以快速發現錯誤，定位錯誤更加容易
節省人力成本，加快軟體開發進度
- 如果 Build-Test 這種重複性工作需要人工執行將會耗費很多時間
- 現在交給 CI Server 自動化執行，節約了很多時間，從而投入到有價值的工作中去
控制開發流程，實時交付
- 細分的程式碼提交，可以更容易判斷當前的開發進度
- 這讓管理者更容易管控整個開發流程，從而保證產品實時交付
易於 CodeReview
對於大塊工作的切分自然也有助於做 CodeReview
持續整合的核心
確保新增的程式碼能夠與原有程式碼正確的整合
持續整合的目的
讓產品可以快速迭代，同時還能保持高質量，簡化工作流程
核心措施
- 程式碼整合到主幹之前，先進行自動化單元測試
- 只要有一個測試用例失敗，就不能整合
- 持續整合並不能完全的消除 Bug，而是讓它們非常容易發現和改正
什麼情況下需要持續整合
- 如果專案開發的規模比較小，就不需要持續整合
- 如果專案很大，需要不斷新增新功能或不斷的升級產品，代表需要反覆整合，這個時候就需要用到持續整合來簡化我們的工作
重點
- 持續整合僅僅是讓所有開發提交的程式碼成功整合到系統中並正常協同工作
- 但並沒有經過測試工程師的測試和嚴重，所以整合的程式碼並不能馬上釋出到生產環境
什麼是持續交付 CD？
wiki 給的說明
持續交付是一種軟體工程方法，團隊可以在短時間內生產軟體，以確保可以隨時可靠地釋出軟體，並且在釋出軟體時，可以手動進行釋出。
簡單理解
頻繁地將軟體的新版本，交付給質量團隊或者使用者，以供測試/評審。如果測試/評審通過，程式碼就進入生產階段
持續交付的流程
- 程式碼提交
- 單元測試
- 整合程式碼
- 測試（Test）：這裡不僅僅是單元測試，還可能包含功能測試、整合測試、系統測試等
- 先部署到預發環境（預生產環境，Staging）：測試人員在預發環境進行產品的主流程驗證，驗證通過再執行下一步
- 手動部署到生產環境（Production）：開發手動部署
持續交付的重點
- 持續整合的重點是程式碼，但持續交付的重點是可交付的產品
- 可交付的產品一定要有達標的質量，確保產品在生產環境沒問題，所以在成功整合程式碼之後，還需要進行測試（TEST）
什麼是持續部署 CD？
wiki 給的說明
通過自動化部署的手段將軟體功能頻繁的進行交付
通俗理解
- 持續部署是持續交付的下一步
- 程式碼在任何時刻都能部署
- 最後將部署到生產環境的過程自動化
和持續交付的區別
- 持續交付：程式碼最終部署到生產環境的過程是手動的（Manual）
- 持續部署：程式碼最終部署到生產環境的過程是自動化的（Auto）
持續部署的流程
- 將最後一步的 Production 自動化
- 開發人員提交程式碼到編譯、測試、部署的全流程都不需要人工干預，完全自動化執行
持續部署的優勢
這一策略加快了程式碼提交到功能上線的速度，保證新的功能能夠第一時間部署到生產環境並被使用
持續部署的不足
- 全流程自動化，無法保證質量，哪一步出問題了無法提前預知
- 目前一個產品正常釋出到生產環境，還是需要測試工程師進行手工功能測試的
- 所以持續交付更主流，因為它算半自動化