背景
故事要從兩年前說起，那時知乎調整了移動用戶端的釋出流程，确立了每兩周一次的固定發版周期，這期間包含了需求産生、設計、開發、測試等一系列的流程。當時業務發展的速度與現在相比并不快，整體的工作流都是圍繞着 Gitlab 、Jenkins 、Slack 等工具，即在 Jenkins 上打包和測試、在 Gitlab 上通過 MR 的方式管理代碼改動、通過 Slack 接收流程中的各項通知。
每個 MR 在建立或送出新代碼時都會自動觸發 Jenkins 打包，MR 相關各角色可以友善地安裝這個包進行驗收和測試。在 Gitlab MR 中，我們設定了如下圖的一系列标簽（Labels）用來标記各角色的驗收結果，隻有集齊這些标簽的 MR 才能被合并，其中 Dev 、PM 、Design 、QA 标簽分别代表開發自測通過、産品驗收通過、設計師驗收通過以及 QA 測試通過。
一個典型的知乎用戶端 MR
不過随着知乎使用者量的快速增長，移動用戶端功能也越來越複雜，開發團隊也相應擴大，與此同時在知乎用戶端的開發和測試過程中出現了如下問題：
- 代碼耦合嚴重
- 依賴關系複雜
- 業務職責混亂
- 頻繁的代碼沖突
- 代碼難以複用
- 高風險功能影響版本釋出
- 。。。
總之，老的用戶端架構和釋出流程開發效率低、測試效率低、功能疊代慢，漸漸不再适應業務的發展。于是在 2017 年底，知乎走上了移動用戶端元件化之路，對于元件化的一些概念，這裡不再贅述。而元件化給我們帶來的新的挑戰是，如何在每次應用疊代的過程中清晰地管理大量的元件資訊、元件之間的依賴關系、應用與元件之間的依賴關系，如何能快速擷取建構結果，如何能在不同測試階段發現 Bug 時快速定位到問題所在等等。
這些新的挑戰最終轉化成需求，造就了知乎移動端元件管理平台 Athena 。将 Gitlab 、Jenkins 在日常疊代中的工作流的作用弱化，取而代之的是一個內建式一體化的平台，無論是産品、設計、開發、測試，在這個平台上可以很清晰的檢視操作所需的元件或應用資源，節省在各個工具之間上下文切換帶來的低效能，以及團隊内部溝通的成本。工具的平台化同時也代表着工作流程的規範統一，通過使用平台的權限控制，使得移動端發版工作流程更加明确統一。對于新入職的員工，無需再花費大量時間了解消化複雜的流程，隻需要按照平台的使用說明，即可快速上手工作。
多說一句，我們使用 Athena 命名平台，正是因為 Athena (希臘神話中的女神) 主司智慧和公正。我們希望 Athena 的誕生能減輕工程師在移動端開發流程中的心智負擔，并公正客觀的實作統一有效的流程規範。
架構
知乎移動用戶端元件管理平台 Athena 是基于 B/S 的架構，采用前後端分離的政策，前端主要專注于友好的互動和清晰的資源展示，後端則主要負責資源的業務邏輯處理以及與其他工具的互動。
關于前端選型，我們使用了目前趨勢迅猛的前端架構 Vue 以及官方推出的一系列生态圈産品 Vue Router, Vuex 來搭建。Vue 是一款漸進式的前端架構，這對于平時主要工作集中在後端項目的工程師相對比較友好，學習曲線沒有 React 陡峭，其提供了豐富的 API 供使用者使用，同時官方的腳手架工具 Vue CLI 可供使用者快速搭建應用。
關于後端技術選型，我們選用知乎自研的基于 tornado 的定制 Restful API 架構來搭建，選用 MySQL 負責資料存儲，同時使用知乎自研的部署釋出引擎來執行平台的部署釋出。
同時，Athena 希望在工作流中将 Gitlab 和 Jenkins 弱化，是以我們對二者的常用 API 進行了封裝供 Athena 調用，使用者隻需要在 Athena 上進行操作即可，由 Athena 觸發 Gitlab 和 Jenkins 完成各項任務。另外，使用者在 Athena 上的任何操作都會使其在 Slack 上收到即時通知。
主要功能
作為移動用戶端的元件管理平台，Athena 的主要功能表現為以下兩點：
- 元件管理
- 元件內建
元件管理
元件接入 Athena 的前提是擁有自己獨立的 Gitlab 代碼倉庫，且目錄結構符合知乎用戶端元件規範。目前 Athena 需要人工錄入元件，使用者使用「添加元件」的功能将元件接入至 Athena 平台後，Athena 會自動為該元件代碼倉庫添加 Webhook 用以監聽代碼倉庫中的變更。
同時可以看到，當使用者在平台添加元件的時候，我們設計了一些元件次元上的權限管理。隻有元件的負責人擁有平台上元件的所有操作權限，并且元件的負責人可以自定義配置元件驗收過程中所需的角色标簽 （包括 Dev 、 PM 、Design 、 QA ），配置好的角色會在元件驗收流程中做相應的驗收工作。這裡的标簽與上述 Gitlab MR 中的标簽功能一緻，有了這些标簽，我們便可以将各角色的驗收工作從 Gitlab 遷移到 Athena ，進而達到弱化 Gitlab 在流程中作用的目的。任一角色未通過驗收，該元件版本就不能作為內建候選版本。這樣我們統一了各元件的內建規範，與此同時也給予使用者一定程度的自由。
每當元件負責人在代碼倉庫中修改了元件的版本号 ，代碼倉庫的 Webhook 将會被觸發進而去調用 Athena 的接口，Athena 則會為以 Gitlab Tag 的形式為該元件建立一個新的版本。同時 Athena 還會自動釋出元件新版本的 aar（Andoid 元件）或 Framework（iOS 元件）。使用者可在 Athena 平台上浏覽元件的新版本以及此次元件更新的内容。
元件釋出流程
元件內建
元件內建是指将知乎主 App 依賴的元件更新到新的版本，在元件化之後，我們用元件內建來代替原流程中的 MR 。使用者在 Athena 上選擇元件的新版本并建構內建包來驗收，打包也是由 Athena 觸發 Jenkins 來完成的。各業務團隊各自在上文提到的元件配置中決定內建驗收參與的角色，所有角色驗收通過後，QA 便可以在 Athena 平台上将主 App 所依賴的元件更新到指定的版本。
元件內建流程
如下圖所示，使用者在指定的主 App 版本上可以找到對應元件的各個版本，對指定的版本建構內建測試包，如果此版本通過了驗收，則可以內建至相應的主 APP 版本中。
元件各版本清單
基于指定元件版本打內建測試包
如此一來，凡是接入到 Athena 平台上的元件都抛棄了原始的散養式的管理，而遵循一套統一，清晰且高效的疊代流程。元件釋出流程獨立且快速，業務團隊内部不同職能的員工溝通成本降低，工作效率提升。為今後移動端更加快速的發版奠定了基礎。
展望未來
自從 Athena 平台上線半年多來，已經經曆知乎移動端發版 30+ 次，在此期間 Athena 已經：
- 接入移動端用戶端元件總計 70+ 個
- 完成元件新版本的自動釋出共計 2500+ 次
- 完成元件內建測試包的建構 600+ 次
- 完成元件內建 400+ 次
同時用戶端的疊代流程也越來越穩定，Athena 持續為提升知乎移動端品質與釋出速度保駕護航。
我們當然不會滿足于現狀，Athena 女神的智慧也絕不僅限于此，我們計劃在後續的工作中賦予她更多的使命：
- 去 Jenkins 化
Athena 依賴 Jenkins 來實作建構任務的管理以及配置設定，維護 Athena 的同時，我們還需要維護 Jenkins 上的配置。這樣造成了維護和使用成本的上升，我們希望未來 Athena 可以完全摒棄 Jenkins 來實作建構的配置設定和執行。
- 自動化測試
目前元件的測試自動化程度還不高，同時 Athena 對自動化測試的支援也并不好，未來我們會使 Athena 接入更多自動化測試，真正實作元件的持續內建和持續釋出，提供更全面的品質保障。
- 品質資料收集與可視化
品質資料的重要性不必多說，我們希望能夠将疊代流程中各個環節的資料收集分析（靜态代碼掃描、單元測試、包大小檢查等），作為元件持續內建流程的準入規則，形成一套更加智能完善的閉環系統。
作者:鐘離無糖
出處:https://zhuanlan.zhihu.com/p/46411733