码迷,mamicode.com
首页 > 其他好文 > 详细

产品版本规划

时间:2018-04-04 12:52:02      阅读:594      评论:0      收藏:0      [点我收藏+]

标签:避免   使用   而不是   定义   项目   and   标准版   release   规划   

    最近兄弟部门部门做了比较大的调整。需要重新去定义产品,并做好产品的版本规划。从质量管理部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点,测试-测试版本(依据BUG,功能,测试注意事项进行测试),提交BUG(BUG关联禅道版本)

?   T+N日15..30-17点,确认测试环境版本信息,提供项目经理(邮件描述版本更新内容及测试结果)

?   项目经理确认版本测试结果,驱动准生产环境进行更新

?   T+N日17点-18点。冒烟准生产

T+N+1日

测试准生产

 

开发版本:技术分享图片

 

测试版本:

技术分享图片

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

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

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

技术分享图片

技术分享图片

产品版本规划

标签:避免   使用   而不是   定义   项目   and   标准版   release   规划   

原文地址:https://www.cnblogs.com/YatHo/p/8715838.html

(0)
(0)
   
举报
评论 一句话评论(0
登录后才能评论!
© 2014 mamicode.com 版权所有  联系我们:gaon5@hotmail.com
迷上了代码!