什么是集成？
在傳統的軟件開發中，集成通常是在每個人完成工作后的項目結束時進行
實際栗子
- 現在有一個電商平台需要開發
- 由於電商平台模塊眾多，需要不同的開發人員開發不同的模塊【本地開發】
- 最后將所有人開發好的代碼集成到一個系統中【提交代碼到遠程倉庫】
- 集成完成后需要對其進行部署上線
- 隨着時間的推移，該系統無論是 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 自動化
- 開發人員提交代碼到編譯、測試、部署的全流程都不需要人工干預，完全自動化執行
持續部署的優勢
這一策略加快了代碼提交到功能上線的速度，保證新的功能能夠第一時間部署到生產環境並被使用
持續部署的不足
- 全流程自動化，無法保證質量，哪一步出問題了無法提前預知
- 目前一個產品正常發布到生產環境，還是需要測試工程師進行手工功能測試的
- 所以持續交付更主流，因為它算半自動化