平均每周五天基本上有四天都会有项目上线，有时一天会上线至少二个版本，就在昨天刚上线了一个项目，星期一才提测的一个项目，星期二就安排上线了，所以悄悄地告诉小伙伴们，昨晚俺加班了(再悄悄地告诉大家其实这个昨晚已经过去很久了~微笑脸)，今天跟小伙伴们分享一下王豆豆公司的上线流程。
01 早会
每天早晨上班之后，都会开早会，早会主要是回朔昨天的内容、今天的计划、需要解决的问题三个方面。
开发每个人讲自己的情况后。
主持人：“测试呢？”
测试A：... ...
测试B：... ...
王豆豆：“XX项目，昨天已经将所有的测试点测试完全了，今天开发合到master上回归测试完成之后就可以上线了。”
开发A：“我一会儿就合"
王豆豆："好的"
散会之后，一小时过去了.....
王豆豆问开发A："合完了没“
开发A：”还没有，还在做code review"
然后再一小时间过去了，代码还是没有从分支到master上。
上午下班前问：”什么时候能合完吗？"
开发A自信满满地说：”能“
02 回归测试
一直到下午三点左右，代码才合并到master上，果真是合并十分钟，等待四小时，不过这样也有好处，项目组内只有项目leader才有合并代码的权限，他在合并代码之前会再做一次code review，这样最大程度保证代码的正确性，只此以后，王豆豆就变聪明了，提前让开发合master。
回归测试开始
1.配置参数和环境
2.回归主要的流程
3.将以前提的bug再次回归
4.回归主要的异常流程
王豆豆回归测试时主要就是由这几个方面组成的，如果有需要跟第三方系统联测的情况，那么代码合前到master时，需要设计测试用例场景覆盖需求与第三方系统测试人员联测，三方联测最是花费时间，所以测试过程中如果有这个需求一定要提前安排好时间，与联测人员约好相应的时间，联测在回归测试阶段也会进行，这时主要以正向流程为主，目的是检查业务流程是否完整、接口是否联通、数据是否正确等几个方面。
用于回归测试的服务器：
王豆豆目前公司有十台测试服务器，平时根据项目、业务需求和测试任务的不同，在不同的测试服务上拉分支进行测试，几轮测试完全之后，确定要上线时再将分支合并到master上，然后其中固定的一台测试服务器上进行回归，这台服务器只用于回归master分支，这样就保证了测试任务的独立性，同时也能保证测试上线配置不会遗漏。
针对上述情况，王豆豆举例说明：
假设我们有5台测试服务器，分别命名为test1、test2、test3、test4、test5。
刚好今天王豆豆就接到了一个新的测试任务，接到任务之后，王豆豆就会询问测试小伙伴们哪台服务器是现在没人用的？假设今天test3没人用，那王豆豆就选择test3作为本次测试任务的测试服务器。
确定了测试服务器，开发转测之后，王豆豆就会在test3这台机器上部署代码（我们是用jenkins自动部署，早已脱离了手工去部署代码），配置数据，进行测试。
通过几轮的测试，当项目满足上线需求之后，会让开发将代码从分支合到master上进行回归。
回归测试时，就会将代码部署到test1上，test1所对应的代码版本一定是master，这时就会在master上进行回归测试。
03 上线前准备
回归测试完成之后，通过测试，表明项目已经具备上线的要求了，那这时就开始做上线前的准备，上线前准备一般会为三个步骤：
1.确定上线策略
a.上线顺序
如果有多个系统上线，上线顺序是怎么样的？经常我们会有三个系统一起上线，那么A、B、C三个系统的依赖关系是怎么样的？比如B系统的上线功能依赖于A系统的 上线功能，那么就先上A系统，再上B系统，项目中上线顺序根据实际情况确定上线。
b.修复数据策略
如果功能上线之后出现BUG，应该怎么处理？一般我们会设一个开关，当新功能一旦出现问题，将开关打开，走原来的老流程。
如果上线之后出现BUG，BUG影响的数据应该怎么修复？有时会单条单条的修改数据，但如果数据量太大，单条修复数据这个工作量就很大，那么在有可能出现BUG地方设置一个点，有可能是task任务，重新跑原来的流程，也有可能是设置一个状态，一旦数据出现问题，无法正常进入下一个流程，那么设置状态为error，当BUG解决后，可以重试，修复错误数据。
3.旧数据分析
这个分析并不是每个项目都需要，仅限新功能上线后分影响老数据的那些项目。
2.写上线申请邮件
上线之前，项目测试负责人要写上线申请邮件，邮件内容包括有：
1.数据配置
有没有开关？有就需要配置。
数据库有没有修改？有新增表，需要事先增表，有修改表结构，需要改表结构。
有没有外部接口？有就需要配置接口URL，否则流程不能跑通，回调也不能通。
等等，根据实际情况来写。
2.上线注意点
可以写本次项目上线后，会引起的风险，哪些地方可能容易出现问题？需不需要加上监控等？又或者上线之后，需要人为地去监控数据。
3.在邮件中写清楚上线策略
3.配置数据
根据测试人员编写的上线申请邮件，在上线之前在线上环境中配置好数据，根据邮件来配置，所以在编写邮件的时候需要将配置写全，这些配置可以根据开发人员提测时的转测邮件来写，或者测试过程中的补充配置，谨记配置要写完整。
4.开始上线
一般我们上线的权限只有几个人有，上代码时需要先将线上环境的job停掉，我们也是用jenkins进行自动化部署，只是需要人为的打版号、标签，部署版本，停Djob任务，上线完全之后，启动Djob任务等。
04 上线之后
项目上线之后，首先是测试人员开始做灰度测试，灰度测试时，一般由开关控制，只要少量的数据可以走新业务流程，在灰度测试时，将所有业务流程走完，检查各项数据的正确性、流程是否通、流程是否完整等等检查点。确定无问题时，再将开关打开，再开放少量真实用户数据。
这时，需要测试人员在项目上线之后的几个小时内，重点监控线上数据的流向，一旦数据有异常，立即采取措施，回滚代码又或者重新打开开关等，尽量将线上bug引起的损失降到最低，接下来就开始修改bug和修复数据。
基本整个项目上线流程就是如此。