版本控制是配置管理的一项主要内容。我们都知道源代码必须要进行版本控制，以免在软件交付使用时出现因不正确的版本使用带来的问题，特别是存在持续交付和同时并行多个版本参与不同试验的情况下。
但是，除了版本控制就只需要控制源代码就足够了吗？答案是否定的。除了源代码之外，还有以下的内容需要进行版本控制。
1. 关于构建工具、设置、方法的信息
同一版本的源代码使用不同版本的编译工具可能造成两种截然相反的结果——使用某个版本的编译工具可编译成功的代码，使用另一个版本的编译工具可能导致编译失败。同样的，Makefile的构建配置、打安装包的脚本也是这样。
因此，为了保证构建的可重复性，这类信息（可能是描述性的文字说明，也可能是可以自动运行的脚本）也应当在版本控制之下。
2. 广义的源代码（目标码？）
这主要是指每次创建基线时做构建所生成的内容，其中最重要的是常以安装包形式体现出来的构建的最终结果。
3. 产品测试与运行的设置信息
对软件产品进行不同的设置，会严重影响其运行时的性能甚至是功能。因此，在对软件进行不同类型的测试时应该如何设置，把软件部署到实际运行环境时应该如何设置，必须先策划，后验证，而且不能随意更改，纳入版本控制。
4. 产品测试与运行的环境信息
一个软件产品，总是要放入一个运行环境中，不同的环境，对产品的运行会有不同的影响。因此必须定义产品在何种环境下使用。这种测试和运行环境包括计算机、网络等硬件环境，也包括操作系统、中间件、数据库、服务、其他程序等软件环境。定义这个环境，既包括软件、硬件实体，也包括它们的设置。这些环境信息，也应纳入版本控制。
5. 数据库表结构
对于使用数据库的软件产品，要像管理源代码一样管理以DDL （Data Definition Language，数据定义语言）表述的数据库表结构（这通常是一组SQL语句）。类似于编译构建源代码，可生成可运行程序；执行DDL，可生成数据库中特定的表结构。因此，DDL也要像源代码一样纳入版本控制。
6. 测试用数据
要取得预期的测试效果，有些测试数据需要精心设计。将这些测试数据纳入版本控制，可以使后续的回归测试变得简单。
7. 测试用例
测试用例包含自动执行的脚本以及人工执行步骤、预期结果的描述，还有一些测试代码，如桩模块、驱动模块、模拟对象等，也应当纳入版本控制。
可以把测试用例放入源代码版本控制工具，也可以考虑采用专门的测试管理工具来管理。
以上是从源代码构建到部署运行这整个过程中，要纳入版本控制的最重要的7类内容。其他杂七杂八的还有很多，比如程序开发环境中，除了构建工具之外的其他工具及其设置；比如各式各样的尚未包含在以上内容中的文档，等等。总之，所有的有价值的软件研发相关的信息资产，都应纳入版本控制之中。
这正是：
版本控制为哪般，不能狭隘看眼前
价值资产皆受控，研发维护才轻松
参考书目：《软件集成策略——如何有效率地提升质量》，董越，工业出版社
联系客服
