最近兄弟部门部门做了比较大的调整。需要重新去定义产品，并做好产品的版本规划。从质量管理部OKR来分析，支持产品部门做好产品规划也是个优先任务。
（实际是以前没有明确，达成约定的版本规划和版本号定义…）
一个好的产品规划，除了对自己的产品有充分清晰地思考之外，还要兼顾外界的技术趋势、业界的动态、公司资源的考量。一定不能盲目地去加各种各样的需求，或者毫无目的地去做版本迭代。每个版本的需求一定都是基于产品目前的现状，市场的情况，最后基于产品发展的目的而去做的。
这是我总结的产品规划流程图：
因为对具体的产品业务不清楚，所以在职能擅长的范畴内，我会在产品版本命名规则，环境分层两方面给与产品部门具体的支持和建议。
软件版本号的命名规范与原则
为了在软件产品生命周期中更好的沟通和标记，很多公司对版本命名都有自己的一套规范，例如：
- <名称>_<主版本号>.<子版本号>_<SVN最后提交数>
- <名称>_<主版本号>.<子版本号>.<阶段版本号>_<日期版本号加希腊字母版本号>
- <名称>_<主版本号>.<子版本号>_<日期版本号加希腊字母版本号>
我们应该对软件的版本号命名的规范和原则有一定的了解。
1、APP、软件的版本阶段
Alpha版：也叫α版，此版本主要是以实现软件功能为主，通常只在软件开发者内部交流，一般而言，该版本软件的Bug较多，需要继续修改。
Beta版：此版本相对于α版已经有了很大的改进，消除了严重的错误，但还是存在着一些缺陷，需要经过多次测试来进一步消除，此版本主要的修改对像是软件的UI。
RC版：此版本已经相当成熟了，基本上不存在导致错误的BUG，与即将发行的正式版相差无几，测试人员基本通过的版本。
Release版：此版本意味着"最终版本"、"上线版本"，，在前面版本的一系列测试版之后，终归会有一个正式版本，是最终交付用户使用的一个版本。该版本有时也称为标准版。一般情况下，Release不会以单词形式出现在软件封面上，取而代之的是符号(R)。
2、版本号的命名规范与原则
软件版本号有四部分组成：<主版本号.><子版本号>.<阶段版本号>.<日期版本号加希腊字母版本号>。希腊字母版本号共有5种：base、alpha、beta、RC、Release。 例如：1.0.0.180313_base
通常，完全的版本号定义，分三项： <主版本号.><子版本号>.<阶段版本号>, 1.1.0
3、版本号修改规则
主版本号(1.x.x)：当功能模块有较大的变动，比如增加多个模块或者整体架构发生变化。此版本号由项目决定是否修改。
子版本号(x.1.x)：当功能有一定的增加或变化，比如增加了对权限控制、增加自定义视图等功能。此版本号由项目决定是否修改。
阶段版本号(x.x.1)：一般是 Bug 修复或是一些小的变动，要经常发布更新版，时间间隔不限，修复一个严重的bug即可发布一个修订版。此版本号由项目经理决定是否修改。
日期版本号(x.x.x.180313)：用于记录修改项目的当前日期，每天对项目的修改都需要更改日期版本号。此版本号由开发人员决定是否修改。
希腊字母版本号(x.x.x.x_beta):：此版本号用于标注当前版本的软件处于哪个开发阶段，当软件进入到另一个阶段时需要修改此版本号。此版本号由项目经理决定是否修改。
4、版本号的阶段标识
按照软件的研发过程，可以再将版本号进行相应的标注管理，但管理会变得过于复杂，视具体情况而定！
5、关于APP的版本管理
以Android为例， Android中有 versionCode 和 versionName，他们分别所代表的意思如下：
verisonCode:内部版本号，必须是整型。用来区分版本的新旧，版本号越大，代表距当前越近的发布版本。给开发者内部使用的。
versionName:向用户展示的版本号，必须是字符串，这个版本号就是我们可以用来遵循规范的位置，可以作为版本比较的，判断是否需要提示更新、是否需要强制更新的依据。
使用SCM进行代码管理
公司使用的SCM系统是SVN， 以下结合SVN介绍怎样进行代码版本管理。
Subversion有一个很标准的目录结构，是这样的。比如项目是proj，svn地址为svn://proj/，那么标准的svn布局是
svn://proj/
|
+-trunk
+-branches
+-tags
SVN有两种普遍的管理模式：
以Trunk做开发：
所有的开发都是基于trunk进行开发
时间区间(1)
- (1)的起始时间是1.0.0开发的开始。
- 在(1)期间，没有任何用户使用1.0.0（还没有发布），开发人员直接在Trunk1.0.0上开发。
- (1)的结束时间是3.0开发的结束时间。结束时发布1.0.0产品，在SVN上创建1.0.0 Tag。这时Trunk1.0.0自动变成Trunk 1.0.1。
时间区间(2)
- (2)的起始时间是1.0.1开发的开始。
- 如果在(2)期间，用户报告1.0.0的Bug或者一些很急迫的功能要求，并且需要马上修复实现。那么：
- 在Tag：1.0.0_release基础上建立branches:1.0.0_bugfix，并且发布补丁包。
- 选择性的把 dev_1.0.0_bugfix这个分支merge回trunk（什么时候进行这步操作，要根据具体情况）
- (2)的结束时间是Turnk1.0.1开发的结束时间。结束时发布1.0.1产品。此时做以下事情：
- 将branches:1.0.0_bugfix的代码合并到Trunk1.0.1上。并且发布锁定Tag：1.0.1_release代码避免任何进一步的修改。
- 这时Trunk1.0.1自动变成Trunk 1.0.2。
以分支做开发：
时间区间(1)
- (1)的起始时间是1.0.0开发的开始。
- 在(1)期间，没有任何用户使用1.0.0（还没有发布），开发人员直接在Trunk1.0.0上开发。
- (1)的结束时间是3.0开发的结束时间。结束时发布1.0.0产品，在SVN上创建1.0.0 Tag，同时创建1.0.1 Branch。这时Trunk1.0.0自动变成Trunk 1.0.1。
时间区间(2)
- (2)的起始时间是1.0.1开发的开始。
- 在(2)期间，因为有用户使用1.0.0，所以1.0.1所有的开发工作在Branch1.0.1上进行。
- 如果在(2)期间，用户报告1.0.0的Bug，并且需要马上修复。那么：
- 在1.0.1 Trunk上对问题进行修复，并且发布补丁包。
- 将此改动合并到Branch1.0.1上。
- (2)的结束时间是Branch1.0.1开发的结束时间。结束时发布1.0.1产品。此时做以下事情：
- 合并代码之前，在1.0.1 Trunk上建立Tag，如：1.0.0_20180313。用来表示将1.0.1合并进来之前的代码。
- 将Branch1.0.1的代码合并到Trunk1.0.1上。并且锁定Trunk1.0.1代码避免任何进一步的修改。
- 从Trunk1.0.1上创建Branch 1.0.2，用于进行Branch 1.0.2的开发。
一些注意事项：
如果修复Bug，可以在Trunk或者Branch上做，但是一定要使用SubVersion的合并功能，而不是在Trunk和Branch上分别改两遍。如果改两遍，造成的结果是在要将Branch合并到Trunk上出现冲突。
如果有些核心数据结构的变动，将它放在小版本升级后的第一个迭代进行。避免对用户造成升级困难，或者用户需要重新装载所有数据。
合并代码的时候需要非常小心，保证Branch上的代码和合并以后Trunk的代码一样非常关键。如果不一样会造成这种情况：第一个从Branch上发布的产品没有问题；后来为了修复一个Bug，从Trunk上发布一个新版本后，出现了第一个发布没有出现的问题。
环境版本如何扭转
项目因具体情况可能会出现多个测试环境进行维护的情况，这里以三套环境，N日为周期为例，该类情况可参考以下流程进行版本发布！
角色：开发，测试，开发负责人、版本负责人
环境：开发环境、测试环境、准生产环境
时间线 | 事务 |
T日 | 9点版本负责人创建版本 |
9-16点，开发人员开发功能，修改BUG（BUG解决关联禅道版本） | |
16-18点，开发负责人确认版本信息（开发功能，测试注意事项，SVN模块最后version），提交版本负责人 | |
版本负责统计项目各产品版本信息（开发功能，测试注意事项，SVN模块最后version），驱动测试 | |
T+N日 | T+1日9点，测试人员更新测试环境 |
T+1日至T+N日15点，测试-测试版本（依据ＢＵＧ，功能，测试注意事项进行测试），提交ＢＵＧ（ＢＵＧ关联禅道版本） | |
T+N日15..30-17点，确认测试环境版本信息，提供项目经理（邮件描述版本更新内容及测试结果） | |
项目经理确认版本测试结果，驱动准生产环境进行更新 | |
T+N日17点-18点。冒烟准生产 | |
T+N+1日 | 测试准生产 |
开发版本：
测试版本：
产品研发过程管理的方法和工具
使用Redmine进行研发管理，Redmine不仅可以用来做软件研发过程管理，而且可以用来管理非软件研发的项目。它给整个团队一个总览图，同时记录所有的细节。
