数字化配置管理尝试

软件进入汽车业带来很多变化，大家都着急忙慌地赶着上市，配置管理也随之需要轻便灵活起来，在实际工作中，由于做好太笨重，确实有被直接放弃的趋势。

从我的角度来看，它的价值和使命远没到被淘汰的时候，但需要与时俱进，这就是今天再次写它的原因。

先思考一个问题，如果我们把配置管理做完美是什么样子呢？

首先，要从每个配置项的版本控制做起，要记录清晰的变更履历，要经过多人有效的评审，要有评审记录，评审出来的问题要继续有跟踪记录，最后版本要锁定，且锁定不是口头说说，要在一些特定的存储区域用工具锁定，其他人无法更改……极为繁琐，一处出问题，可能就要从头来一遍。

但是，单个配置项的版本控制及释放虽繁但不难，别忘了，各个配置项之间还会发生复杂的关系，它们并不是单一的、独立的、解耦的，它们之间会互相依赖、互为输入、互相嵌套，可谓牵一发而动全身。

比如，又到了交付的日子，配置管理员准备打条基线，但在Excel里一项一项地梳理配置项时，发现还缺一项测试没结果。那就去问测试吧，测试说，还需要系统输入一个需求参数，不然我没法测。然后，系统回去查了查文档，确实是漏了，之前没考虑到，但这个参数涉及到功能安全，可能要和功能安全的再确认下……一番着急忙慌之后，功能安全文档要改，系统需求也要改，代码也要改，还要重新评审，评审过程中，发现这是个挺大的变更，还得上CCB……

好吧，配置管理员说那算了吧，你来，我配置不了了。

所以，实际工作中，非常难去做到真正完美的配置管理，因为有太多的限制且耗费太大资源了。

在汽车行业里，项目组需要在项目生命周期的特定里程碑冻结一组配置项，以在项目开发中实现可追溯性和完整性，这是汽车行业配置管理的出发点。

再换种通俗点的说法，可追溯性就是能找到当初是怎么想的、怎么做的；完整性就是该做的都做了，不要遗漏。

比如，出了工厂或售后问题回去翻旧账，能找到当初怎么做的，也好定位Root Cause；分配任务、协同工作、传递信息时，能够保证准确交互交流，别用错了标定参数，集错了软件版本，用了废弃的需求；项目交接时可以找到完整的、正确的文件版本；一个新的项目要拉一个分支去开发，可以找到对应的准确的源代码或其他基础文件……

这大约是配置管理在汽车软件领域的一些比较有代表性的价值。如果没有比较好的管理，杂乱的信息很容易被搞混、被误读、被遗忘。

那么，支持它这价值的最主要或者最不可或缺的是什么要素呢？我总结为“版本控制 结构化”，这应该是最起码的原则要求了。

版本控制比较容易理解。结构化呢？

结构化分两种，一种是静态结构化，这个也相对容易理解，想想我们的文件夹就能明白了，但这个阶段只是实现了一堆东西的堆砌存储，尚不能充分用起来。

第二种就是动态结构化，这其实是配置管理的精髓。我们需要在某个节点去把静态结构化存储的一堆文件牵一条线穿起来，这条线就是基线或者有时候叫快照，它进而定义了项目在这个点的状态。

另外，结构化并不仅仅是简单清晰的一级一级拆分的金字塔结构，可能会有一个上级对多个下级，一个下级对多个上级，会交织在一起。

举个简单的例子，我们有同一级别的ABCDE五类文档，每类文档又有12345五个版本，这五五二十五个文档会安安静静地被静态结构化，说人话就是被按版本存储起来了。

但穿线方式有很多种，比如A5B5C5D5E5，也可以是杂乱的A3B4C1D3E2，对于一种交付目的可能会用前者，而另一种目的则可能会用后者，这是需要动态去寻找、确认的，这还是理想的最简单情况。

实际情况中，显然不会是这么简单的结构，会分很多等级，会相互交织，相互调用，复杂程度就是非常高了。

配置管理要交付的产物，就是在“结构化 版本控制”的前提下实现这个正确的穿线。

写到这里呢，应该是把价值骨干理清楚了。

接下来开始寻找枝叶，把最繁琐的部分澄清下，回想一下前面提到的完美配置管理的烦人之处。

比如，配置项有严格的命名规则，不是每个人都知道，也不是每个人都愿意遵守，实际中会有各种命名混乱，而命名一旦混乱，也就难以找到正确的信息；

文档更新时，要记录变更履历，但具体的内容完整与否、准确与否、及时与否，都是取决于个人的责任心和细心程度，难保会做得多好；

配置项要发布，一般也就是有正式的评审或签字，评审还要基于一套Checklist，之后还要特别操作锁定版本，这也是个很冗长的过程；

配置项的选择及基线的选择都要花一番精力去找，而且一旦一处信息错了或要更新，很多其他引用该信息的文档文件都要对应更新；

有依赖的配置项还要建立追溯，不管是系统里建立链接，还是文本里描述，都是繁琐的，也要实时更新；

信息来源分散，责任人分散，同样的信息也要以不同格式放入不同的文档模板中，想要收集完整准确的信息，自然是颇费周折……

基于这些场景，我们可以提取出一些繁琐关键词，不直观（结构化要靠脑子想象）、人工工作多（完成品质依赖于个人意愿和能力）、分散化（大量沟通协调）、按部就班（过于重视理论严谨性和完整性，而忽略实际使用需求）、耦合性强（牵一发而动全身）。

那么，这些东西是我们可以考虑动手术的地方。

找到了要守住的价值底线，也找到了繁琐的部分，我们可以尝试一种可能简便的方式，但前提是要使用数字化协同开发工具链，比如，Polarion、JIRA、RTC、Pingcode、飞书等等。

一般来说，这样的软件ALM工具会有非常丰富的功能，从需求管理、配置管理、缺陷管理、测试管理、项目管理、文档管理、交付管理等都会涉及到，我们主要用到建立工作项和文件存储的功能。

结合前一部分梳理出来的繁琐关键词和工具自身的能力，可以总结一些尝试方向，结构可视化、信息同源化、基线灵活化和痕迹自动化，这些概念不是很好理解，下面详细解释一下。

在汽车行业，我们整体的模式还是以项目为组织方式和以里程碑交付为目标的。

首先，我们可以通过工具提供的工作项建立的功能（如里程碑、交付、释放、工包、工件等）来搭建一个按照里程碑序列进行的结构，就是这三五个或七八个大的里程碑拉成了我们整个项目的框架。按照项目的复杂程度，还可以建立更细节的下一层次里程碑。

这里多讲一句，工具一般都会有这样的功能，就是建立不同工作项之间的链接关系，包括后面也一样，我们就是通过链接来实现结构化的，通过工具的不同展示效果（目录式、金字塔式、看板式等）实现可视化的。

搭建好整个交付框架后，我们可以根据想要管理的配置项建立更多的工作项，依然是使用链接的方式。在具体的每个工作项里，可以添加适用的里程碑、计划的时间、文件的链接及相应的文字说明，也可以开发特定的字段菜单。

信息同源化是说什么呢？我们要先花一定的精力保证那些基础数据是正确的，而且保持在一个源头、一个区域，各个其他区域使用这个数据是通过链接或ID去调用的，当同源的数据改变后，所有调用这个数据的区域都会自动更新，这样可以减少大量的重复工作和错误。

另外，对于单个配置项的版本控制，其中最重要的是可以知道每次的变更点，人工录入显然耗时、耗力、也易错，这时，工具的自动痕迹留存就体现了很大的价值，我们还可以轻松地对比出来二者的差异，比人工描述自然更完整准确。

痕迹留存在客观上也起到了评审的作用，如果没有任何记录和约束，评审常常会流于形式，但强制的痕迹留存会让人天然提高一些对这个交付物的重视程度。

写到这里，应该是解决了一部分繁琐的问题，也基本保留了“版本控制 结构化”的价值。

或许，有人还记得住，前面提的那个“穿线”的比喻，我们似乎还没有实现这个最终的穿线。

实际项目场景中，很多情况是最新版本作为基线版本，也就是所谓的穿线。那么，我们可以在对应工作项做一个“时间点”的描述，时间线是一维的，时间点是单一的，在这个时间点之前的所有的链接的配置项的最新状态就是要被穿线的配置项。如果有时候需要某些配置项以前的版本，而非最新的，可以在对应工作项用文字特别说明一下。这在一定程度上，也算是实现了基线灵活化的目标。

正文先写到这里，整个过程下来，我们会发现，单纯的交付一份配置管理文档的工作消失了，它被融合到了整个开发和项目管理中，这是数字化工具给我们的帮助，也是对配置管理深入理解后的异化或改进。不过，数字化工具仍然还只是工具，它能否解决我们的问题，关键是要看如何用。

当然，有时候仅仅是我们一厢情愿，实际使用中会有很多问题，工具不会用、有自己的习惯、不愿改变、不愿分享……

所以，尽管数字化是未来，但需要不断尝试、不断适配、不断优化、不断落地，这是个求索的过程。

最后需要说明的是，本文侧重描述了项目层面的交付物的配置管理，而广义上的配置管理可能会涉及到持续集成、分支策略、协同编码、缺陷管理等等更底层的东西，暂不扩展。