[[129315]]

在持續(xù)集成的世界中，單元測(cè)試是確保添加新功能時(shí)不破壞任何其他功能的關(guān)鍵。對(duì)于執(zhí)行全部、端到端的測(cè)試以及追蹤主要績(jī)效指標(biāo)同樣重要，不僅僅是確保了維護(hù)功能，而且沒(méi)有傷害性能。預(yù)部署測(cè)試的關(guān)鍵是確保測(cè)試環(huán)境盡可能同生產(chǎn)環(huán)境緊密貼合。管理員應(yīng)該也能確定他們擁有一套完整的單元測(cè)試，因此沒(méi)有功能的回歸分析。

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

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

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

測(cè)定KPI

關(guān)鍵性能指標(biāo)（KPI）是一種簡(jiǎn)單的定量指標(biāo)用來(lái)卻行新代碼的質(zhì)量。比如，企業(yè)可能希望度量登錄一個(gè)應(yīng)用的時(shí)間，搜索內(nèi)容和點(diǎn)擊內(nèi)容的時(shí)間。運(yùn)行電子商務(wù)系統(tǒng)的企業(yè)同時(shí)可能希望知道付款流程需要花費(fèi)多少時(shí)間，以及用戶在進(jìn)入購(gòu)買點(diǎn)時(shí)需要多少點(diǎn)擊。

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

一旦KPI確定，開(kāi)發(fā)者可以使用AWS的工具來(lái)度量他們，比如CloudWatch。CloudWatch可以讓IT團(tuán)隊(duì)自動(dòng)化檢測(cè)服務(wù)水平度量——服務(wù)器負(fù)載和彈性負(fù)載均衡器性能。他們也可以上傳自定制標(biāo)準(zhǔn)到CloudWatch，使用CloudWatch API即可實(shí)現(xiàn)，這也意味著任何代碼都可能成為KPI。CloudWatch在KPI度量達(dá)到非常規(guī)水平時(shí)會(huì)提醒開(kāi)發(fā)者。

確保在高水平負(fù)載下測(cè)試你的應(yīng)用。一個(gè)實(shí)例可以處理多少請(qǐng)求？對(duì)比每秒少量點(diǎn)擊，每秒一萬(wàn)次點(diǎn)擊的延遲增加多少？

第三方性能測(cè)試工具，比如New Relic，提供額內(nèi)置的度量KPI支持，通過(guò)“關(guān)鍵處理”實(shí)現(xiàn)。這個(gè)想法確保了大多數(shù)的重要的或者大多數(shù)常規(guī)的任務(wù)識(shí)別，而且確保這個(gè)任務(wù)的性能，并且追蹤每一個(gè)部署對(duì)其的影響。

也可以拋棄統(tǒng)計(jì)你的日志，使用 Loggly、Splunk或者類似的工具來(lái)生成圖表。重要的是要在你上線一項(xiàng)新系統(tǒng)的性能之前監(jiān)測(cè)性能。

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

計(jì)劃選擇性的上線

測(cè)試一項(xiàng)更新的常規(guī)做法就是選擇性的提供給客戶。這類似于A/B測(cè)試，但是取代了嘗試看看用戶對(duì)不同的布局做出怎樣的反映，你可以嘗試確定用戶對(duì)于新代碼做出的反映。很難預(yù)測(cè)一個(gè)人會(huì)怎樣使用一個(gè)應(yīng)用，因此選擇性地發(fā)布開(kāi)發(fā)通常有助于最小化變化帶來(lái)的影響。

谷歌經(jīng)常選擇性的發(fā)布新功能，發(fā)布給一小部分人，而且慢慢地使其成為所有用戶能接受的功能。可以做得很隨機(jī)，或者基于用戶的登錄事件。如果有什么錯(cuò)誤出現(xiàn)，被選擇的用戶反饋的時(shí)間長(zhǎng)短也沒(méi)太大關(guān)系。

如果你正在使用亞馬遜彈性Beanstalk或者亞馬遜Code Deploy，設(shè)置一個(gè)獨(dú)立的環(huán)境，或者為不同的客戶設(shè)置服務(wù)器群。這將允許你的IT團(tuán)隊(duì)在一個(gè)環(huán)境發(fā)布更新，同時(shí)保持現(xiàn)有的代碼在舊的環(huán)境中。嘗試將用戶分布到多個(gè)環(huán)境中，你則無(wú)需總是更新同樣的群組。在保持更新的群組中的用戶要特別留心關(guān)注。