网站的日常需求常常是批量发布的，在发布过程中只要有一个需求产生问题就可能影响整次发布。如果发布被延迟，那也可能是延迟一批需求的发布。究其原因总是答案不同，也可能在各个环节都有一定的问题。
比如前几周有一次，前台发布延迟了一天，原因是回归测试未通过，因风险考虑延迟一天确定问题。那么我们能把责任就定在回归测试上么？显然不是。让我们追溯看看吧！
1、回归测试为什么没通过？后来查出来是调用外部接口有问题，和本次发布的需求没有关系。
2、为什么不能在发布日前进行排查确定呢？因为回归测试完已经下班了，回归测试人员又没有及时发出回归测试报告。该风险涉及面较广，无法由某个产品线负责人来进行判断。
3、那么回归测试是否能在下班前完成，如有问题，及时留下相关人员来进行问题分析呢？18点下班，回归测试半个小时左右，倒推回去，要求功能测试17点完成。
4、功能测试17点完成是否有困难？完成的标志是在预发布环境所有测试也通过。OK，那再倒推一下，预发布大约半个小时。留一个半小时的预发布测试时间。15点需要完成测试环境的功能测试。
5、15点完成功能测试，早上9点开始合并代码，提供测试环境约9点半。我们来算一下测试时间9：30-12点，13点-15点。共4个半小时。中间还有DEBUG，重新提交、合并的过程。这个过程中，如有空等待，人员找不到，BUG问题找不到，接口人员找不到，那真不敢想像啊！HOHO，时间太宝贵了啊！
那么这次因为回归测试没通过而导致的发布延迟，到底由谁来负责呢？
要顺利发布，要各个环节都需要做好才行啊！