发布流程考虑
灰度发布
灰度发布是指在黑与白之间，能够平滑过渡的一种发布方式。AB test就是一种灰度发布方式，让一部用户继续用A，一部分用户开始用B，如果用户对B没有什么反对意见，那么逐步扩大范围，把所有用户都迁移到B上面 来。灰度发布可以保证整体系统的稳定，在初始灰度的时候就可以发现、调整问题，以保证其影响度。
-
多级发布
也可以称为分步代码发布， 是一种代码发布的方式 。基本操作是整个团队共用一个代码库，一定频率（比如每天一次，或者每周一次）把整个代码的最新版本做一个新的发布分支(release branch)，把发布分支逐步发布到产品线。
特点："逐步选择"的过程不由代码控制（如果代码控制，那新一版本的控制代码有问题就可能让整个代码发布过程崩溃）。“逐步选择”过程由运营团队负责：比如选择每个机柜的第一台机器，或者每个机群的第一个机柜，或者多个数据中心里面选择某一个数据中心⋯⋯关键是选择的时候是均匀分布到各种不同的机器上。如果新代码在某一种配置的机器上有问题，运营团队能够及时发现。
监控： push一般要做实时的监控：代码逻辑错误的信息按照代码版本（比如svn revision number）来分类，保证新版本的代码不带来新的错误；硬件的信息（CPU内存IO）按照选择的机器、机柜、机群、数据中心分类：保证新的版本不引起更大资源消耗。当以上的信息都确认之后，可以给更大规模的机器安装新代码。
-
AB测试
这是一种很成熟的概念，是 产品发布的常用手段 。比起分步代码发布，AB测试往往有更长的周期（比如几个星期甚至几个月）。基本操作是产品的开发者加一个或者多个配置控制（一般每个产品配置应该带有配置的ID），允许通过调节相应的配置来让一个产品发布到“逐步选择”的用户群。
特点：“逐步选择”是一个有代码控制的逻辑过程。一般的产品基于用户ID选择；也有基于IP或者其他信息的。
监控：AB测试的数据一般按照产品配置ID和打开／关闭状态分类，分析某个产品配置在打开的时候和关闭的时候对用户行为的影响，和对硬件资源的消耗，由此可以预测这个产品在100％发布之后的影响。
从概念中可以看出多级发布和AB测试中最重要的区别： 面向对象不一样 。多级发布针对的是 代码发布 ，AB测试针对的 产品发布 。
互联网应用在交付上线过程中（运维部门的职能），需要经过灰度交付和A/B测试两个环节，前者用于检验系统是否稳定可靠，满足上线要求，需要收集和分析性能数据来决定；后者用于检验到底新版本好还是旧版本好，需要收集和分析用户访问数据来决定。
阿里灰度发布引擎参考
发布前测试优化？
上线前测试简化
测试环境与正式环境切换
-
数据库问题?
-
现有API应用？