為什麼“複雜應用”開發測試階段需要 ChatOps ?

• 隨著部署工具及部署 pipeline 流程引入到整個開發迭代流程中，使用釋出單模式進行開發、測試環境的部署往往需要開啟多個 web 控制檯，對於日常開發迭代來說較為繁瑣。

• 如今專案的開發往往會存在多個 git repo，每個 git repo 又會產生多個製品用於部署，基於手動選擇的方式對於開發人員開發、測試都非常不友好。

• 在訊息通知方面，雖然使用了 webhook 將專案協同資訊進行了群通知，但專案所有通知傳送到一個群內，造成資訊爆炸，逐漸失去通知意義。

首先來看我們團隊當前的部署流程所需要的步驟，需要經過“等待 CI 構建成功” “釋出單選擇所需製品及環境” “部署”這麼幾個流程。其中製品的選擇，在每次釋出時，都需要進行選擇，當元件較多時，則較為繁瑣。

並不是所有的場景都需要 ChatOps，這裡重點強調“複雜應用”，是因為應用複雜度提高後，會面臨配置複雜、製品複雜、流程複雜的局面，因此需要 ChatOps 工具來降低開發測試過程中的部署難度。而對於簡單的應用，例如專案初始階段的單體應用，則不必大費周折折騰複雜的工具流程，在 CI 中整合小部分自動更新測試環境的流程就很高效。

如何結合 CI/CD 體系和 IM 開放平臺構建 ChatOps 工具

當前 CI/CD 落地的現狀及選型思考

持續整合

持續整合是所有流程的基礎，目標也很明確，就是將構建環境、製品型別進行統一，便於進行後續的部署使用。在當前容器化流程的背景下，我們也是選擇了容器映象作為最終制品，開發人員統一產出容器映象，方便進行部署。

所有的程式碼倉庫，無論複雜與否，都會建立 Jenkinsfile 進行構建。流程如下圖所示。

應用定義選型

在應用定義的選擇上，經歷了最初的 PaaS 平臺自定義應用模型、程式碼倉庫儲存靜態 Manifest 檔案後，最終選擇了 helm 作為應用定義的工具，主要基於以下幾個方面考慮。

• 部署方式簡單，可以通過單條命令直接進行安裝，即使在工具較為匱乏的私有化環境中脫離部署工具也可使用一條命令進行部署和升級。

• 使用模板進行定義，便於進行多個副本部署及差異化配置。

• 通過製品庫來儲存 helm chart，dev 環境使用構建號進行版本推送，生產環境通過 helm 倉庫打 tag 後進行版本推送，實現“應用定義”的版本化。

應用部署工具選型

在應用部署工具上，選擇使用 Spinnaker，主要基於以下的內容進行考慮。

• 應用定義及元件版本分離

• 基於環境載入公共配置

• 釋出啟動引數定製

部署流程定義如下圖：

將 helm chart 及容器映象作為製品輸入，通過製品繫結將 helm chart 版本與 image 版本進行分離，實現應用定義和應用元件版本的獨立配置。

使用 values 檔案引用，方便的對“某一類”環境進行統一配置，例如公用雲不同廠商間的差異化配置。

構建適合團隊的 ChatOps 體系

ChatOps 工具構建的目標

• 解決訊息雜而亂的問題，以專案迭代為粒度進行訊息的分類、建立 IM 群組。

• 解決開發測試環境建立繁瑣、需要口頭約定的問題，以專案迭代為粒度建立獨立的測試環境。

• 儘量避免 web 控制檯操作。

• 迭代結束後自動清理環境、群。

開發測試過程流程梳理

如下圖所示，我們對開發測試的整個部署流程進行梳理。其中最為繁瑣的、需要多次人工操作的部分就是“部署配置” + "版本選擇"這個過程，如何將製品按照一定的規則更新到對應的環境中，並且能夠記住當前的選擇便是這個流程的關鍵。

首先，我們需要將整個部署流程進行模板化，這裡我們使用 namespace 作環境間的隔離，將環境中最關鍵的兩個因素，namespace、訪問域名作為啟動引數，將單一的部署流水線模板化。

通知隔離

通過接管 webhook 事件，將原有的專案協同通知進行重新分發。當專案協同工具中產生迭代建立時，自動觸發建立一個預製好 devops 機器人的群，並利用 IM 提供的卡片能力對訊息進行優化，增加便捷的入口。專案協同事項變更時，自動對群內成員進行增刪。同時，環境也與當前的迭代關聯，在需要時通過聊天指令進行快速建立。在迭代結束時，回收群、測試環境等，進行清理工作。

當前 ChatOps 主要實現以下指令:

• deploy - 喚出部署設定卡片。

• branch - 設定某個倉庫對應的分支、查詢對應制品並喚出部署卡片。

其中卡片功能分解如下圖：

當環境建立成功後， ChatOps 控制器會記錄當前環境的製品選擇，當對應的製品有更新時，會自動更新當前的環境，實現測試環境一次配置，整個迭代內自動更新。

整個流程如下圖：

開發測試階段如何快速除錯應用

在日常的開發過程中，基於上述的 ChatOps 流程進行環境的部署和更新已經能滿足大部分的需求，程式碼推送後，也可以在分鐘級做到環境的更新。

單對於聯調和測試時遇到的問題需要修改時，等待一個 CI/CD 的流程顯得非常漫長，另外開發新的功能和新元件時，想快速放入測試環境中也較為繁瑣。

因此我們在尋求一個工具，用於快速除錯開發環境。

在早年的服務端開發時，我們時常使用 sftp 外掛，將原生代碼同步到伺服器上進行執行，那麼 nocalhost 就是容器化的 rsync 工具，nocalhost 在進入除錯模式時，把對應的 container 映象替換為指定的開發映象，並增加一個檔案同步的 sidecar，可以將本地的程式碼同步至容器中，對於指令碼型別的語言可以直接進行除錯，對於像 golang 這樣需要編譯的型別，可以在本地構建進行同步，也可以直接在容器中進行構建。

整個使用的過程中，需要留意的關鍵步驟是製作適合開發除錯使用的映象，nocalhost 提供了常見環境的開發映象，但應用於自己團隊內部時，映象所包含的內容往往與元件相關，此時就需要定製一個適用於當前業務的開發映象。主要基於以下 2 點考慮:

• 儘量包含實際環境中使用映象中的工具和常用的除錯工具。

• 去除掉影響除錯的快取元件，例如 php 中的 opcache。

總結

隨著業務的複雜程度提高，開發測試流程中重複繁瑣的操作會變得越來越多，基於已有的 CI/CD 體系構建 ChatOps 工具是解決這種問題的一個思路，選擇適合自己團隊的方案才是最為重要的。

作者

盧興民 紅亞科技 CTO

本文由部落格一文多發平臺 OpenWrite 釋出！