在快速的開發循環中，持續驗證系統開發結果 ，分割成小部分地儘早確認，期望開發產出能符合原始需求，或依據產出進行快速修正。 簡單來說就是儘量減少手動人力，將一些日常工作交給自動化工具。例如：環境建置、單元測試、日誌紀錄、產品部署。
持續整合 (CI) 的目的
- 降低風險。
- 減少人工手動的繁複程序。
- 可隨時產生一版可部署的版本。
- 增加系統透明度。
- 建立團隊信心。
什麼是持續性整合(CI)呢？持續性整合的目的為：針對軟體系統每個變動，能持續且自動地進行驗證。此驗證可能包含了：
- 建置 (build)
- 測試 (test)
- 程式碼分析 (source code analysis)
- 其他相關工作 (自動部署)
驗證完成後，進一步可以進行CD工作，整合自動化發佈或部署 (Continuous Delivery / Continuous Deployment) 。透過此流程可以確保軟體品質，不會因為一個錯誤變動而產生錯誤結果或崩潰(Crash)。此流程中的各類工具，也會產生一些回饋給開發者或其他角色，包含網頁/報表等等，用來追蹤並改善軟體潛藏的問題。
Source : Cisco
CI/CD 分別指 持續整合(Continuous Integration, CI)、持續部署inuous Delivery, CD)、持續交付(Continuous Deployment, CD)，後者負責範圍包括前者的內容。
在筆者看來，CI/CD 比較像是三個不同階段的任務，只有完成了前一個階段，才能進入下一個階段。
第一階段、持續整合(Continuous Integration, CI)
曾經團隊協同開發過的人，應該都有遇到在提交時，為了解決程式碼衝突，結果花上更多的時間在處理衝突的程式碼。
尤其提交間隔越久的開發者，處理程式碼的衝突，就越困難。而且還可能造成團隊的成員重複解決相同程式區塊的衝突。整合的時間越晚，整合的難度與失敗的機率就越高。
持續整合的目的，利用頻繁地提交新功能的變更，觸發自動化建置和測試，確保最新版本的軟體是可運行的。
- 版本控制: 持續整合最重要的一步，可以說，沒有版控，就沒有 CI/CD。
- 建置: 確保提交的程式碼是否可以執行的。
- 自動化測試 確保功能正常與軟體品質。
- 程式碼分析: 檢查 code style 或程式的穩健度。
第二階段、持續部署(Continuous Delivery, CD)
完成整合的階段後，接下來就是部署的階段。
不管是為了測試、驗收或上線，都一定需要進行軟體的部置。但是往往部署環境的差異，造成驗收或上線時的兵荒馬亂。
持續部署的目的，就是要快速而自動的部署，任何版本的軟體到不同的環境。為此，須採用同一個包裝好的套件 (package)，以達到 簡化組態管理(configuration management) 與 減少部署所需的時間。
另外，因為採用同一 package 進行部署的因素，必需將其組態 / 設定外部化 (configuraiton externalization)。簡單點講，就是不要將設定寫死 (hard-coded) 在程式碼。
- 發佈
- 手動測試
第三階段、持續交付(Continuous Deployment, CD)
持續交付的目標，就是 儘快將最新版本的軟體，交付到最終使用者(end-user)手中。
為達到持續交付，必需先行建立 持續整合 跟 持續部署 的機制。
持續整合的精神
持續整合是 CI/CD 最重要的一點，如果提交的程式有問題，造成整合失敗。對於發生失敗的這種情況，團隊內的成員，需要在一開始就要溝通清楚，取得共識。
對於上面提到，提交造成整合失敗的情況，常見的做法有……
- 每次提交之前，先在本機執行建置與單元測試，作為整合前的額外驗證措施。
- 造成提交失敗的人，要負責修訂錯誤。
- 建置有錯的情況下，禁止其他新功能的提交。
- 測試失敗的情況下，需立即找出問題，確保測試通過，以維持程式品質。
持續整合需要團隊內，所有成員的一同努力與堅持，才能達到良好的效果。
source:
先降, 下次再談 , 先去按摩了
沒有留言:
張貼留言