本文作者：紅亞科技 CTO——盧興民
紅亞科技聚焦資訊技術發展，為資訊技術相關專業提供優質教學服務
背景
ChatOps 最早起源于 GitHub，它以溝通平台為中心，通過與機器人産生對話和互動，使開發人員隻需在聊天視窗即可完成 DevOps 所承載的工作。
服務 600+ 高校的 IT 實訓教學平台“青椒課堂”，為何選擇 ChatOps 來承載業務，又如何将 SaaS 工具與開源工具結合形成完整的技術方案，本篇文章将為你揭曉答案。
為什麼“複雜應用”開發測試階段需要 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 後進行版本推送，實作“應用定義”的版本化。
應用部署工具選型
在應用部署工具上選擇上使用了 CODING CD，主要基于以下的内容進行考慮：
- 應用定義及元件版本分離。
- 基于環境加載公共配置。
- 釋出啟動參數定制。
将 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 提供了常見環境的開發鏡像，但應用于自己團隊内部時，鏡像所包含的内容往往與元件相關，此時就需要定制一個适用于目前業務的開發鏡像。主要基于以下幾點考慮：
- 盡量包含實際環境中使用鏡像中的工具和常用的調試工具。
- 去除掉影響調試的緩存元件，例如 PHP 中的 OPcache。
總結
随着業務的複雜程度提高，開發測試流程中重複繁瑣的操作會變得越來越多，基于已有的 CI/CD 體系建構 ChatOps 工具是解決這種問題的一個思路，選擇适合自己團隊的方案才是最為重要。
點選立即開啟高效雲端研發工作流