软件工程：版本发布

最新推荐文章于 2025-03-11 14:30:49 发布

OceanStar的学习笔记

最新推荐文章于 2025-03-11 14:30:49 发布

阅读量3.3k

点赞数 4

分类专栏：计算机理论与基础文章标签：软件工程

原文链接：https://time.geekbang.org/

版权

计算机理论与基础专栏收录该内容

310 篇文章

订阅专栏

说到版本发布，对于很多开发人员来说，觉得只是一个很简单的事情，就是将程序编译打包部署，但实际发布的时候，却经常出现发布错版本的问题，或者是发布前修改了一点代码导致上线出现bug的情况产生。

而版本发布对于很多项目管理着来说，又是一个很纠结的事情，觉得还有很多功能没完成，很多bug还没有改完，害怕用户负面评价，结果时间一拖再拖，迟迟无法上线。

那应该如何做好版本发布，保障好发布产品的质量呢？

关于软件版本

“版本的含义”是什么呢？

不同语境下，版本的含义也有所不同。比如产品经理会对开发人员说：“这个功能我们会放在下个版本中实现”，开发人员对测试人员说：“这个bug在昨天的版本中已经修复了”。

这里产品经理说的“版本”是指特定功能的集合，开发人员说的“版本”是指一次程序的构建结果。也就是对软件版本来说，包含两部分含义，一部分代表特定功能集合，一部分代表某一次特定的代码构建结果。

为了明确标识软件版本，需要对版本进行编号。

编号格式：主版本号 . 子版本号.[. 修正版本号.[构建版本号]]，比如1.2.1、2.0、3.0.1 build-123。

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

团队中对版本有了清晰的定义和良好的版本编号，在讨论版本时，你就可以根据版本号清楚
地知道应该有哪些功能，属于哪一次的构建结果。在修复 Bug 或者增加功能时，开发人员
也能清楚地知道代码应该加入哪个版本。在验证 Bug 时，测试人员就可以知道应该在哪个
版本中验证 Bug 有没有被修复。

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

回到前面的问题，为什么有的项目管理者会在发布前感觉没准备好，害怕上线发布呢？根源上，还是对于功能和质量没有信心，担心发布后获得负面的评价。

而实际上，并不代表你需要完成所有的功能，或者没有任何 Bug，有一个完美的版本才能上线。毕竟追求完美是没有止境的，这世界上也不存在完美的软件，很多著名的软件，比如Windows、Office、iOS 都免不了在发布后还要打补丁。

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

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

版本的发布规划，要规划哪些内容呢？

（1）规划好要发布的功能

要发布之前，搞清楚哪些是用户必须有的功能，哪些是用户可以没有的功能
对于必须有的功能，要么要保证软件中有这个功能才能发布，对于不是必需的功能，可以以后逐步完善。

（2）定义好发布的质量标准

在发布前，搞清楚你的用户对质量的容忍度如何，对哪些功能的质量要求高，对哪些功能的质量要求没那么高。
对于那些用户在意的功能，要具有较高的发布标准，反之，则可以有较低的质量标准。

（3）设计好发布的策略

考虑好是直接发布给所有用户？还是先让一部分用户试用？比如说可以先让内部用户使用，内部用户对软件质量问题容忍度是很高的，还可以帮助发现很多问题
让一部分用户使用 Beta 版也是一个好的发布策略，当用户知道你的软件还是 Beta 版的时候，要求会比较低一点，可以接受一些不那么严重的 Bug。还有就是采用灰度测试的发布策略，让一小部分用户先用新功能，如果没发现什么问题，再继续扩大使用的用户规模，如果有问题，也只是影响少量用户。

（4）要有一个综合性的版本发布计划。

在确定了要发布的功能、定义好了质量标准、设计好了发布策略，就可以制定一个综合性的版本发布计划了，确定好发布的时间点。
这个发布计划，不止是项目内部成员，还需要和项目之外利益相关方，比如客户、市场运营人员，大家一起确定最终的发布计划。
在对版本的发布做好规划后，就不用再纠结于该不该发布，该什么时候发布的问题。有功能没完成没关系，关键要看这个功能是不是必须要有；有 Bug 没有修复完成，是不是影响发布，要看这些 Bug 是不是影响发布的质量标准；还可以采用一些像 Beta 版、小规模用户试用的发布策略，降低用户对功能和质量的预期。

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

发布版本需要注意什么问题

在规划好发布的版本后，要发布版本似乎是一件很简单的事，就是将源代码编码、部署。但发布版本，可能并不是像你想的那么容易，这其中有几个需要注意的问题。

（1）必须保证要编译部署的是正确的版本：虽然一般来说，开发人员不会犯这样的错误，但是如果发布了错误的版本，后果可能很严重，所以要引起足够重视。

（2）保证版本稳定可靠。每一次对代码的修改，都可能导致新的 Bug 产生。如果你的代码库在发布之前还一直在增加新的功能或者不停的修复bug，那么质量是难以稳定下来的。

（3）发布失败之后能回滚。没有谁能保证程序发布后没有严重问题，所以最保险的版本就是在部署后，如果发布版本出现严重问题，就应该对程序进行回滚操作，恢复到部署之前的状态。即使有些不可逆的升级，也需要事先做好应对措施，比如发布公告，停止服务，尽快修复。

针对这些问题，已经有些好的实践，比如说代码冻结，bug分级，回归测试等可以降低发布风险，保障发布产品的质量。在版本发布上，我们可以指定合理的流程，来应用好这些实践，保障发布的质量。

一般的发布流程

（1）在发布之前做代码冻结。

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

（2）对代码冻结后发现的bug要分级。

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

（3）每次修复bug后，发布新的版本

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

（4）每次部署新的候选发布版本后，要做回归测试

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

（5）申请上线发布

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

（6）部署分布

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

（7）上线后测试

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

软件上线只是新的开始

当你的软件上线后，这不代表你的项目就结束了，可能这才只是新的开始。

用户在使用你的产品的时候，可能会遇到一些 Bug 或者是有一些建议，所以需要给用户反馈的渠道，让用户可以有途径对于 Bug 或者功能去反馈。通过收集用户的反馈，可以进一步完善你的软件产品。
只是靠用户主动反馈问题还是不够的，需要主动的对发布的版本进行监控，
- 比如说要收集App Crash 的 Log、监控服务器资源占用情况、监控 API 出错的比例、监控网页响应的速度等数据。
- 当发现数据异常时，很可能说明发布的版本是有问题的，需要及时的应对，回滚版本或者发布新的更新补丁。

总的来说：

发布前，先评估风险，增加相应的监控数据和设置报警的阈值。制定出现问题的应对方案。
上线后，先推送一小部分用户，并同时进行线上数据的监控，如果没有发现异常，自动加大比例，直到完整覆盖；
如果发现异常，自动报警通知相关负责人，上线处理，并直接关闭新功能。

软件成功上线后，也是回顾总结一下整个项目过程的时候了
在这里插入图片描述

总结

版本规划，其实就是通过合理的规划，尽可能的让软件的功能和质量，满足好用户的预期。所以一方面要尽可能提供应有的功能和保证质量，另一方面也可以通过合理的发布策略，例如 beta 测试，降低用户预期。

通过规范的发布流程，可以确保要发布的版本正确以及发布质量的稳定。流程的关键在于发布前要对代码冻结，避免发布前频繁修改代码引入新的 Bug，同时在每次修复 Bug 后，要做回归测试保证 Bug 被修复以及没有引入新的 Bug，上线后还要对线上版本再一次测试，确保没有问题。整个流程中一些手工部署发布的操作应该尽可能自动化。

最后，软件上线只是新的开始，还需要收集用户的反馈，对线上服务进行监控和预警，对整个版本的开发过程进行总结回顾。