在持续集成的世界中，单元测试是确保添加新功能时不破坏任何其他功能的关键。对于执行全部、端到端的测试以及追踪主要绩效指标同样重要，不仅仅是确保了维护功能，而且没有伤害性能。预部署测试的关键是确保测试环境尽可能同生产环境紧密贴合。管理员应该也能确定他们拥有一套完整的单元测试，因此没有功能的回归分析。

如果你使用了任何形式的敏捷开发——Scrum、GTD或者任何其他的——你很可能熟悉单元测试，并且知道它对于持续集成多么重要。每一个变成语言都至少有一套单元测试。

以Python为例，py.test允许你编写你想要的测试。通过Node.js，你可能想要使用Mocha 和Should的组合。不管你选择哪一条路，确保在每一个提交阶段之后运行测试。如果测试失败了，你就知道没法部署这个分支。

有很多托管的预部署测试工具可用，但是大部分都有刚性结构要求，或者只支持特定的语言。Jenkins-CI是基于触发器运行工作的既定方式，而且可以测试任何语言。Jenkins适用于大多数工作流，并且如果有失败出现就会发送邮件提醒。它甚至还能展示测试运作的图表。

测定KPI

关键性能指标（KPI）是一种简单的定量指标用来却行新代码的质量。比如，企业可能希望度量登录一个应用的时间，搜索内容和点击内容的时间。运行电子商务系统的企业同时可能希望知道付款流程需要花费多少时间，以及用户在进入购买点时需要多少点击。

一旦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团队在一个环境发布更新，同时保持现有的代码在旧的环境中。尝试将用户分布到多个环境中，你则无需总是更新同样的群组。在保持更新的群组中的用户要特别留心关注。