目前在公司参与开发的一个项目是一个非常成熟稳定的项目，项目已经在全国的经销商推广使用了几年了，因此对于新版本的每次升级首要考虑的不影响用户的使用的情况下发布新功能和修复bug。对于开发人员而言，每次的新版本发布将会面临着很大的压力。

因为即使我们再三小心，也难免在发布新版本时，不对用户产生丝毫的影响。有时候甚至会产生些比较严重和紧急的Bug。

经历过几次新版本的发布后，我对此进行了些思考，总结以下几点：

1.每次发布新版本的间隔时间不宜过长，新版本中包括的需求和Bug不宜过多，应该根据需求和Bug的紧急和重要程度来排序，然后选择一定数量的新需求和Bug来发布。（比如每月发布一次新版本，每次累计需求和bug不超过30个为宜，当然这是要根据项目的具体情况而言的。)

2.关于需求的理解，在需求讨论会议结束后，开发人员会根据自己的理解做出需求规格说明书，建议将需求规格说明书发给需求人员确认，如果有必要也可以发给客户进去一次确认，如果没有专门的需求人员则可以直接和用户约好时间进行确认。在需求规格说明书确认完成后，编写详细设计后，在开发组内进行评审完成后，建议也将详细设计给实施人员和运维人员进行一些说明，这样一来可以避免实施和运维最后开发完项目才了解需求的实现，同时也可以让他们尽早的提出些建议。

3.项目组内的成员之间要相互进行代码的Review，这样既可以防止一些错误的出现，也可以相互学习，提高技能，同时还可以提高代码的质量。虽然这样会增加成本，但是好处也是显而易见的。建议代码的Review作为一项制度能够确立下来，比如规定每周3下午14:00--15:00和周5下午的14:00--15:00进行代码Review。

4.在每次进行Bug修复和新需求的开发时，一定要进行严格的单元测试，并做成单元测试文档，在自己完成单元测试文档的

编写后，应该将单元测试用例在组内进行评审，评审完成后由开发人员自己先测试一遍，然后第二负责人再测试一遍。然后

再交给测试人员进行测试。

5.要给测试人员足够的时间进行测试，如果测试组测试后觉得风险较大，可以延迟一段时间发布(比如延迟一周发布),如果测试中发现有些问题可能需要比较长的时间才能解决，可以考虑将这些问题留待下次发布时解决。当前前提是要保证这些问题不发布，不对用户使用系统产生重大的影响。

6.在发布的前2周最好分支一个版本出来，将这个版本作为本次发布的基础，新开发的代码或不能在这次发布时完成的代码不要再迁入这个分支中，即使迁入也要屏蔽掉，将此版本发布，交给测试组人员进行测试。测试后发现的Bug也将在这个分支版本上进行修改。以后再合并到主干代码中。

7.在发布的前一周，将准备发布的系统发布到公司内部的模拟环境中，并由公司的内部实施和测试人员进行试用，这样尽可能的减少发布时产生的风险。

8.在发布的前2个工作日，由测试组人员评估此次发布可能产生的风险以及测试的覆盖率。然后根据测试人员判断和开发人员的反馈意见作出是否按时发布的判断。