软件工程之美35讲——版本发布:软件上线只是新的开始

软件工程之美35讲——版本发布:软件上线只是新的开始

版本号构成

  版本号 . 子版本号.[. 修正版本号.[构建版本号]]比如说:1.2.1、2.0、3.0.1 build-123。
  其中主版本号和子版本号用来标识功能变化,小的功能变化增加子版本号,大的功能变化增加主版本号。
  修正版本号则表示功能不变化的情况下修复 Bug,而构建版本号表示一次新的构建,这个通常由编译程序自动生成。团队中对版本有了清晰的定义和良好的版本编号,在讨论版本时,你就可以根据版本号清楚地知道应该有哪些功能,属于哪一次的构建结果。在修复 Bug 或者增加功能时,开发人员也能清楚地知道代码应该加入哪个版本。在验证 Bug 时,测试人员就可以知道应该在哪个版本中验证 Bug 有没有被修复。

怎么做好版本号管理

版本发布前,做好版本发布的规划

  • 首先是规划好要发布的功能。在发布前,搞清楚哪些是用户必须要有的功能,哪些是用户可以没有的功能。对于必须要有的功能,那么要保证软件中有这个功能才能发布,对于不是必需的功能,可以以后再逐步完善。
  • 再有就是要设计好发布的策略。考虑好是直接发布给所有用户?还是先让一部分用户试用?比如说可以先让内部用户使用,内部用户对软件质量问题容忍度是很高的,还可以帮助发现很多问题。
  • 最后,就是有一个综合性的版本发布计划。在确定了要发布的功能、定义好了质量标准、设计好了发布策略,就可以制定一个综合性的版本发布计划了,确定好发布的时间点。

规范好发布流程,保障发布质量

  • 在发布之前要做代码冻结。

  什么是代码冻结呢?就是在发布之前,对于要发布的版本,在源代码管理工具中,专门创建一个 release 分支,然后对于这个分支的代码,冻结功能的修改,不接受新功能的增加,甚至重要性不高的 Bug 都不修改,只修复重要的 Bug。由于严格的控制代码的修改,这样可以让版本的质量逐步趋于稳定。

  • 对代码冻结后发现的 Bug 要分级

在代码冻结后,可能还存在一些 Bug,测试的过程中也会新增一些 Bug。代码冻结的原则就是尽可能减少代码的修改,避免引起不稳定。所以对于这些 Bug,要有一个简单的分级:是否在发布前修改,还是留在发布后再修改。至于如何对一个 Bug 分级,这需要项目负责人和产品负责人一起确认。

  • 每次修复 Bug 后,发布新的候选版本

  进入代码冻结后,开发人员还需要对一些 Bug 进行修复,每一次修复完 Bug 后,就要生成一个新的候选发布版本,比如说 1.1 RC1、1.1 RC2。关于生成发布版本,现在比较流行的做法是和持续集成系统整合,完全自动化。也就是在自动化测试通过之后,会自动构建,生成各个环境的发布版本。这样好处是,可以避免人为失误导致的错误,另外程序的配置管理做好了的话,只要测试环境的版本在测试环境测试没问题,那么就可以认为在生产环境的版本也是正常的。自动化构建,生成发布版本并不复杂,各个语言都有成熟的方案,如果你还不了解的话,可以通过搜索引擎搜索关键字:“[对应平台] 自动打包”,例如搜索“iOS 自动打包”、“iOS build automation”这样的关键字。其中稍微有点麻烦的就是如何应用不同环境下的不同配置,比如说测试环境连测试环境服务器,生产环境连生产环境服务器。有关程序配置管理部分,可以参考这篇文章:《大型项目程序配置管理演化之路》

  • 每次部署新的候选发布版本后,要做回归测试

  在每次开发人员部署新的候选发布版本到测试环境后,还需要做一次回归测试。也就是说在 Bug 修复完,对主要流程要重新测试一遍,同时还要对之前确认过的 Bug 再确认一遍,以确保 Bug 确实修复了,并且没有引入新的 Bug。如果当前候选发布版本达到版本发布的质量标准后,就可以准备发布了。

  • 申请上线发布

  上线发布是一件很严谨的事,所以在正式上线发布前,通常还需要有一个申请和审批的流程。审批的主要目的是要有人或者有部门统筹对所有的上线发布有一个全面的了解和控制,避免上线过于随意导致问题,避免和其他部门的上线冲突。

  • 部署发布

  如果已经实现了自动化,部署发布应该是非常简单的一步。如果还没有自动化部署发布,也需要事先将详细的操作步骤写下来,避免部署发布时发生纰漏,这样在实际部署发布时,按照事先写好的步骤操作就不容易出现错误。

  • 上线后的测试

  项目上线后,测试人员需要马上对已经上线的版本做一个主要功能的测试,以确保线上运行正常。如果做好了数据监控,还同时要对一些关键数据进行监控,例如服务器 CPU 利用率、内存占用率、服务出错率等数据。如果万一发现版本上线后出现问题,需要考虑按照事先准备好的回滚方案进行回滚操作,尽量将损失降到最低。通常不到万不得已,不建议马上对问题打补丁进行修复。因为哪怕很小的代码修改,都可能会引入新的 Bug。而重新做一遍回归测试,耗时会比较长。以上就是版本发布的一个常见流程,你也可以基于这个流程制定适合你项目的流程,让你的版本发布更加稳定可靠。

posted @ 2021-01-20 17:34  段志轩  阅读(15)  评论(0编辑  收藏