怎么让版本迭代科学严密

版本控制在软件持续开发当中还是非常非常重要的，如果管理不好，很容易把多个版本搞乱，给开发，测试，运维和运营都带来很多沟通协作上面的麻烦，大大降低团队的工作效率，本文就讲解一下我们的控制规范。

版本迭代控制的意义

1. 方便团队的沟通，大家讨论功能和BUG可以带上版本信息，起到一个名字的作用。

2. 问题可追溯性，可以通过把代码，数据库，测试BUG记录版本统一，追溯BUG可能被引入的时间和版本。

3. 实现测试版本到生产版本的平稳过度，基本杜绝测试版本转移到生产版本产生BUG的情况。例如，后台可能在开发和测试数据库都手工进行了表调整，在转移到生产环境，忘记了在生产数据库进行调整。

4. 更好的发挥出自动化测试的效果。

版本号的定义

1. 版本编号包括3个部分，例如3.1.2，第3个数字2是前端/后台自己内部的小修改，不影响交互的修改，例如前端修改了展现样式。功能添加，接口和数据库的修改都是大版本调整，大修改版本定义需要技术团队开会统一决定。

2. 版本的改变，每个组，安卓/IOS/WEB/后台/数据库，都需要记录版本更新记录，所有相关的代码和数据库脚本都需要放入的GIT里面，并且根目录下面需要有一个Release_版本号.txt文件，记录这个版本的变化情况，数据记录增加了那些字段和用途，代码需要记录增加了那些功能。放在代码当中的版本文件方便程序员阅读，该文件还需要在QQ群文件里面保留一份，方便其他成员的阅读。

3. 开发版本，测试版本，自动化测试版本，生产版本的命名规则，例如3.1.2版本开发版本为3.1.2D，D代表Development，测试版本为3.1.2T，T代表Test，自动化测试版本3.1.2A，A代表Automation，生产版本3.1.2。生产版本一定是低现在的开发版本，测试版本的。

4. 数据库版本保留的是数据库修改的SQL脚本，数据的修改都是大修改，所以数据库版本只有2位数字，如3.1，没有3.1.2。

5. 前2个数字相同，例如后台3.1.4，安卓3.1.1，IOS3.1.5，都必须保证是可以统一使用的，第3位数字是组内自主版本，前2位是团队版本控制位数。

6. 数据库的版本维护由后台团队管理。

版本使用流程

1. 新版本开发启动，技术团队讨论开会，讨论需要修改的东西。如果是新功能，数据库发生改变，接口发生改变，版本号要统一升级，讨论结束后，由产品总监在群文件里面发布当前开发新版本号。如果只局部组内修改，则可以由各组自己控制。

2. 版本开发使用主线开发，分支发布的原则，分支的最后一个版本对应了当前的生产版本，分支只保留生产版本，不保留测试和开发版本。开发版本就是主线版本，没有开发分支，除非有特殊情况(这种情况需要各组提出，开会决定，不能组内自己决定，例如代码优化有分支，这是特殊情况)。

3. 开发结束以后进入测试阶段，如果开发内容都是在本版本开发的，则不需要开测试分支，测试版本和开发版本都使用主线。到了测试后期，如果出现新功能修改需求，但这些需求不在本版本发布，则必须建立测试分支，后面该版本的BUG修改需要在测试分支进行，不能在开发版本进行。

4. 生产发布后，主线版本（若没有测试分支）/测试分支，自动改变标签成为生产版本，为了测试分支和生产分支，测试分支标签必须加入T后缀，当生产发布后，T后缀去掉，分支变成生产分支，所以测试分支只存在于开发的周期中，本开发周期结束，测试分支就消失了。

测试环节版本发布

1. 安卓/IOS/WEB/后台，发布测试版本需要在群文件里面记录发布日志，每个组一个日志，上面写上发布的版本号，发布人和发布时间，日志文件中最后一条就是当前测试的版本。测试和生产需要有各自的发布日志，测试一个文件，生产一个文件。如果测试版本发布只是一个组的事情，其他组可以不更新日志。日志的最后一条被自动认为是当前的测试版本。例如：后台版本(3.1.2T)，IOS（3.1.4T）。

2. 测试版本发布需要实现自动化，测试版本需要出一个手工测试版本和一个自动化测试版本，手工测试版本交付手工测试流程，自动化版本需要交付小司做自动化测试。手工版本和测试版本可能会有些差异，差异要通过打包环境变量来控制，不能手工修改代码来实现，手工修改代码可能会导致引入新的BUG。

3. 每个测试版本发布，每个小组需要增加自己的第3位数字，来区分一个开发周期中的多次测试版本发布，测试团队提的BUG，也需要注明测试的版本，并且加上当前的后台的版本，后台当前版本在测试发布日志中可以查到，数据库版本不需要，数据库版本就是前两位数字。这样，这个BUG发生的环境被准确的记录下来，前端版本，后台版本和数据库版本，方便我们后面追溯问题。对于非人工的发布的BUG，测试团队需要手工找到对应的后台版本，加入后台版本信息，人工提的BUG，需要在提出的时候加入版本，新需求类型的BUG，需要有独立分类，不需要版本信息。

4. 测试环境发布实现和生产环境一样的自动化。

生产环节版本发布

生产环节发布需要实现Jenkings的自动化，自动化在生成环境运行升级SQL脚本，自动化编译前后台代码，自动化部署后台代码和发布前端代码。安卓和IOS可以发布到某个目录，然后再由人工去提交到苹果商店和安卓市场。

生产环境的自动化发布是为了保证，测试环境和生产环境的一致性，不能在这个环节加入新的人为的BUG。尤其数据库脚本，必须要记录，保证测试环境的一致性。因为生产发布和最后测试发布使用了相同的代码，相同的数据库更新脚本，这样就保证了测试环境和生产环境的一致性。

为了尽量减少数据对测试的影响，需要定期把生产环境数据转移到测试环境当中，使用接近生产环境的数据来做测试。

自动化测试流程

这里讲到的自动化测试流程是我们自己开发的一套APP的UI自动化测试方案，标定流程是用来解决ASSERTION的判断数据问题，具体请参看"APP的UI自动化测试"。

1. 自动化测试用例脚本也需要进行版本控制，版本号只使用2位数字，如3.1版本，不会有3.1.2版本，也需要分测试版本和生产版本，不需要开发版本。生产版本号低于测试版本号。

2. 自动化测试开始之前，需要写测试日志，测试日志需要发给技术总监审核，测试日志需要记录当前测试版本情况和标定轮版本情况，需要包括前端和后台的版本信息。例如，当前生产环境是3.1.5版本，测试版本是3.2.1版本。

3. 然后开启自动化测试的标定轮，标定轮需要当前发布版本3.1.5版本进行标定。运维需要提供环境建立自动化脚本，该脚本把自动把生产数据拉到自动测试化环境，部署生产版本3.1.5版本到自动化测试环境，自动化测试和生产环境是独立的，但使用的数据版本和后台版本是相同的，后台数据库版本都是3.1版本，后台代码版本是3.1.5版本。环境建立好后，自动化人员使用前端生产版本，如3.1.6来进行标定流程。标定流程测试用例应该是全部走通的，如果走不通，说明发现了上一个版本的BUG，导致的原因可能是数据的不同，也可能是配置有问题。如果这个流程有啥问题，自动化测试人员需要在测试日志里面写出来。

4. 标定流程完成以后，就开始测试3.2.1A版本，运维提供自动化升级脚本，把自动化测试数据库版本3.1升级到3.2，并且自动化部署3.2.X的后台版本，自动化升级完成后，自动化人员开始使用3.2.1A版本跑的测试用例3.1.X，这一轮测试，对于没有修改的地方不应该产生断言，而对于修改的地方会产生断言，这是正常的。数据库库存从3.1版本升级到3.2版本，数据是没有变化的，变化的数据结构，可能表有增加或者表字段有所增加。

5. 第3轮需要调整测试用例，测试用例生成新的版本3.2版本，在生产发布之前，可以根据情况跑几次3.2版本的测试用例，测试环境仍然是自动化测试环境。

6. 生产发布以后，在生产环境跑3.2版本的测试用例，这个用例起到冒烟测试的作用。这个流程用例跑完，是不应该改变生产环境的数据。如果测试用例里面有添加数据的用例，就必须加入数据删除的用例。保证跑完测试用例之后，没有添加和修改任何数据。冒烟测试用例，可以选择性提取一些测试用例，不需要跑全部测试用例，否则太耗时。

数据库版本

1. FSDFS部分，不做版本，只是包含当前版本，里面包含了历史全部图片，即使用户删除图片，也只是逻辑上的删除，物理上是存在的，这样保证了FASDFS和全部版本的数据库都可以无缝工作。

2. 数据库，最好实现版本备份，方便后期BUG追溯时候可以重新恢复当时的环境，如果数据库备份太大，占用太大存储空间，就保存前个版本备份即可。数据库备份只保存生产环境版本，测试环境使用完，就抛弃，每次测试轮开始，都拉过来生产数据。

3. 数据库变迁脚本，必须和代码一样保留，这样可以知道在不同版本之间，修改了那些表和字段，方便问题的追溯。

4. 测试环节尽量使用近期版本的生产数据，这样可以大大降低数据对测试准确度的影响，也可以让测试更加接近真实生产环境。