虽然这是配置管理新手上路系列，但是很多基本名词解释，我觉得大多数正在阅读这篇文章的读者，之前肯定读过很多的配置管理相关书籍，看过很多解释。在这一系列中，对于专有名字，我会以名词解释的形式在底部给出，正文还是希望以口水话叙述，这样大家容易明白。
重要的配置项都纳入版本管理
什么叫重要的配置项？可能有用的配置项都可以称之为重要的配置项。比如：
- 源代码
- 文档
- 构建脚本
- 配置文件
- 数据库文件
- 初始化数据
- 第三方库
- 其它和项目相关的信息
上面几类为啥要纳入版本库管理就不需要说了。但是下面有些特殊点要谈谈。
初始化数据：这里要有个权衡。如果初始化数据不是很大，和源代码放到一个库里是可以的。如果数据量太大，则可以考虑放到单独的一个库。因为毕竟这部分数据更新频率不是很快，如果和代码放到一起则意味着经常需要下载很多份不经常变化的信息。与其这样不如放到一个相对独立的地方，也容易管理。
第三方库： 这个也要分源码和二进制两种情况来分析。如果我们可以获取第三方库的源代码，且库文件的生成环境要求很简单、构建过程也不复杂，那么就可以直接把第三库代码和产品代码都放到一个库里；相反，如果第三方库构建环境很麻烦、构建过程复杂，那么可以放在一个独立的库里维护，在需要引用的时候直接引用二进制文件就可以。
问题1：那么问题来了，照片算重要配置项么？产品构建产生的二进制包呢？要纳入版本库管理么？
- 照片和二进制包都是配置项，可以纳入版本库管理，但是如果文件很大，则可以考虑其它方式存储。
- 对着白板拍下来的讨论信息肯定要纳入版本库管理，而那种团建性质的照片最好单独建库或者放到文件服务器上共享。
- 构建生成的包最好放到产品库上存储和分享
问题2：文档放到版本库里管好？还是放 wiki 上好？
如果像“古代”那种好几十页的配置管理计划最好还是放到版本库里管，因为放 wiki 上也只能以一个附件的形式体现。但是现在的配置管理关于文档管理的理念是流程工具化、文档脚本化，只有一些无法用脚本、工具体现的信息才真正要记录到文档中。所以一般产品、技术相关的版本库里好些，因为文档距离代码近啊，而流程、计划等和项目管理相关的放到 wiki 上更加有利于分享、协同更新。
命名规范
虽然现在一切从简，但是最好有一个统一的命名规范。比如如果文档的名字可能出现在浏览器的路径上，那么最好用连字符而不是下划线。
每个配置项都要有唯一的标识。
名词解释：
产品库：放构建出来的产品的服务器
菜鸟思考：NA
网友评论