在互聯網的產品開發時代，產品迭代越來越頻繁，“從功能開發完成直到成功部署”這一階段被稱為軟件開發“最后一公里”。很多開發團隊也越來越認識到，自動化測試和持續部署可幫助開發團隊提高迭代效率和質量。
那么，如何更好地解決“最后一公里”這一問題呢?
一切從自動化測試開始，讓自動化測試貫穿在整個項目開發-集成-部署-交付的-開發流程中。
如果你的團隊還沒有開始自動化測試，推薦從經典的測試金字塔開始。
自動化測試
在這個分層自動化測試金字塔中，Unit 代表單元測試，Service 代表服務集成測試，UI 代表頁面級的功能測試。不同的產品層次都需要自動化測試，投入的精力和工作量會有所不同。下面我們仔細看下每個層次的測試：
1.1 Unit 單元測試
“凡是不能量化的工作都是不可考量的”
目前很多公司已經意識到了單元測試的重要性，但國內堅持寫單元測試的團隊並不多，其中一個難點在於沒有考量，沒有很好地執行單元測試覆蓋率檢測。
想想，如果沒有單元測試覆蓋率檢測，單純的只寫單元測試，時間長了也許開發人員會產生惰性，比如：今天任務太緊了，就不寫單元測試了，以后再補，反正寫不寫也沒有人知道。引入單元測試覆蓋率檢測之后，開發人員會更主動地寫單元測試，就算補寫單元測試也更有成就感。單元測試覆蓋率檢測有現成的第三方工具，比如 code climate 、 Coveralls 等等，針對不同的語言也有還有一些定制化的檢測工具， 比如前端常用的 Eslint , Python 常用的PEP8 等等。整個項目的單元測試覆蓋情況百分比，看上去一目了然。
相比其他層級的測試，單元測試發現並解決問題付出的成本相對來說最低，而投入產出比最高。單元測試的責任主體一般來說是開發人員，寫單元測試也是開發人員對自己的代碼進行檢查的過程。
1.2 Service 集成測試
“多數應用和產品都需要與外部資源交互，有時候多數 Bug 並不來源於程序本身，而是由從外部輸入的數據所引起的。”
這時候，就更需要集成測試。
集成測試是在單元測試的基礎上，將所有模塊按照設計要求（如根據結構圖）組裝成為子系統或系統，進行集成測試。這個集成測試階段主要解決的是檢查各個軟件組成單元代碼是否符合開發規范、接口是否存在問題、整體功能有無錯誤、界面是否符合設計規范、性能是否滿足用戶需求等等。
集成測試與單元測試最大的區別在於，它需要盡可能地測試整個功能及相關環境。如果不經過單元測試，那么集成測試的效果將會受到很大影響，大幅增加單元代碼糾錯的代價。
這一層的被測對象是抽離了展現層的代碼(前端以及部分后端展現層邏輯)，主要是由測試人員進行，是測試人員大展身手的地方。
1.3 UI 系統測試
“一份永遠都運行成功的自動化測試用例是沒有價值的。一切都在變化中。”
在做好上面兩層的測試覆蓋之后，最頂端的是 UI 層的自動化測試。目前，UI 層的自動化覆蓋正在逐漸轉變為頁面展示邏輯及界面前端與服務展現層交互的集成驗證。UI層自動化做的方式很多，根據不同的系統，不同的架構可能會用到不同的框架或者工具，比較主流的有QTP，Robot Framework、watir、selenium 等。
怎么選擇合適的工具？每個測試工具都有它的優缺點，每個被測試的項目也有自己本身的特點。比如，項目是用什么語言編寫的，C, C++, Java, PHP , Python or C#? 項目是什么類型，Desktop , Web or Mobile Application? 很難說一種工具就可以搞定所有或者大部分的項目，也很難說一個項目就能單純的靠一種工具來搞定。
UI 層是直接面向用戶的，需要測試人員放入更多的時間和精力。如今的互聯網公司大多需求變化大而快，迭代頻繁，所以很多團隊做 UI 自動化測試投入較大精力，卻遲遲見不到效果，自動化測試人員每天奔命於維護腳本，追趕進度。有 2 點 UI層自動化覆蓋的原則非常有必要提下：
-
能在底層做自動化覆蓋，就盡量不在UI層做自動化覆蓋；
-
只做最核心功能的自動化覆蓋，腳本可維護性盡可能提高。
綜上所述，分層自動化測試側重不同，效果不盡然完美的，而最快速高效發現 bug 的方法是將自動化測試包含到構建過程中。謹慎周全的自動化測試可以進一步保證持續部署的穩定與安全，提高持續部署的成功率。
持續部署
對於持續部署，@灣區日報 這樣評論：
一個團隊工程技術水平高低，直接反映在部署代碼上。我碰到其他公司的人，都喜歡問你們怎么部署代碼的，非常大開眼界。你很難相信，很多（有一定規模的）公司仍然是人肉 SSH 到十幾、二十台機器上 git pull、手動重啟服務器，部署一次代碼幾個小時 -- 這么原始，活該加班：）
持續部署（continuous deployment）是通過自動化的構建、測試和部署循環來快速交付高質量的產品。某種程度上代表了一個開發團隊工程化的程度，畢竟快速運轉的互聯網公司人力成本會高於機器，投資機器優化開發流程化相對也提高了人的效率，讓 engineering productivity 最大化。
2.1 持續部署的步驟
“持續部署”的痛苦源於部署時的各方面，比如需要部署到哪些環境，測試環境？灰度發布？正式環境？還有其依賴包的版本，環境配置管理等等，都需要考慮在其中。對於一個標准的部署——安裝軟件包並啟動環境，可能的步驟將會是：
2.2 CI 工具的選擇與使用
imothy寫過一篇文章介紹了 IMVU 是如何進行持續部署。IMVU 的做法是，在持續集成構建過程中進行大量的、覆蓋范圍廣的、非常可靠的自動化測試，保證在 10 分鍾內跑完整個測試套件。所有測試通過后，部署便開始了。
在這個過程中，持續集成工具的選擇和系統的搭建顯得尤為重要。面對眾多的 CI 工具，我們將其分為 Hosted CI 和 Self Hosted CI：
-
Self HostedCI 指的是將軟件部署在公司的機房或內網中，需要提供多台服務器來完成 CI 系統的運轉，同時需要對不同機器之間進行環境配置。主流工具有Jenkins，其他受歡迎的工具比如 Baboom 及 TeamCity 等。
-
Hosted CI 指的是由 SaaS 型的 CI 服務，全程在線進行構建配置，不需要考慮裝機器，裝軟件，環境搭建等成本。常見的有 CircleCI，Codeship 和 TravisCI 等。
我們對比一下這兩種 CI 服務：
-
Self Hosted CI 對構建環境有完全的控制權，能夠實現完全定制。但需要搭建環境和配置、維護成本高，需要買專門的機器，花費人力物力且更新遷移風險高；
-
Hosted CI 無需額外機器，幾分鍾就可以用起來。可以根據你的需要動態調度資源。省時，省心，省力。
我們做了一款 Hosted CI 產品—— flow.ci ，它是融入了 workflow 機制的持續集成（CI）服務，也可以理解為自動化流程平台，除了集成代碼、編譯、測試之外，還可以集成常用的工具、靈活自定義流程。1 分鍾即可完成開發測試環境搭建，開啟第一個Build。
flow.ci 更側重於工作流的設置，默認的工作流可以自動編譯測試代碼，進行單元測試覆蓋率，代碼質量檢測等工具以插件的形式進行集成；並加入了 Webhook 功能。從自動化測試到持續部署，一切簡單靈活。
2.3 讓持續部署成功的要點
一個持續集成 & 持續部署的自動化系統並不是那么簡單的事，如果不選用其他 CI 服務，其開發工作量和一個標准的大型互聯網業務系統沒什么兩樣。如果沒有持續部署的經驗，要想成功地進行持續部署要注意這些:
- 充分而廣泛的自動化測試覆蓋；
- 盡可能短的測試反饋時間；
- 部署過程自動化；
- 部署過程要保證數據安全；
- 在穩定的前提下，盡早部署；
- 完善的風險緩解措施；
- 將同樣的產物部署到不同的環境中
2.4 持續部署習慣的養成
持續部署真正困難的不是技術的實現，也不是工具的選擇和使用，最難的是培養團隊持續部署的習慣以及工程文化。可以參考下Instagram 的持續部署工程文化。
總結
不論是自動化測試，還是持續部署，都只是一種實現手段；他們真正存在的價值在於提高代碼質量和提高產品的持續交付能力。關於如何進行更好地進行自動化測試和持續部署，可以多參考下其他公司的持續部署實踐案例與經驗。
如果你有更加深刻的見解，歡迎留言交流！
【參考鏈接】