软件工程学习笔记12——运行维护篇

一、版本发布

1、关于软件版本

对软件版本来说，包含两部分含义，一部分代表特定功能集合，一部分代表某一次特定的代码构建结果。

为了明确标识软件版本，需要对版本进行编号。目前业界在软件版本的命名上，通常会采用以下方式：

• 主版本号 . 子版本号.[. 修正版本号.[构建版本号]]
  比如说：1.2.1、2.0、3.0.1 build-123。

其中主版本号和子版本号用来标识功能变化，小的功能变化增加子版本号，大的功能变化增加主版本号。修正版本号则表示功能不变化的情况下修复 Bug，而构建版本号表示一次新的构建，这个通常由编译程序自动生成。

2、版本发布前，做好版本发布的规划

这里的关键在于，要在用户（或客户）的心理预期和你软件的实际情况之间，达到一种平衡，让软件的功能和质量，满足好用户的预期。

要合理管理好用户的预期，达到好的发布效果，就需要在版本发布前先做好版本发布的规划。

版本的发布规划，主要是指是：

规划好要发布的功能
对于必须要有的功能，那么要保证软件中有这个功能才能发布，对于不是必需的功能，可以以后再逐步完善。

设计好发布的策略
考虑好是直接发布给所有用户？还是先让一部分用户试用？让一部分用户使用 Beta 版也是一个好的发布策略；还有就是采用灰度测试的发布策略，让一小部分用户先用新功能，如果没发现什么问题，再继续扩大使用的用户规模。

综合性的版本发布计划
在确定了要发布的功能、定义好了质量标准、设计好了发布策略，就可以制定一个综合性的版本发布计划了，确定好发布的时间点。
这个发布计划，不止是项目内部成员，还需要和项目之外利益相关方，比如客户、市场运营人员，大家一起确定最终的发布计划。

3、规范好发布流程，保障发布质量

发布版本之前，需要注意的几个问题：

• 必须保证要编译部署的是正确的版本。
• 要保证版本稳定可靠。
• 要在发布失败后能回滚。

我们也可以制定合理的流程，来应用这些好的实践，保证发布的质量：

• 在发布之前要做代码冻结
  代码冻结的原则就是尽可能减少代码的修改，避免引起不稳定。
• 对代码冻结后发现的 Bug 要分级
  在代码冻结后，可能还存在一些 Bug，对于这些 Bug，要有一个简单的分级：是否在发布前修改，还是留在发布后再修改。
• 每次修复 Bug 后，发布新的候选版本
  进入代码冻结后还需要对一些 Bug 进行修复，每一次修复完 Bug 后，就要生成一个新的候选发布版本，比如说 1.1 RC1、1.1 RC2。
• 每次部署新的候选发布版本后，要做回归测试
• 申请上线发布
  在正式上线发布前，通常还需要有一个申请和审批的流程，避免上线过于随意导致问题，避免和其他部门的上线冲突。
<