MPLS 次末跳弹出配置_CD2.0 读书笔记 | 软件配置管理的自查七问

注：本文来本自于“持续交付2.0交流群”的群友 陈玉毅，笔名小玉一休，并已获得原作者授权，发表于本公众号。

今天跟小伙伴们分享的是：乔梁老师的专著《持续交付2.0》第 11 章“软件配置管理”。

1 “一切自动化”是持续交付部署流水线的一个重要原则，也是提升“持续交付验证环”运转速度的一个重要影响因素

随着软件发布速度越来越快，软件配置管理已经成为“一切自动化”的基石。这两句话，总结概括就是：配置管理是基础，应高度重视配置管理的基础工作是否做到位了。如何实施呢？乔老师给出建议：将一切纳入配置管理，遵循软件配置管理的 3 个基本原则：一切皆有版本；共享唯一受信源；标准化与自动化。

1)一切皆有版本，指的是：当需要更快地发布软件时，就需要对生产软件过程中的相关内容进行管理，这些内容不仅仅是源代码，配置文件，运行数据，还包括：测试工具包或测试用类库，测试相关的代码，测试数据，测试脚本等。不妨按照：基础操作系统层，标准软件层，应用软件层，进行分类整理，对其中内容的任何一次变更，都将产生一次新的快照，亦即新的版本对应关系。这就是持续交付中版本管理的第一原则：将所有内容进行版本变更管理，亦即，一切皆须版本管理。

2)共享唯一受信源，指的是：整个组织需要管理研发团队的所有仓库：需求仓库，代码仓库，软件包仓库，所有团队成员都应该以这些仓库中的内容为基准，相互协作，以确保所有成员所获取的信息都是一致的。其中的软件包仓库，包括 3 种类型：临时产物仓库，正式发布包仓库，外部软件包私服仓库。乔老师提醒，很多团队对于临时产品仓库和外部软件包私服仓库的管理较为薄弱。在持续交付模式下，它们也是需要重点关注和管理的部分。

3)标准化与自动化，指的是：软件配置管理应该制订相应的标准与规范，例如：分支策略，分支命名，分支Tag命名，产品特性命名以及存放位置，源代码目录结构等。当研发团队成员都了解并遵守这些标准与规范后，不仅仅能够减少不必要的沟通成本，还能够将更多的日常事务性操作自动化，从而释放更多的人力资源，并大大降低手工操作带来的种种失误。

《持续交付2.0》中提到，规范化和标准化并不等于僵化，所有的规范化管理都应该有相应的改进机制，能够不断发现规范化管理中的可优化点，并持续进行优化，这一点在大型团队中尤其重要。

2

良好的软件配置管理是打造持续交付部署流水线，加速持续验证环的基础支撑。

我们可以用下面5个问题来验证检查研发团队是否对一切都做了版本管理：

Q-1：产品源代码和测试代码是否放入了版本控制系统？

Q-2：软件应用的配置信息是否放入了版本控制系统？

Q-3：各种运行环境的系统配置是否放入了版本控制系统？

Q-4：自动化的构建和部署脚本是否放入了版本控制系统？

Q-5：软件包是否进行了版本管理？

研发团队也可以尝试挑战一下，检验软件配置管理是否做得足够好：

Q-S1：只要从源代码仓库中检出产品源代码，就可以一键自动化构建出完整的应用软件包吗？

Q-S2：在没有他人的帮助下，任何研发团队成员都可以一键自动化构建出一套应用软件系统，用于体验产品新功能吗？

版本管理七问让我认识到差距。还是需要反复研读第十一章，争取把配置管理的基础打得再稳固一些。

希望乔老师的《持续交付2.0》是锦鲤，能够帮助提升研发效率。

在快速变化的互联网环境下，效率代表着未来。

作者介绍

陈玉毅，字晓宇，笔名小玉一休。开源社区的追随者与贡献者，拥有丰富的产品规划，架构设计和团队管理经验。擅长组织研发团队对技术路线进行预研及技术选型，追求简单高效，敏捷交付的产品研发模式。