4 版本号

开发人员对自己交付的每个服务程序，都应能够识别对应的代码，以便于在对应的代码版本上梳理流程和查找问题。

为此，开发人员给出的每个程序，都需要有一个版本号，一般采用点分4位的格式，形如1.2.3.4。

对于每一个点位代表什么含义，每个公司有自己不同的标准，下面仅提供一种修改版本号的规范。

1、重大改变版本

第一个数字对应重大改变版本。

包括技术方案调整，整体架构修改，服务完全重构，两个版本间协议不再兼容等。

只有发生了重要改变，才会修改这个版本号，一般由技术主管确认即可。

2、迭代版本

第二个数字对应迭代版本。

每次项目迭代增加一个版本号。

这样可以很清楚的记录服务迭代次数，查找问题时，也能很快梳理这个版本对比上次迭代，改变了哪些功能。

这个数字的修改，由项目迭代开发人员操作即可，发布前由技术主管确认。

3、发布更新版本

第三个数字为发布更新版本。

每次更新到线上环境，对用户开放，需要增加此数字。

如果灰度发布过程中发现问题，修复后重新灰度，需要修改此版本号；线上正在运行的服务，发现问题，修复后，也需要修改此版本。

这个数字体现了一次迭代后，项目发布的稳定性。每次迭代版本（第二个数字）更新后，发布版本需要更新归零，重新计数。

这个数字的修改，由项目开发人员操作即可，发布前由技术主管确认。

4、测试版本

第四个数字为测试体验版本号。

测试期间，每次修复bug后，需要重新部署到测试环境验证，需要更新此版本号。

这个版本体现了一次迭代，做了多少次改变，服务才最终稳定。

最终发布时，此版本号可以保留。

每当前几位数字更新后，测试版本归零，重新计数。

这个数字的修改，由项目开发人员操作即可，无需技术主管确认。

5、编译版本号

除了这四个数字外，最后还可以追加一个编译版本号。

由自动编译系统追加，体现在编译文件的后缀名上即可，无需修改程序的版本号信息文件。

编译版本号单调递增，无需清零，体现了这个程序一共使用编译系统编译了多少次，也可以在两次编译之间做出区分。

由于此版本号由编译系统自动生成，即便开发人员忘记修改其他版本号，此版本号也会更新。运维部署后，如出现问题，不至于找不到对应的代码版本。

版本号的目的是识别程序与代码的对应关系，因此在开发过程中，开发人员一定要做好版本维护。结合Git/SVN等代码管理工具，编译版本前，先提交代码。每给出一个版本，就要修改对应的版本字段，确保每次给出的版本都不相同。

这样，发生问题时，才能快速的找到对应代码，进行问题排查，节省时间保证效率。