不可錯過的持續集成進階指南(2)

這時候需要改進你的 CI 系統，建立標準化的環境部署順序，在 Workflow 中增加部署預生產環境并進行灰度集成測試的流程，做好線上環境部署后的回歸測試。到這里，已經真正做到了持續交付。

持續交付并不是指軟件每一個改動都要盡快部署到產品環境中，它指的是任何的代碼修改都可以在任何時候實施部署。而“持續部署”，即自動部署到生產環境中而無需手工干預：得到一個版本后，自動部署該版本到生產環境中。實踐證明，相對獨立快速地部署新功能是一個核心競爭力，可以減輕大規模功能變更的風險。

持續部署，是相對成熟的持續集成系統。

“開發人員提交代碼，持續集成服務器獲取代碼，執行單元測試，根據測試結果決定是否部署到預演環境，如果成功部署到預演環境，進行整體驗收測試，如果測試通過，自動部署到產品環境，全程自動化高效運轉。”

第四進階 — 并行多 workflow 集成以及個性化集成，基于 Docker 的持續集成

隨著項目和團隊規模增長，模塊之間依賴關系變得復雜，如何確保代碼質量的同時，保證代碼構建的一致性和穩定性，成為一大挑戰。Docker 可以方便地以“容器化”的方式部署，它就像集裝箱一樣，打包了所有依賴，在其他服務器上部署很容易，不至于換服務器后發現各種配置文件散落一地，這樣就解決了編譯時依賴和運行時依賴的問題。

還有一個問題，開發的分支越來越多，每個活躍分支都進行環境部署和集成測試，對持續集成環境的維護成本也就越高。而 Docker 的快速啟動和鏡像倉庫是天生為 CI/CD 設計的，以前啟動一個虛擬機需要幾分鐘，而啟動 Docker 只需要幾秒鐘，讓并行的持續集成才能成為可能。

目前，比較常見的基于 Docker 進行持續集成的流程如下：

• 開發者提交代碼；

  原文轉自：http://blog.flow.ci/ci_advancedguide/

  • 共3頁:
  • 上一頁
  • 1
  • 2
  • 3
  • 下一頁