产品升级策略
目前由于客户的反馈量比较大,因此产品频繁升级,在升级过程中,当然也犯了一些错误,总结一下,以免再次犯错:
1:一定要有自动化的build工具,由于项目比较小,所以采用手工编译的方式,还没有感觉太麻烦,单是当项目的文件增多的时候,一定要使用自动化build工具,否则将严重影响产品的发布,而且出错几率特别大.
2:一定要有自动化的项目检查工具,由于任何一个Exe/Dll,都是需要正确的名称,正确的版本号,公司名称,生成图标等检查项,这些项目如果都是人来检查就累死了,因此需要一个工具来协助检查,另外该工具需要具备的两外一项功能就是检查每个项目引用的Dll或com组件是否一致,由于一些Dll/com组件有多个版本,因此协调不同项目的引用一致检查,也是很繁琐的.
3:一定要通过所有的单元测试,由于在项目的修改过程中,很多函数的修订人可能变更,因此,通过单元测试是验证代码合理性的唯一标准.
4:一定要经过文档核对,由于在产品升级过程中,部分界面或功能进行了修订,这样就造成了,文档和产品的不一致性,因此,需要经过文档部门的核对,产品才能出货.
5:最重要的是要经过测试部门的大规模测试,否则是不能出货的.
通过上边5点,说明了一个问题,就是一个产品真正Release一个版本,是要经过多个步骤的,而这个步骤的自动化程度越高,当然效率也就更大,但是这也是一个系统的工作,人工参与是不能缺少的,这就说明Release一个新版本必须要慎重,所以频繁Release新版本不一定是好的事情.
昨天兄弟Liuzhp和我讨论后,总结的方法如下:
1:一个产品一定要有一个稳定版本,并围绕这个稳定版本,进行产品的深加工,并发布这个版本.
2:对于产品发现的Bug要立刻修订,但是并不发布新的版本,而是发布累积升级包,通过升级来解决系统中存在的问题.
3:当升级补丁累积到一定的数量级后,在进行产品的升级,并发布新的版本.
这种策略的好处是可以稳定一个版本,便于市场化的发行和运作,并通过升级对用户提供技术支持,也可以避免由于大规模版本升级造成的测试/文档/市场/研发等部门的压力,并通过升级累积来逐步修订系统,并且为新版本的发行积累了经验,也可以使研发部门可以逐步提升产品的质量.
1:一定要有自动化的build工具,由于项目比较小,所以采用手工编译的方式,还没有感觉太麻烦,单是当项目的文件增多的时候,一定要使用自动化build工具,否则将严重影响产品的发布,而且出错几率特别大.
2:一定要有自动化的项目检查工具,由于任何一个Exe/Dll,都是需要正确的名称,正确的版本号,公司名称,生成图标等检查项,这些项目如果都是人来检查就累死了,因此需要一个工具来协助检查,另外该工具需要具备的两外一项功能就是检查每个项目引用的Dll或com组件是否一致,由于一些Dll/com组件有多个版本,因此协调不同项目的引用一致检查,也是很繁琐的.
3:一定要通过所有的单元测试,由于在项目的修改过程中,很多函数的修订人可能变更,因此,通过单元测试是验证代码合理性的唯一标准.
4:一定要经过文档核对,由于在产品升级过程中,部分界面或功能进行了修订,这样就造成了,文档和产品的不一致性,因此,需要经过文档部门的核对,产品才能出货.
5:最重要的是要经过测试部门的大规模测试,否则是不能出货的.
通过上边5点,说明了一个问题,就是一个产品真正Release一个版本,是要经过多个步骤的,而这个步骤的自动化程度越高,当然效率也就更大,但是这也是一个系统的工作,人工参与是不能缺少的,这就说明Release一个新版本必须要慎重,所以频繁Release新版本不一定是好的事情.
昨天兄弟Liuzhp和我讨论后,总结的方法如下:
1:一个产品一定要有一个稳定版本,并围绕这个稳定版本,进行产品的深加工,并发布这个版本.
2:对于产品发现的Bug要立刻修订,但是并不发布新的版本,而是发布累积升级包,通过升级来解决系统中存在的问题.
3:当升级补丁累积到一定的数量级后,在进行产品的升级,并发布新的版本.
这种策略的好处是可以稳定一个版本,便于市场化的发行和运作,并通过升级对用户提供技术支持,也可以避免由于大规模版本升级造成的测试/文档/市场/研发等部门的压力,并通过升级累积来逐步修订系统,并且为新版本的发行积累了经验,也可以使研发部门可以逐步提升产品的质量.
