軟件工程中的部署管道（CI/CD）

時間 2021-01-19

標籤 git github 服務器架構 ide 工具單元測試測試版本控制調試欄目 Git 简体版

原文原文鏈接

軟件工程團隊中的管道是一組自動化的流程，使開發人員和DevOps專業人員可以可靠，高效地編譯，構建並將代碼部署到生產計算平臺。沒有硬性規定能夠說明管道須要什麼樣的內容以及必須使用的工具，可是管道最多見的組件是：構建自動化/持續集成，測試自動化和部署自動化。git

管道一般由一組工具組成，這些工具一般分爲如下幾類：github

源代碼控制
構建工具
容器化
配置管理
監控方式

軟件交付管道的主要目標是自動化，在管道的任何步驟之中或之間都無需手工步驟或進行任何更改。手動執行這些無聊且重複的任務時，確實會發生人爲錯誤，而且最終會因部署不足而影響可交付成果的能力以及潛在的SLA。服務器

部署管道

部署管道是從版本控制中獲取代碼並以自動化方式將其提供給應用程序用戶的過程。當一組開發人員從事項目或功能時，他們須要可靠且有效的方式來構建，測試和部署其工做。從歷史上看，這將是一個手動過程，涉及不少溝通和不少人爲錯誤。架構

典型的部署流程的階段以下：ide

版本控制

一般，從事代碼工做的軟件開發人員會將所作的更改提交到源代碼管理中（例如github）。提交源代碼管理後，將啓動部署管道的第一階段，該階段將觸發代碼編譯，單元測試，代碼分析和安裝程序建立。若是全部這些步驟都成功完成，則可執行文件將被組裝成二進制文件，並存儲到工件存儲庫中以備後用。工具

驗收測試

驗收測試是對編譯/構建的代碼運行一系列測試，以針對企業設置的預約義驗收標準進行測試的過程。單元測試

獨立部署

獨立部署是將通過編譯和測試的工件部署到開發環境的過程。開發環境應該（理想狀況下）是生產環境的副本，或者在最壞的狀況下很是類似。這使軟件能夠在基礎架構等生產環境中進行功能測試，以準備進行任何進一步的自動化或手動測試。測試

生產部署

此過程一般由Operations或DevOps團隊處理。這應該是與獨立部署很是類似的過程，而且應該將代碼實時交付給生產服務器。一般，此過程將涉及Blue/Green部署或Canary發佈，以在出現不可預見的問題時容許零停機時間部署和輕鬆的版本回滾。在沒有零停機時間部署能力的狀況下，一般會與企業協商發佈窗口。版本控制

持續集成和持續交付管道

持續集成（CI）是一種實踐，開發人員天天屢次將其代碼檢入版本控制的存儲庫中。這些簽入會觸發自動構建管道，從而能夠快速，輕鬆地定位錯誤檢測。調試

CI的主要優勢是：

較小的更改更易於集成到較大的代碼庫中。
其餘團隊成員更容易看到您所作的工做
儘早發現較大工做中的錯誤，使其更易於修復，從而減小調試工做
一致的代碼編譯/構建測試
較少的集成問題，可快速交付代碼

持續交付（CD）是使開發人員和運營工程師可以可靠，快速且可持續地將錯誤修復，功能和配置更改交付到生產中的過程。連續交付提供了例行執行的代碼交付管道的優點，能夠放心地按需執行這些代碼。

CD的優勢是：

較低風險發佈–藍色/綠色部署和Canary發佈容許零停機部署，用戶沒法檢測到，而且相對輕鬆地回滾到先前版本。
更快的錯誤修復和功能交付–使用CI＆CD，當完成功能或錯誤修復並經過了驗收和集成測試後，CD和CD管道能夠將其快速交付生產。
節省成本–持續交付使團隊能夠小批量處理功能和錯誤修復，這意味着能夠更快地收到用戶反饋。這樣就能夠進行更改，從而減小了項目的總時間和成本。

藍色/綠色部署

利用藍/綠部署過程，能夠經過在生產環境中建立一個命名爲「藍」和「綠」的鏡像副原本減小風險和停機時間。在任何給定時間，只有一種環境處於活動狀態，以提供實時生產流量。在部署期間，將軟件部署到非實時環境中-意味着生產流量在此過程當中不受影響。針對當前非活動環境運行測試，一旦全部測試都知足預約義的標準，則流量將切換到非活動環境以使其處於活動狀態。在下一個部署中將重複此過程，而原始實時環境如今將變爲非實時環境。