在《源代码管理的新15条建议 》中的第7条建议提到：每个团队应当对代码配置项和非配置项有所说明，不要假设每个团队新人都是代码配置管理达人，小心自以为是的新手加入一些自以为是的垃圾。虽然可以删除，但发现再删除，其本身就是成本。
在《高效组织的配置管理计划》也提到了产品线层面的配置管理，那么产品开发团队的配置管理到底应该是什么样呢？本文试图来探讨下。
首先说明本文探讨的产品开发团队的特征。这里的产品开发是指围绕某产品或者产品线开发，其产品的生命周期是长于一年以上，为了改进产品，不断有新的要求得到实现满足，也会发现产品的缺陷，需要在开发中解决。 这样的产品开发是不同于短期合同外包项目的，其产品开发团队将较长期的承担此产品（线）的运行维护，增强修改，开发建设。应当说，当前大多数团队是属于这样的团队。
什么是配置管理规则？
配置管理规则这个说法也许过于学术化，讲白了其核心就是文件如何存放和版本升级。而规则即是团队共同遵守的约定。比如在某目录下存放会议纪要，为了便于查找会议纪要的文件名以会议日期开头，格式是YYYYMMDD。
为什么需要产品开发团队的配置管理规则？
1，开发团队是多人组成，规则能够让所有人查询，有依据，协同提供效率
2，产品开发是长期过程，文件会越来越多，如果没有一定的规则，将造成文件遗失或者难以查找。
谁来制定团队的配置管理规则？
团队负责人应当为团队长远的信息资产负责，组织团队成员来商量团队自身的配置管理规则。
如果团队存在配置管理员这样的角色的话，那么配置管理规则的起草和维护当然首先是配置管理员的事情。
团队的配置管理规则有哪些内容？
对于软件开发团队，显然首要的，源代码管理是规则重点覆盖的内容。对于源代码管理，要回答如下典型问题：
1，选择什么样的源代码版本控制工具？如果组织已经选定，或者历史上已经选定，那么需要遵循。这是基础工具，一般不会经常变化，而变化必须经过慎重的考虑，当然往往的这是组织级考虑的内容。所以这个问题对于绝大多数团队而言，不是问题，因为已经有选定的工具。
2，对于源代码，选择什么样的主干分支模式？ 这是显著影响团队效率的选择，必须团队骨干一起来做决定，不同的主干分支模式适用于不同的场景，需要团队中此方面的达人来提供建议，如果团队内难以做决定，麻烦组织中的高手来设计本团队的主干分支模式也是应当的，甚至有组织邀请业界专家来为重要产品线设计主干分支开发模式，并制定规则。
3，对于选定的主干分支模式，有哪些操作注意点，具体而言比如如下问题：
3.1 什么情况下从主干拉出分支？
3.2 什么情况下合并分支到主干？
3.3 什么情况下从分支拉出分支？
3.4 什么情况下从主干合并到分支？
3.5 什么情况下从分支合并到分支？
3.6 什么情况下删除分支？
3.7 如果选择主干无分支，那么需要注意什么？有什么配套手段？
4，源代码检入时需要遵循什么规则？ 如何书写检入说明？ 是否需要与某个变更或者需求或者缺陷进行关联? 要先本地进行静态代码扫描？ 先进行code review？还是后进行扫描，或者code review
5，哪些区域的代码是信息安全高等级代码？ 访问级别比较高，团队外围成员需申请后才能访问？如何申请？
6，哪些区域的代码是核心代码？ 或者是红区代码，但凡此处代码修改，对应的测试范围需要扩大，关联到其它的系统？
7，为了协同工作，在工程师本地电脑上需要如何设置？
