项目一旦到了测试环节或者要对外交付的阶段，跟发布有关的记录就不能只留一个干巴巴的版本号了事。ALM Soft这类工具里的发布记录，到底该怎么去维护，后续又要怎样往回查某个发布版本的信息，这个过程里面最重要的事情，是把每一次发布到底纳入了哪些内容、涉及哪些需求、修了哪些缺陷、测试的结果是什么样的，以及最后交出去的那些东西，全都串在同一条链条上。不同的部署版本中，菜单的叫法也许会有一些出入，所以下面我就按照比较常见的ALM发布管理流程来把这些理清楚。很多这一类的平台，都会用Release和Cycle来组织发布的批次，同时它也支持把需求、测试集合和缺陷直接挂到对应的版本下面去。

　　一、ALM Soft发布记录怎么维护

　　发布记录这个东西，不能等到快要交付的时候才急急忙忙地去补，最好是从版本刚刚建立的那一刻，就动手去维护它。要是都堆到后边再去临时整理，就很容易漏掉那些半道加进来的需求，还有被推迟处理的缺陷。

　　1、创建发布版本

　　先到【Releases】或者叫发布管理的地方，按照项目把发布目录搭起来，然后点一下【New Release】，新建一个版本。接着把版本的名字、开始日期、计划什么时候发布、由谁负责，以及这个版本的大致说明都填进去。版本的名字最好能有一套固定的格式，比方说用产品名称加上版本号再加上日期，这样大家喊起来都是一个口径，不会前后冒出好几个不同的叫法，后面不管是谁接手都能一眼看明白。

　　2、拆分发布周期

　　要是一个版本里面还分了好几个阶段，比如开发、联合调试、测试和最终的交付，那就可以在这个版本下面再新增一些Cycle。很多常见的ALM平台都允许在一个Release底下建出好几个Cycle，并且给它们各自填上开始和结束的时间。这样做的好处是，等到以后想要往回查的时候，一眼就能看出来问题到底是在哪个阶段冒出来的，不用再把整个版本的历史翻个底朝天。

　　3、关联需求和缺陷

　　接下来，得把这次发布里包含的新增需求、变更过的需求，还有修复了的缺陷，统统都关联到这个发布版本上去。有些缺陷如果暂时不打算修，也要把推后的原因，还有计划在哪个版本里解决，清楚地写出来，别只简单地标个“延后”。不要只是在附件里上传一份发布说明就算完事，系统里面那些需求和缺陷的状态也得跟着同步更新，要不然两边对不上，后边追溯起来又是一笔糊涂账。

　　4、补齐测试和交付物

　　在正式发布的前头，还要把测试相关的集合、跑出来的执行结果、回归的记录，还有安装包、配置文件、发布说明这些交付的东西，一一关联齐全。文件的命名里面务必带上版本号，可别把不同版本的安装包全都扔在同一个文件夹里，等到后面，连哪个才是要正式交付的那一个都分不出来了，那就很耽误事情。

　　二、ALM Soft发布记录版本怎么回查

　　想要往回查一个历史版本的时候，千万别光知道去翻附件，更把稳的办法，是从发布版本这个入口点进去，然后顺着需求、缺陷、测试，还有基线，一层挨着一层地往下看。

　　1、先从发布列表定位版本

　　可以先到【Releases】里面，用版本名字、发布的日子或者负责人这些条件，把想要的那个版本筛出来。点开目标版本之后，先瞅一眼它最基础的那些信息，以及下头挂着的Cycle，然后再去核实一下关联上去的需求、测试集合和缺陷是不是已经齐了、准了，有没有什么遗漏的地方。

　　2、查看历史的修改记录

　　要是项目里面打开了版本控制的功能，那就可以进到某个对象（比如一个需求或一条缺陷）对应的【History】→【Versions】里头，去翻看它以前的历史版本。很多常见的ALM平台，都能够把对象的旧版本给留存下来，而且还允许一次挑两个版本，去点那个【Compare】来比一比，看看它俩之间到底改动了什么地方。平时在改需求、测试用例，或者动发布说明的时候，随手写上短短的一句为什么要改，以后往回查的时候真的能省下好多时间。

　　3、用基线回看发布当时的状况

　　对于那些里程碑性质的大版本，可以去建一条Baseline，也就是常说的基线。基线就好比是在某一个时间点上，给项目拍下的一张快照，用它来保存当时的那些需求、测试，还有它们之间的关联关系，特别合适。等到需要翻回去看的时候，只要到【Libraries】里面，把那条基线选中，再点一下【Compare To】，就能把它跟另一条基线，或者和现在的实时状态放在一块儿做对比了。

　　4、导出差异记录

　　碰到那种版本变动特别多的情况，不妨把基线比出来的结果，导成一份CSV文件，然后再分给项目的负责人、测试的人和质量的人一块儿去复核。在看那张差异表格的时候，眼睛要重点去抓那些新增的、被改动过的、被删掉的，还有被挪过地方的对象，别只顾着去翻附件有没有更新，毕竟附件更新并不代表关联的数据也都跟着变对了。

　　三、ALM Soft发布记录怎样避免后期混乱

　　发布记录的维护本身要说不算多复杂，真正惹出麻烦的，通常还是名字没有统一起来，还有在中间过程的时候没有及时去更新。项目一忙起来，好多人都习惯了把重要的信息留在邮件或者聊天记录里头，结果系统里面挂着的那些，却还一直是旧的状态。

　　1、统一版本命名

　　所以，发布的版本、安装包、测试报告、缺陷清单，还有发布说明，这些最好都共用同一套版本号来标识。临时打出来的包，一定要单独给它打个标记，可别让它跟正式的安装包搀和在一块儿，否则很容易拿错，等到现场部署的时候就会出乱子。

　　2、每次变更及时更新

　　每次有新的需求加进来、有缺陷被决定推迟、测试又补跑了一轮，或者安装包被替换掉了，这些事情发生以后，都要赶紧把发布记录也更新掉，千万不要把这些变动一直攒到交付的那一天，再一次性去往回补，那样既容易漏东西，也把自己搞得很紧张。

　　3、关键节点建立基线

　　在需求被冻结的那一刻、测试全部跑完的时候，还有正式交付的前夕，这几个关键的时间节点上，可以分别去创建一条基线。常见的ALM平台都允许拿基线去跟踪对象的变化，同时也能去查看到某一个对象在不同基线里面都有过什么样的状态，这样一路跟下来，整个项目的变化过程就都有据可查了。

　　总结

　　总的来讲，要维护好ALM Soft里面的发布记录，以及想要顺利地回查发布版本，大体的处理思路，就是把版本、周期、需求、缺陷、测试还有交付物，都拴在同一条关联的链子上面。平时就顺着版本的推进持续去更新，到了关键的那些时间节点上，把基线保存下来，等到以后需要回头去追溯的时候，再通过历史记录的翻阅和差异比较的手段去回查。这样一来，整个项目交付的来龙去脉就会变得清楚得多，也不会因为信息零散而搞出不必要的返工和扯皮。