产品版本规划

    最近兄弟部门部门做了比较大的调整。需要重新去定义产品，并做好产品的版本规划。从质量管理部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日为周期为例，该类情况可参考以下流程进行版本发布！

    角色：开发，测试，开发负责人、版本负责人

    环境：开发环境、测试环境、准生产环境

开发版本：

测试版本：

产品研发过程管理的方法和工具

使用Redmine进行研发管理，Redmine不仅可以用来做软件研发过程管理，而且可以用来管理非软件研发的项目。它给整个团队一个总览图，同时记录所有的细节。