通用技术产品团队管理 - 版本规划

沙漠丶 · 2018年03月20日 · 1568 次阅读

　　最近兄弟部门部门做了比较大的调整。需要重新去定义产品，并做好产品的版本规划。从质量管理部 OKR 来分析，支持产品部门做好产品规划也是个优先任务。
　　（实际是以前没有明确，达成约定的版本规划和版本号定义…）

　　一个好的产品规划，除了对自己的产品有充分清晰地思考之外，还要兼顾外界的技术趋势、业界的动态、公司资源的考量。一定不能盲目地去加各种各样的需求，或者毫无目的地去做版本迭代。每个版本的需求一定都是基于产品目前的现状，市场的情况，最后基于产品发展的目的而去做的。
　　这是我总结的产品规划流程图：

　　因为对具体的产品业务不清楚，所以在职能擅长的范畴内，我会在产品版本命名规则，环境分层两方面给与产品部门具体的支持和建议。

软件版本号的命名规范与原则
　　为了在软件产品生命周期中更好的沟通和标记，很多公司对版本命名都有自己的一套规范，例如：

<名称><主版本号>.<子版本号>
<名称><主版本号>.<子版本号>.<阶段版本号><日期版本号加希腊字母版本号>
<名称><主版本号>.<子版本号><日期版本号加希腊字母版本号> 　　我们应该对软件的版本号命名的规范和原则有一定的了解。

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 日