3.2.2 严谨的上市版本发布流程
软件版本是软件产品在生命周期中某个时间点的一个快照，是软件呈现的一种形态。不同的版本往往存在功能或特性方面的差异，对用户的使用有直接影响，软件版本的重要性不言而喻。软件版本发布看似简单，但我们经常会在这个过程中犯一些不应该犯的错误，接下来这个案例，相信读者并不陌生。在下面这段对话中，Carl讲述了一个在版本发布过程中出现人为错误的案例，Sherry给出了解决同类问题的优秀实践。
Carl：之前，我们公司的一款已上市的智能录音笔在软件更新后，其声音转文字功能失效了。
Sherry：问题挺严重。
Carl：是的。幸好这个问题在代理商试机时被发现，于是，我们连夜把解决了此问题的补丁版本发给生产车间，生产车间工人只好在所有退回的产品上重新烧录软件。
Sherry：怎么回事呢？
Carl：之前的版本发错了。小A是一位新来的开发人员，某天，他接到了对此产品进行软件定制的任务，也就是需要对软件进行变更，以满足用户对软件的定制化需求。此款产品属于销售多年的老款产品，公司不再为它提供更新，因此，它不在公司日常维护产品列表中。另外，其代码编译服务器存在一些历史遗留问题，该产品的软件主管正好又在这一天请假了。于是，小A首先从项目经理那里接到任务，然后从代码仓库中获取代码并在本机修改后，直接编译，最后把版本发给测试人员小B。而小B，正好也是新来的测试工程师，对公司的版本发布流程等不太熟悉，收到小A发布的版本后，进行了测试。在确认功能修改满足用户需求后，小B认为测试可以通过。在项目经理的催促下，小A原本想把测试通过的版本发出去，但在发邮件时，因操作失误，将个人计算机上保存的另一个中间版本发给了生产车间。
Sherry：我们也曾遇到过这种问题。这种问题是一个令所有软件研发人员深恶痛绝的低级问题。
Carl：是的。你们是如何解决此类问题的呢？
Sherry：从流程着手解决。如果原来有版本发布流程，那么对现有流程进行完善；如果没有相应的版本发布流程，那么需要创建新流程。软件版本的上市发布需要一套受控的流程（见图3-9），其核心思想是通过多层审批流程确保发布版本的正确性。版本正确性的审核重点是测试工程师的审核（或者称为确认），也就是由测试工程师确认开发工程师上传到版本发布平台上的软件压缩包是否为测试通过的版本。判断软件压缩包是否为测试通过的版本的方法或工具有很多（如文件对比工具Beyond Compare等），然而，审核判断方法是否有效的工作则由测试主管负责。例如，测试工程师可能利用工具自动比较测试通过的版本文件与开发工程师上传的软件压缩包文件是否一致，并留下比较记录，测试主管确认记录即可。同时，开发主管和项目助理，以及其他干系人（图3-9省略部分，视项目具体情况可选）也将从不同角度，对软件压缩包的发布依赖文件及归档流程的前后逻辑进行严格审核。经过多方对发布内容、归档逻辑的严格审核后，软件经理将根据各干系人的审核通过状态进行最后的发布审批。此时发布的软件版本对于用户的使用来说已经是安全的了，为什么还需要文控工程师的审批呢？这正是版本发布流程规范化的特点。文控工程师站在文控体系的角度，统一审核所有对外版本的发布说明、存放软件的服务器的安全性等，以便所有用户能在发布平台上获取统一的正式版本。只有通过了文控工程师的审批，软件版本才能进入最后的“生效”状态。
图3-9 软件版本上市发布流程
Carl：非常好！软件版本的发布还有专门的发布流程，特别是版本的发布有多层级角色的发布权限与状态的管控，值得我们学习！
思考
版本发布是一件严谨的事情，一个版本就是一个产品。对于软件版本的发布，不同公司会采取不同的管理措施，包括专人管理，以及流程和平台管控。
（1）专人管理
1）由开发工程师或开发主管外发。
2）由测试工程师或测试主管外发。
3）由项目经理外发。
（2）流程和平台管控
如果公司有一套严谨的版本发布流程，那么软件版本在通过公司内部的层层审批后，即可正式发布。
