有贊移動關於權限與審批流程的標準化

1、背景

有贊移動有weex發佈平臺、移動配置中心平臺、App分發平臺、熱修復平臺等。這些平臺都須要發佈，而發佈就須要規範化，須要審批制度。若是爲各個平臺開發這個審批流程，看起來是一種浪費。

首先想到第一種方案：接入現有的先後端發佈平臺。

移動側的發佈基本是配置類的發佈，跟後端應用和前端應用的發佈不同。後端應用和前端應用的發佈都是將指定的內容推送到某臺或者多臺機器進行部署、啓動。二者若是硬要作抽象，成本反而更大，並且不易維護。因此放棄第一種方案。

那麼是否能夠抽象成單獨的統一管理平臺，進行標準化呢？

2、梳理

首先看一下標準的發佈審批流程通常是怎麼樣的？

第一步：申請人提交發布單

第二步：負責人審批

第三步：申請人發佈

而這裏申請人和負責人就是以權限爲區分。

通常的權限角色有模塊負責人、開發、運營、測試等。

其中，審批人是模塊負責人，而申請人能夠是開發，也能夠是模塊負責人。而二方平臺還能夠根據不一樣角色賦予不一樣的權限。

2.1 權限

權限實質上指的是用戶和模塊之間的關係。因此只須要模塊的惟一標識和用戶的惟一標識，用戶的惟一標識由統一的用戶認證服務提供，模塊的惟一標識由各個二方平臺提供。對於二方平臺來講，只要提供模塊惟一標識和用戶惟一標識，而後得到角色便可，而後根據角色進行相應的操做。因此這一層就能夠單獨抽離出來。現有的先後端發佈平臺也已經驗證了這一點。

2.2 審批

審批須要哪些元素呢？ 申請人、審批內容、審批人、審批狀態。其中審批內容在各個二方平臺是不同的。

儘管如此，仍是能夠抽象成兩個字段：審批單惟一標識和用於查看審批詳情的連接。這兩個字段均可以由二方平臺提供。因此審批也是能夠作抽象的。

3、設計

如何設計這個統一的平臺將權限與審批流程標準化呢？首先看一下二方平臺和有贊移動權限與審批統一管理平臺（如下簡稱統一管理平臺）的交互流程圖。

首先，二方平臺和統一管理平臺都要依賴CAS，CAS是有讚的用戶認證平臺。這樣，就能夠基於同個用戶進行權限管理。

3.1 二方平臺與統一管理平臺的交互

從圖中能夠看到，二方平臺與統一管理平臺主要有四大交互：添加模塊、獲取權限、提交發布單、獲取發佈單狀態。

3.1.1 添加模塊

模塊是最小的可配置權限的元素，好比weex發佈平臺對應的各個模塊、熱修復平臺對應的App等。須要在發佈平臺配置權限的時候，就須要選擇模塊。
因此，二方平臺在註冊模塊的時候，須要同步到發佈平臺，帶上平臺和模塊的惟一標識，以及模塊的名稱，加強可讀性。

3.1.2 獲取權限

權限由統一管理平臺管理，模塊負責人能夠編輯權限，其餘人能夠申請權限。

二方平臺經過攜帶平臺和模塊的惟一標識，以及用戶的惟一標識，從統一管理平臺獲取權限，依賴權限進行相應的操做。

3.1.3 提交發布單

移動側的各個二方平臺發佈的內容基本是配置類的信息，配置的內容、格式、條件都不同。

好比weex發佈的內容包含平臺、環境、規則、描述，和頁面列表，如圖：

而熱修復平臺發佈的內容包括應用版本、補丁文件、描述、下發模式（規則）等：

首先想到的是將這些配置類內容抽象成內容、規則和描述。可是若是這麼作的話，各個二方平臺展現時各自須要從新解析，也不便於根據內容裏的字段進行搜索。

因此，各個二方平臺的發佈頁面由各個平臺本身開發，提交發布單的時候，再將惟一標識符（包含平臺、模塊、發佈單ID等)和發佈單詳情的url傳給統一管理平臺，統一管理平臺來維護一張審批表，包含發佈單惟一標識符、狀態、申請人、發佈單詳情url等。

其中，狀態包括待審批、審批經過、審批拒絕。發佈單詳情url用於審批人在統一管理平臺審批時能夠跳轉查看審批內容詳情。

3.1.4 獲取發佈單狀態

各個二方平臺有各自的發佈單詳情表，而審批狀態統一從統一管理平臺獲取。二方平臺經過審批狀態，判斷是否能夠進行發佈。

3.2 優化改進

3.2.1 權限申請入口

考慮到每次須要添加的權限的時候，都須要模塊負責人去權限管理頁面添加，對於負責人來講是一種沒必要要的時間浪費。因而增長權限申請的入口，不只在統一管理平臺可見，在各個二方平臺也開發入口，經過再url後面攜帶平臺、模塊、角色等參數，跳轉到統一管理平臺的權限申請頁面。申請後，模塊負責人會收到通知（企業微信、釘釘或者其餘形式），贊成申請便可。既減小了模塊負責人的操做成本，也減小了模塊負責人與申請人的溝通成本。

3.2.2 審批通知與審批結果通知

申請人發起發佈申請後，審批人會實時收到通知。而審批人經過/拒絕申請後，申請人也會實時收到通知。減小了兩者的溝通成本。

3.2.3 容許關閉審批

可能有一些模塊的特殊性（測試模塊），或者環境的特殊性（有讚的網絡環境分爲Daily、QA、Pre、Prod），有些模塊在某些環境須要關閉審批，這樣更能提升效率。不然在測試環境，每次發佈都要審批，着實比較麻煩。

4、總結

由此，全部的審批操做和權限操做都在統一管理平臺進行。添加模塊、提交發布單和發佈、回滾等操做在各自的二方平臺進行。統一管理平臺以Dubbo的形式向二方平臺提供統一標準接口：

• 接口一：在統一管理平臺建立模塊
• 接口二：獲取到用戶在發佈平臺的角色
• 接口三：在統一管理平臺建立/撤回審批單
• 接口四：獲取審批單的進度

統一管理平臺的後臺操做頁面，主要是權限管理界面和審批界面。

由此就將發佈的審批流程和權限管理進行了標準化。現有的二方平臺，以及未來更多二方平臺均可以經過統一管理平臺提供的接口接入，在統一管理平臺上進行權限和審批流程的管理。後續隨着二方平臺的複雜度變高，權限角色的增長，審批類型的增長均可以很方便地進行擴展和複用。

標準化意義在於下降成本，包括開發成本和使用成本。平常開發中須要更多思考，識別業務中哪些能夠標準化哪些須要個性化，而後將可標準化的部分抽象出來作成服務，對於效率和擴展性來講都是更好的選擇。