自动化发布 网站的版本发布频繁，整个发布过程需要多个团队通力合作，发布前，多个代码分支合并回主干可能会发生冲突，预发布验证也会带来风险，每次发布又相当于一次宏机事故，因此网站发布过程荆棘丛生，一不小心就会踩到雷。 对于有固定发布日期的网站，一到发布日，整个技术部门甚至运营部门如临大敌，电话声此起彼伏，工程师步履匆匆，连空气中的温度都仿佛升高了几度，即便如此，发布过程还是常常出错，发布日工程师加班到凌晨是常有的事，而且容易中出错，因发布引发的故障也居高不下。 据说国外某知名互联网公司的CEO就因为没有有效手段控制发布故障、减少发布日的加班而引咎辞职，其继任者提出了火车发布模型，将每个应用的发布过程看作一次火车路程，火车定点运行，期间有若干点，每一站都进行例行检查，不通过的项目下车，剩下的项目继续坐着火车旅行，知道火车到达终点，但实际中，有可能所有项目都下车了，还有可能是车上有达官贵人， 由于火车发布模型是基于规则驱动的流程，所以这个流程可以自动化。采用火车发布模型的网站会开发一个自动化发布的工具实现过程的自动化，根据响应驱动，自动构造代码分支，进行代码合并，执行发布脚本等。正常流程下，可以做到发布过程无人值守，无需SCM参与，每个项目相关人员基于流程执行响应的操作，即可完成应用自动化发布，人的干预越少，
自动化程度越高，引入故障的可能性就越小，火车准点到达，大家按时下班的可能性就越大。 灰度发布 应用发布成功后，仍然肯能发现因为软件问题而引入的故障，这时候就需要做发布回滚，即卸载刚刚发布的软件，将上一个版本的软件包重新发布，是系统恢复，消除故障。 大型网站的主要业务服务器集群规模非常庞大，比如某大型应用集群服务器数量超过一万台，一旦发布故障，即使想要发布回滚也需要很大时间才能完成，只能眼睁睁看着故障时间不断增加却干着急，为了应用这种局面，大型网站会使用灰度发布模式，将集群服务器分成若干部分，每天只发布一部分服务器，观察运行稳定没有故障，第二天继续发布一部分服务器，持续几天才把整个集群全部发布完毕，期间如果发现问题，只需要回滚已发布的一部分服务器即可。
灰度发布也常用于用户测试，即在部分服务器上发布新版本，其余服务器保持老版本，然后监控用户操作行为，收集用户体验报告，比如用户对两个版本的满意度，一确定最终的发布版本，这种手段也被称为AB测试。
一起设计吧
