前言
最近公司要搞CICD，希望把公司內部所有API都統(tǒng)一起來管理，從立項、需求調研、產品調研、部署以及實施，前后總共搞了兩個多月，特此記錄下來，希望能夠幫到大家。
項目背景
公司是國內做外貿電商平臺的頭部企業(yè)之一，研發(fā)團隊130人左右，內部分為多個事業(yè)部，每個事業(yè)部內有多條產品線，每條產品線下有多個產品團隊。每個產品團隊使用不同的開發(fā)工具，代碼和API的設計沒有明確的設計規(guī)范，并且各自使用的工具也不一樣。在公司項目快速發(fā)展的時候，每個產品團隊都在忙著開發(fā)，因此研發(fā)管理的問題并不突出，雖然此前出現(xiàn)過幾次關于統(tǒng)一研發(fā)測試工具的討論，但最終因為項目排期問題不了了之。
從今年年初開始出現(xiàn)過幾次比較大的項目事故，因為迭代周期太短，測試覆蓋度不夠，導致項目上線之后優(yōu)惠券系統(tǒng)有異常損失了一點錢，因此從公司高層開始推研發(fā)管理改革，什么cicd、敏捷開發(fā)、代碼審查、API管理、自動化測試啥的都要搞一套。整個項目從3月份立項到5月底正式完成，在經過6月一個月的實踐之后得到不錯的反饋。
面臨的問題（需求調研）
在經過一周左右的需求調研，把內部大部分團隊的API管理需求整理為以下8點：
1.API文檔管理工具不統(tǒng)一，編寫效率低下，不方便分享。
2.對于API的設計規(guī)范不統(tǒng)一，不同團隊之間的API對接非常麻煩，有用Rest的，也有表單的和json的。
3.API文檔記錄的內容不夠詳細，經常缺漏字段，導致對接和測試過程中增加了很多溝通成本。
4.需要mock?api模擬后端請求，讓前端可以脫離后端進行對接和測試。
5.測試人員同時使用多個工具（API文檔管理、測試、用例編寫），測試和溝通效率低下。
6.API變更的時候無法及時通知相關人員，只能在釘釘上去喊人或者是當面溝通。對于API的變更也沒有詳細的記錄。
7.測試人員水平層次不齊，沒有辦法按需編寫詳細的測試用例。通過腳本寫用例也不方便維護。
8.希望有API的自動化測試，方便對一些復雜的場景進行測試，比如支付的流程。
說實話當時一看到需求覺得頭都大了，首先是需求很雜，不僅有API文檔管理的需求，還有測試和自動化測試，還要能方便上手。一開始是希望專門拉個團隊做這事，但接到需求之后內部討論了一下覺得成本太高，大家也沒做過，何況實施周期比較短（只有兩個月），自己搞是不可能的（估算了一下如果要搞一個能用的可能得5個人搞個至少半年），轉而從現(xiàn)有的市面產品中尋找解決方案。
產品調研第一階段
產品調研的思路很簡單：
1.有免費或者開源的最好，其次才是付費的
2.能至少滿足80%的需求
3.能夠離線私有化部署
一開始我們想到大家平時用得比較多的Postman、Swagger和Jmeter，理由首先是他們都是免費的，其次是對這三個產品比較熟悉，上手比較快。但是把經過一輪調研之后還是淘汰掉，原因也很簡單：
1.缺乏足夠強的API文檔管理，Postman的文檔太簡單，Jmeter缺少這塊功能，Swagger需要在代碼里寫注解，但是我們之前的文檔都是寫在word里面的，使用習慣不一樣。
2.團隊協(xié)作功能太弱，對于130人左右的研發(fā)團隊，以上三個產品都像是單機的產品，后面我們試用了Postman的付費版，覺得依然不符合國內用戶的使用習慣，更像是一個測試工具，而非管理平臺。
3.無法滿足快速編寫測試用例和自動化測試的需求。
4.無法做到API變更通知和版本管理。
產品調研第二階段
于是我們就接著找目前市面上的API管理平臺，得到以下的清單：
1.EOLINKER API?Studio
2.RAP
3.NEI
4.APIZZA
5.Doclever
最值得一提的是EOLINKER?API?Studio，EOLINKER是一家專門做API相關產品的公司，什么API管理、自動化測試、監(jiān)控、微服務網(wǎng)關等等都有，甚至還有數(shù)據(jù)庫管理和測試用例管理等等的產品，API?Studio只是其中一款產品，主要做API的研發(fā)管理和自動化測試，從產品的功能上看是能滿足我們的絕大部分的需求。但是要吐槽的是EOLINKER這個名字實在不好發(fā)音，一開始打電話給他們客服壓根不知道怎么叫，后面才知道原來是Easy?Open?Linker的縮寫。。。。
RAP是阿里媽媽團隊做的一個開源產品，做了有很多年，但是目前的功能還在是太弱了，和淘寶的朋友打聽了一下原來他們內部也不用（但他們內部有一個aone系統(tǒng)做得很強），所以就放棄了。
NEI是網(wǎng)易的API管理平臺，測試功能太弱并且不支持私有化部署，放棄。
APIZZA是一個創(chuàng)業(yè)團隊做的，界面直接照搬Postman，但是功能相比Postman弱很多，亮點應該是簡單上手快，定位小微型團隊，也不支持私有化部署。同樣要吐槽的是名字，以為是賣批薩的。。。
Doclever是一個個人開源項目，功能比APIZZA強一點，但是作者已經停止維護了，略感可惜。
所以一輪比較下來發(fā)現(xiàn)其實沒有啥可選的，國內的API管理產品的頭部效應太明顯，API?Studio無論是功能完善度還是產品整體成熟度都比另外幾個要好很多。我們先是試用了EOLINKER的線上免費版，覺得功能已經很強了，于是在項目進行到第三周的時候聯(lián)系了他們的客服申請私有云版本試用，申請之后有一個半月的試用期。
部署和實施
這應該是整個項目最難的部分，難點在于給全公司的產品團隊普及一個新的產品并且融入到工作流程里面。首先我們找到了一個項目進度不算緊張的團隊，讓EOLINKER的培訓講師遠程培訓了一次（如果上門培訓需要額外付費，但是試用過程中可以有一次免費的遠程培訓），然后我們觀察了團隊一周的時間，并且發(fā)布了調查問卷去了解團隊的使用情況。經過一周的使用之后，研發(fā)團隊的成員覺得還不錯，上手新產品并不需要很久，同時也給出了使用過程中的問題，我們再把問題反饋給EOLINKER那邊進行答疑。
當?shù)谝粋€團隊覺得用得還不錯的時候，我們繼續(xù)在第二個團隊里面進行試推，并且在第三周讓兩個產品團隊坐在一起討論產品的使用方式，比如制定權限管理的方式，文檔開發(fā)規(guī)范，通知規(guī)范等等?？偨Y得到一個比較通用的方案之后，我們再繼續(xù)推廣到其他產品團隊。
在基本方案跑通之后，我們開始嘗試通過Jenkins把EOLINKER和其他系統(tǒng)關聯(lián)起來形成一個流程，比如當代碼push之后能夠自動跑測試用例，并且把報告發(fā)送給測試團隊，測試團隊再去校驗一下用例的情況。
整個培訓和實施過程花了差不多一個半月，在這個過程中EOLINKER的技術客服的態(tài)度不錯，基本上都是有問必答，而且可以針對問題給到demo。所以整個推進過程比預想中的要順利許多。后面我們由繼續(xù)采購了他們的API監(jiān)控服務，讓API開發(fā)測試和監(jiān)控能夠變成一個完整流程，目前實施下來覺得還是不錯的。
后記
這篇文章主要記錄我們搭建API管理和自動化測試平臺過程中的一些思路和過程，作為開發(fā)人員能夠完整參與到這整個過程中其實可以學到很多，無論是項目的管理、團隊利益關系的協(xié)調，還是新產品培訓和推廣等等。后續(xù)我們再繼續(xù)整理其他系統(tǒng)的搭建流程和使用技巧，希望可以多交流。
相關資源
EOLINKER：www.eolinker.com
