在持續集成的世界中，單元測試是確保添加新功能時不破壞任何其他功能的關鍵。對于執行全部、端到端的測試以及追蹤主要績效指標同樣重要，不僅僅是確保了維護功能，而且沒有傷害性能。預部署測試的關鍵是確保測試環境盡可能同生產環境緊密貼合。管理員應該也能確定他們擁有一套完整的單元測試，因此沒有功能的回歸分析。

如果你使用了任何形式的敏捷開發——Scrum、GTD或者任何其他的——你很可能熟悉單元測試，并且知道它對于持續集成多么重要。每一個變成語言都至少有一套單元測試。

以Python為例，py.test允許你編寫你想要的測試。通過Node.js，你可能想要使用Mocha 和Should的組合。不管你選擇哪一條路，確保在每一個提交階段之后運行測試。如果測試失敗了，你就知道沒法部署這個分支。

有很多托管的預部署測試工具可用，但是大部分都有剛性結構要求，或者只支持特定的語言。Jenkins-CI是基于觸發器運行工作的既定方式，而且可以測試任何語言。Jenkins適用于大多數工作流，并且如果有失敗出現就會發送郵件提醒。它甚至還能展示測試運作的圖表。

測定KPI

關鍵性能指標（KPI）是一種簡單的定量指標用來卻行新代碼的質量。比如，企業可能希望度量登錄一個應用的時間，搜索內容和點擊內容的時間。運行電子商務系統的企業同時可能希望知道付款流程需要花費多少時間，以及用戶在進入購買點時需要多少點擊。

原文鏈接：http://www.searchcloudcomputing.com.cn/showcontent_88095.htm

一旦KPI確定，開發者可以使用AWS的工具來度量他們，比如CloudWatch。CloudWatch可以讓IT團隊自動化檢測服務水平度量——服務器負載和彈性負載均衡器性能。他們也可以上傳自定制標準到CloudWatch，使用CloudWatch API即可實現，這也意味著任何代碼都可能成為KPI。CloudWatch在KPI度量達到非常規水平時會提醒開發者。

確保在高水平負載下測試你的應用。一個實例可以處理多少請求？對比每秒少量點擊，每秒一萬次點擊的延遲增加多少？

第三方性能測試工具，比如New Relic，提供額內置的度量KPI支持，通過“關鍵處理”實現。這個想法確保了大多數的重要的或者大多數常規的任務識別，而且確保這個任務的性能，并且追蹤每一個部署對其的影響。

也可以拋棄統計你的日志，使用 Loggly、Splunk或者類似的工具來生成圖表。重要的是要在你上線一項新系統的性能之前監測性能。

記住：KPI不是一成不變的。如果一個客戶抱怨具體的某一人物執行時間太長，比如下載PDF，i可以將其增加到KPI列表中。目的就是確保終端用戶被照顧到，這也會影響你的應用的性能底線。

計劃選擇性的上線

測試一項更新的常規做法就是選擇性的提供給客戶。這類似于A/B測試，但是取代了嘗試看看用戶對不同的布局做出怎樣的反映，你可以嘗試確定用戶對于新代碼做出的反映。很難預測一個人會怎樣使用一個應用，因此選擇性地發布開發通常有助于最小化變化帶來的影響。

谷歌經常選擇性的發布新功能，發布給一小部分人，而且慢慢地使其成為所有用戶能接受的功能。可以做得很隨機，或者基于用戶的登錄事件。如果有什么錯誤出現，被選擇的用戶反饋的時間長短也沒太大關系。

如果你正在使用亞馬遜彈性Beanstalk或者亞馬遜Code Deploy，設置一個獨立的環境，或者為不同的客戶設置服務器群。這將允許你的IT團隊在一個環境發布更新，同時保持現有的代碼在舊的環境中。嘗試將用戶分布到多個環境中，你則無需總是更新同樣的群組。在保持更新的群組中的用戶要特別留心關注。