说明
在工作中，代码上线是很重要的，而作为上线人员，对流程要严格把控，对需要上线代码的更新是需要仔细研究！！
向持续交付前行
在保证上线质量的前提下，如何提高上线效率，做到自动化部署，持续交付，这是一个值得深入和持久关注的问题。
代码上线流程
svn代码更新-->测试环境上线测试-->测试OK后发送邮件告知测试结果给运维，并说明可以上线代码svn_revision -->上线前记录svn_revision，对比上次上线时的改动，判断对各服务连接有无影响，注意配置文件的修改-->汇报上级（确定上线后）-->上线需将所有测试OK的所有代码统一上线（提前做好备份，方便出现问题回滚。注意配置文件的变动，防止更新后各服务不通）-->对上线后的功能进行测试（通知公司人员进行测试）-->OK邮件通知全员。
注：打标签(svn tag)是一个更通用的做法。
代码中运维需要处理的配置
<?php
return [
//缓存中无数据时，是否从db中读取数据
'read_data_from_db'=>true,
//用户头像
'user_avatar' =>[
//默认的用户头像，不包含域名
'default_avatar' => 'default.jpg',
],
//经纪人头像
'broker_avatar' =>[
//默认的经纪人头像，不包含域名
'default_avatar' => 'default.jpg',
//经纪人头像域名
]
];
保持项，key和svn中的一致性
其中对应的项、key的前后顺序保持和svn中的一样，这样对于开发人员、测试人员来说，出现问题后便于对比。对于运维来说，仅需要修改对应key下的value即可，根据线上的实际情况进行修改。对相应的注释，项和key不要随意修改，也不要调整其前后顺序，如果需要调整，则需要到svn中进行调整，并且和开发人员进行交流核实。
** 上线中遇到的问题 **
下面列举一个上线遇到的问题，再次记录，避免下次出错：
昨日通知上线后，首先我将svn代码进行更新，记录svn_flag位置点为1392，询问上传代码人员无误并无严重修改后，更新代码上线，因为是首次上线，所以将所有代码一次性部署到线上，完成后测试无问题。结束报告。
在回到家中，公司人员反映，出现问题，无法登陆，便上去查看api日志访问日志，发现有error，但无处理结果，次日到公司商议解决。
来后，询问编写代码人员，查看api日志发现此error后，发现有一个配置文件仍然是旧版本，进行核对后重新上线代码。问题得到解决！
** 简述原因 **
因为代码中有一个config目录，在上线后运维需在config目录下修改配置，连接mysql及redis，所以在上代码前我提前将旧版本和此目录做好备份，待新代码上线后，将config目录替换，本以为一切配置无改变。
但是在日志中发现，api接口调用错误，返回配置文件发现，虽然我将旧的config目录替换，但是此目录下也做了更新，所以上线并没有做到同步。
错误总结
通过此次的错误，认识问题的严重性，如果当次类问题发生在正式产品线上，后果很严重，所以需要严格反思，总结文档，提高警惕，避免以后出现同样的错误。
