今天完成的事：

测试了官网BUG。

1、通知客户、通知公司内所有参与人：PM/UI/开发 /OP/QA
2、QAwiki登记，登记的时候，找开发确认，WEB确认清楚几个项目，后端确认清楚几个服务以及数据库
     登记完的一定要是开发确认过的
3、QA找UE和技术部负责人在wiki上登记，登记列表单开一列：负责人确认
4、QA发申请邮件，写明时间点
5、OP发布
6、OP发布完，修改wiki，回复邮件
7、 QA/开发 进行验证，如果问题，开发进行查验并解决
8、验证完成之后，QA修改wiki发布状态，并回复邮件
发布类型：1、新项目第一次部署--部署开发环境的时候，一并把测试环境、线上环境都部署完成
                     部署开发环境：开发人员项目框架搭好之后通知OP进行部署
                 2、旧项目版本迭代
发布时间：1、新项目不局限
                 2、旧项目版本迭代：晚上10点之后

因为测试环境及线上环境的发布未遵守流程,导致效率低下,各岗位协作不畅
特此整理测试及线上环境发布流程，各位前后端技术大牛们遵守流程发布，以避免因为随意发布带来不必要的损失。
发布流程需注意：
1、测试环境每天发布，时间点为下午4点(ps:四点前请开发人员做好相关准备工作,包括wiki登记,邮件发布等过程)
2、线上环境只允许周2和周5发布。
3、Wiki上每天发布完成之后，都要在Wiki上登记是否已经验证,验证分成三格，一格为是否qa确认开发环境演示无误(开发人员在开发环境修复bug后必须通过给QA演示已修复的内容,才能发测试邮件),二格是否运维验证发布成功,成功则写上时间戳，三格是开发人员验证是否发布成功，验证了写上时间缀。
4、每一次发布只允许两种，一种是Bug修复, Bug修复必须标明Bug号，而且是直接能点到禅道上看的Bug。另一种是Story。
5、对于线上有紧急Bug需要修复，必须当天立刻发布的情况，必须由老大,广亮,古尘任意一位leader签字方可以进行。
6、测试以及线上紧急发布都不需要单独建立页面，在当月的登记表上登记，紧急发布部分全部用红色字体标明，其余正常发布用黑色字体即可
7、wiki登录原则上以月为单位，每个月新开一个表格。Wiki上的登记顺序为运维执行时候的顺序，登记顺序为：sql → service → web → html/admin-html
8、无论是测试服，还是线上服务，发布的时候全体项目成员必须都在场。直到验证线上发布成功。包括前端，后端，PM，QA，运维，避免出现因为人员不在，遇到紧急情况 无法解决的问题。
9、开发发布到测试，是由开发人员写wiki。测试环境发布到线上，是由测试人员写wiki. 换句话说。开发人员负责什么时间发布到测试，不需要QA的参加。但是到了线上环境，必须是QA同意，才允许发布到线上。

第一步：在本地或者服务器上打好tag

第二步：在wiki上编写发布日志

路径如下

然后进入对应的环境与其下的项目文档
找到对应的月份发布文件
编辑并添加发布日志
日志名格式为  项目名-发布日期-发布批次  如：修真院七期-20161107-01
发布日志格式如下：
1、需要执行的数据库sql语句 如：
use resources;
insert into resources(name,resource) values('refunds-wealth-finance-service-rmi','wealth.finance.service:10103');
2、发布系统

第三步：运维人员 检查老版本是否备份并将发布版本备份

1、运维发布之前邮件通知大家要发布内容。

2、运维发布之后邮件通知大家发布完成，请大家检查发布是否成功。

3、运维发布不成功，邮件通知回滚

发布后发邮件通知发布结果

验证后添加发布日志中的运维人员验证栏，并添加验证时间

第四步：开发人员验证发布是否成功，回复运维人员邮件，说明是否发布成功。

验证后添加发布日志中的开发人员验证栏，并添加验证时间

第五步：如果发布失败线上环境立即回滚至对应版本，测试环境视情况决定是否回滚

明天计划的事：

租人