真正开写之前，先问个问题，如果把做一个项目当做进行一场足球比赛，各位觉得配置管理员应该是哪个角色？
其实类比很多时候未必真的合适。因为当你做类比的时候，仅仅是抓住了一些共同点，也许不同之处更大，足以让人觉得这种类比不当。类比中融入了你脑子中很多根深蒂固的东西。请原谅我这工科生吧。如果你有更好的类比，也不妨告诉我。
版本管理
工作多年，不管理论中也好，传说中的也罢，配置管理最核心最基本的工作内容就是版本管理，再直白点说就是管理好你的（也是公司的）源代码。
很多公司招配置管理的时候都会要求会使用 CVS（二十年前的??），Clearcase（十多年？？），Subversion（十年？），Git（最近几年）。为啥要求会用这些？这些是什么工具？也许出现早晚不同、理念不同、使用场景不同，但是都有一个共同的特点就是都是版本管理工具（Version Control System)，都是管理配置项版本的。源代码就是配置项，各种文档也是配置项。
是否还记得上一篇中提到的配置识别。识别什么？识别配置项。识别配置项之后首先要做的事就是纳入版本管理。这个时候就需要版本管理工具的支持。光靠拷贝复制粘贴重命名加前后缀各种时间戳是很难做好版本管理的，我们需要工具的支持。人与动物的最大的区别是人会使用工具，不仅如此人还会制作工具。
为什么要工具的支持呢？就像上面所说的每做一次变更，比如每次写完一个功能，或者修复一个 bug，我自己拷贝一份出来，写上修复的 bug 内容，后边再跟一个时间戳不就可以记录下我的工作了么？大学里自己一个人写个 helloworld 这么做也许可以，但是一到大规模工程实践、多人协作这就是另外一回事了。
传说中的版本管理工具是这么诞生：某个教授让手底下的几个学生一起完成一个大作业，要求多人协作，每个人写一部分程序，最后合到一起评分。这个时候问题就来了，几个学生有男有女，分别住在不同的宿舍，有不同的作息时间，如何解决内容共享的问题呢？最朴素的想法就是1）把作业存储到一个公共的地方，这个地方大家都可以访问到 2）如果有个人想要改其中的一个文件，那么他就要把这个文件占有，同时告诉其他人，我要改这个文件其他人不要改，自己改好之后把文件再提交到公共存储上。3）以一个顺序的数字来标识修改的次数，比如这是对作业第5次修改。其实也就相当于自己一个人写 helloworld 时把目录拷贝一份，然后上面写个修改次数或者时间戳。我个人觉得一开始的时候版本工具的作者肯定也没想到这么多，只不过随着使用人数的增多，每个人的使用方法和习惯都不一样，遇到的问题也不一样，从而版本管理工具演进成了现在这个样子，复杂的不行，其实经常使用的功能也就那么几个。
变更管理
对我所管理内容的任何变化的授权或者拒绝都可以称作变更管理。比如我要修改 helloworld.cpp 这个文件，我就要先问我可以改这个文件么? 这个时候就会有人说可以（也许不可以）。如果可以，我自己就去改那个C++文件了；即便不可以，这次变更的请求也都结束了。其实这就是变更管理一个最典型的例子。这里边涉及到的人有我（码农）和允许我改代码的人（CCB），涉及到的配置项有 helloworld.cpp，涉及到的系统有版本管理系统、权限管理系统和审批工作流系统，最后还涉及到一个变更流程。
变更管理可以做得很重，也就是说很规范、很严谨；也可以做得很轻。一般对质量要求的越高（风险带来的损失大），在变更管理这块做得就越严格，但是带来的问题可能就是资源的消耗和周期长；对发布版本的速度要求高的项目，一般变更管理则做得很轻。无所谓好坏，适合自己公司、适合当前项目的就好。
构建管理
简单说就是把一些零散的源代码、文档、脚本、配置文件等等有序组合成一个可以安装的软件、可上架的 app、可部署的网站或者可工作的服务的过程。此过程可繁可简，可正式可山寨，总之是一个可发挥度十分高的工作。
还记得多年之前的构建管理还是相当的单纯，一般是指把源代码编译、链接、打包成一个可执行二进制文件的过程。如果做得更多的一点还可以把相关的文档包括进来；做得华丽一点可以刻到磁盘上（CD，DVD 均可）。因为那个年代还是“软件”的年代，堆网站还只能算副业、偏门。
互联网时代悄然而至，各种大型、超大型站点诞生。有的解释型语言直接丢文件，有的还是需要弄成个 jar 包或者 war 包扔上去。总之这个时候很多构建的产物不再需要分发给千千万万的终端用户，而是部署到 IDC 的服务器上。
现在移动互联网如火如荼。哪个公司要是没有个自己的 app 都不好意思去拉 VC。虽说很多公司的 app 一点营养都没有，但是还是有很多不错的 app 诞生，1024就是一个，我说的是游戏 APP，不是网站。嗯，不要想多了。
虽说最终产物不一致，但从源代码到最终可安装、或者可部署、可上架的过程都要经过一系列的处理，小到改个版本号，大到加上 pre-checkin, code-convention,单元测试，静态扫描，代码混淆，编译，链接，post-build 等等，中间可以做得事情真的很多。
如果说版本管理体现出一个公司是否走上正轨，那么构建管理则体现出一个公司研发的效率。
名词解释
· 配置项：
· 可交付物：
· CCB：Change Control Board，变更控制委员会，对所有的变更请求作出批准或者拒绝的一小撮人。
