在前面兩篇文章中，我們詳細介紹了網易輕舟的CI和CD實踐，同時我們也知道在網易實踐中，CI和CD是分開的，但其實對用戶而言，CI和CD應該是一體的，如何解決這兩者的矛盾呢？
網易輕舟的做法是通過流水線觸發器中的Pipeline關聯觸發功能串聯了CI以及CD流水線，用戶可以預先在容器部署模塊，創建對應的容器應用，然後在CD流水線中添加部署階段，並選擇對應的應用/部署進行更新升級。
需要注意的是，網易輕舟並沒有在流水線這裏提供太多的部署配置，僅提供了鏡像升級。某些運維相關的配置項，比如部署策略、Service、環境變量等，依然需要到容器部署模塊修改。這麼做的目的，是爲了限制流水線側的權限範圍，因爲絕大多數情況下，持續集成面對的都是應用的更新場景，所以這麼做也可以保證流水線可以長期穩定運行。
測試自動化
解決完CI/CD的連接問題，接下來我們就要關注測試的部分。梅光輝表示：“自動化測試是打通持續集成和持續交付的核心，沒有有效的自動化測試保證，持續集成與持續交付就僅僅是一個沒有靈魂的空殼。因此，網易輕舟在CI/CD中引入了對自動化測試的全方位支持。”
通常來講，自動化測試分爲單元測試自動化、接口測試自動化、集成（UI）測試自動化這三個層面。
自動化測試的三個層面的關係如上圖所示，越往上越靠近QA、業務和最終用戶，但與此同時執行起來成本也越高、速度越慢、投入產出也越低。因此，業內最佳實踐往往是加大最底層單元測試的佔比（70%），再配合一定的接口自動化測試（20%）以及集成測試（10%）。
如果從CI/CD最佳實踐來看，單元測試自動化一般在CI階段就會cover掉，並作爲代碼合入的標準。而在發佈過程中，則主要是接口測試自動化，以及最終的集成測試自動化。
針對接口自動化測試，CI/CD在流水線中集成了網易內部的GoAPI接口自動化測試平臺，如下圖所示：
用戶通過預先在GoAPI自動化平臺配置接口測試執行集，然後在流水線中配置執行集，就可以在流水線執行過程中自動執行併產生測試質量報告了。
集成測試自動化一般是由QA或開發人員編寫對應的自動化測試代碼，來覆蓋系統核心的使用流程，實現端到端的場景測試自動化。目前這方面技術最成熟的是Java生態，因此，網易輕舟內部技術選型採用較多的是TestNG等自動化測試框架，再結合Retrofit、cucumber等框架。
同時，CI/CD中也提供了對TestNG工具的支持，用戶在流水線部署階段之後添加對應的集成測試階段，然後配置相應的測試工程容器鏡像，就可以在流水線執行過程中執行自動化測試了，並且也可以選擇將生成的測試結果數據上傳至對象存儲或第三方平臺，然後就可以在流水線執行頁面提供相應的跳轉鏈接查看測試結果了。
API版本管理
無論是對於API的設計者，還是調用方，API版本管理都是十分重要的。在實際應用中，隨着業務的不斷髮展，API也會不斷變化，這時我們會常碰到的問題就是API的向後兼容性，當出現需求變更、考慮不全的情況，兼容性的實現就會變得複雜。
網易輕舟採用的是RESTAPI的設計風格，每個接口都對應着對一種資源的操作，版本信息直接放在URL中，表示每種資源都會有一個對應的版本。比如獲取應用列表的API就是GET /api/v1/applications 。一般情況下，在對應用的數據模型進行擴展和修改的同時，都會考慮數據的兼容性情況，比如某個字段的命名修改，在接口上會同時支持兩個不同參數，而在實現上會將兩個參數映射到同一個字段。同時在接口文檔中，也會有說明告訴用戶能夠儘快做出修改。
如果應用對應的數據模型發生了無法兼容的變更，那就會將接口從v1升級到v2，變爲GET /api/v2/applications。v1版本的接口和v2版本的接口會同時提供對外服務，但是除了bug修復外，一般後續需求如果有對API的更新，都會在新版本中進行更新，用戶如果想要使用新功能，需要主動遷移。
汪燦豐表示：“這種API管理方式是目前比較成熟的方式，當然，一般情況下都是會採用兼容的設計方案。”
採訪嘉賓簡介：
汪燦豐，網易杭州研究院高級產品開發工程師，專注於雲原生以及DevOps領域，目前主要負責網易輕舟CICD的研發工作。
梅光輝，網易杭研究院高級服務端開發工程師，目前主要負責網易輕舟CICD研發工作，在雲原生以及容器DevOps領域有過深入的研究和實踐。
相關閱讀：