袁亮，15:37 2014-2-13，开发部署上线
说明：
1、本流程主要适用于工作一年内的新人，半个小时内就能搞定的，可以不用按完整的流程来，其他的都需要遵守
2、时间不是太急的情况下，老员工也尽量按该流程来，以降低风险
3、另外，每个程序员都是这么一路犯错下来的，你的水平基本上跟你犯过的错误是成正比的(同一个问题一犯再犯那就另说)，所以我们需要学会犯错之后学会去避免它，并且善于从别人的错误教训中吸取经验。
一、需求确定
1、开发之前，必须要明确本次开发的目的，以及实现的方法
a、每个人提出需求的时候，一般都会根据自己的理解、现有的水平，给出相应的解决方案，至于这个方案好还是不好，那就很难说了，所以开发之前，涉及到的相关人员必须要清楚，这次做的根本原因是什么？有没有更好的方法？
b、需求的确定决定了这次开发是否能顺利完成的80%，很多时候，一个很小的改动，可能会减少你们50%以上的工作量。
2、需求的分期完成
a、我们有太多的工作是做的差不多了没上线，或者做着做着就没音讯了，大部分的原因都是因为需求不合理，以及任务分期不合适，总想着事情能一步到位，这会导致开发成本过高，系统太复杂，不敢上线(影响太大)，复杂度上升导致bug过多，或者达不到预期，从而导致一堆人花了很长时间的努力全部白费。
b、要学会将一件大的事情，分割成多个小的、可快速完成的事情来实施，快速迭代开发。
c、开发的工作日尽量不要超过3天，1个星期的工作量的就已经是很容易半途而废的了。
3、需求确定之后，开发过程中，不要随意更改、添加
a、在需求讨论的时候，可以把以后可能会扩展的尽量想到，最终的目标等都可以讨论，这个时候需要尽量的详细
b、但在一期开发的时候，只做最核心、最急的几件事情，要做的东西太多，最终只会导致什么都做不了
c、达成共识之后，请需求发起方将讨论确定下来的内容通过邮件的形式发送给相关人员，邮件标题需要有统一前缀，例如【违禁词汇后台改版】- 第一期需求
二、开发过程
1、线上项目修改，必须要有svn，并确认正式版上的相应文件是否已经提交到svn中，并在测试版进行同步
2、开发新功能，必须先在测试机上开发，严禁在正式服务器直接修改
3、需要有相应的测试版数据库，可以找运维组的同学帮忙
4、开发过程中，有不清楚的，需要及时跟需求方进行沟通、反馈
5、必须有修改记录，修改记录里需含有：
a、数据库结构变化，注释
b、新增了哪些文件，做什么
c、修改了哪些文件，分别是为什么
d、各个功能对应哪些文件
6、开发完成之后，需要发送测试确认邮件给需求方，测试之后需要通过邮件回复正式确认，例如【违禁词汇后台改版】- 测试确认
三、部署上线
1、发送邮件，请求运维组同学帮忙备份程序、数据库，并帮忙观察下监控情况，例如【违禁词汇后台改版】- 上线前备份监控
2、将上线步骤通过邮件形式发送给相关人员，没有异议之后，开始下述上线操作。【违禁词汇后台改版】- 上线部署步骤
3、备份完成之后，部署程序到正式版，所有文件更改必须通过svn来更新，不允许直接copy过去上线
4、数据库结构修改部署，先于程序，更改之后马上看下页面以及相应监控是否正常
a、新增：一般不影响旧程序，可以在程序上线之前改，特殊情况自己考虑
b、修改：改了数据库结构之后，旧程序会报错，怎么办？
c、删除：可以在程序上线运行正常之后再删
5、程序文件部署
a、确认正式版的对应文件没有人直接在服务器上修改，如果有，则将正式版的提交，然后在测试版up，再重新进行测试
b、文件新增的，可以在程序上线前更新到正式版
c、更改旧有文件的，如果是后台的，可以先更新后台的，观察没问题之后，前台的如果耦合度不高，可以一个模块一个模块的上线测试
6、上述几步没问题之后，让相关人员在正式版把各个功能都测试一下，并看看其他地方是否会受影响
7、查看相应的数据统计及监控(页面访问、51yes统计、cnzz统计、运维监控、用户反馈)
四、部署出错处理
1、出现问题之后，立即通知相关人员，特别是需要告知自己的leader，协助修复，如果预估修复的时间超过10分钟，项目较重要，则请运维组的同事帮忙进行恢复
2、恢复到旧版本之后，在测试版排查是什么原因导致
3、重新发送新的上线部署步骤邮件，再重新部署
4、没问题之后，邮件告知大家，什么原因导致部署失败，以及如何避免
五、上线后的观察、维护
1、将整个开发过程的开发记录添加到tech后台
2、上线后的一周内，都要时不时的抽时间去了解下相应情况(使用情况、效果如何、用户反馈、有什么不足等)
3、将收集到的情况做相应记录，并记录到后台，为后续开发做准备