| 配置管理怎么才能体现出价值？做研发人员、测试人员和项目经理最头疼的事。 |
什么事最头疼？就是构建管理。很多配置管理的问题都是构建管理的问题。
这个产品怎编译？（这是新加入项目的成员最头疼的事）
为什么同样的代码，在我这不工作了？
7.2.1 的安装包在哪里？
为啥这个产品的两个包大小不一？
怎么构建这么慢？我都吃饭回来了，还没编译好？
为啥对构建管理大家出的问题最多呢？因为这部分涉及的人、涉及的流程、涉及的配置项也是最多的。很多很多的细节需要去关注，忘了关注哪一环，哪一环就会通过一个个的问题补偿回来。
构建管理的原则
那么怎么才能做好构建管理呢？
受控、可靠、一致性的构建环境
易理解的构建脚本
可重现的构建过程
急速的构建速度
迅速解决构建问题
受控、可靠、一致的构建环境
| 如果配置管理员对构建环境都无法掌控，还谈什么构建管理。 |
构建管理交给配置管理工程师去做的价值在哪里？首先就是研发人员都搞不定的构建环境，我能搞定，而且是能快速搞定。简单的构建环境，装好个 IDE，点个按钮就能编译产品，这样做调试代码还可以，但是当项目变大，人员变多这样做就不合适了。终归，我们需要一套干净的构建环境来构建产品。所有要发布的产品都以从这套环境构建出来的产品为准，包括测试、打包、上线等。绝对不能让研发人员在构建环境上调试代码，也不能让测试人员在上面直接部署服务，进行测试。
构建环境要受控
构建环境受控这里是指受配置管理团队的控制。配置管理团队负责的产品构建环境是用来编译出产品，用来发布或者上线的环境，不是用来调试编译过程、不是用来验证产品功能的环境（配置管理团队专门为研发人员搭建的个人开发环境不在此列）。
配置管理团队负责的构建环境，除了配置管理团队和相关运维人员外，其他人都不得访问。访问受控。
构建环境上除非经过配置管理团队授权，运维人员等不得更新构建环境上的软件、更改配置。配置受控。
除非特殊需要，否则不得安装杀毒软件。配置管理员也不得把不相关的文件下载到构建环境中。
除非特殊需要，否则构建环境不开启磁盘加密、安全扫描等功能。
构建环境要可靠
可靠指的是什么？是指机器可靠、网络可靠、环境可靠。
把一些过保的机器丢给配置管理做构建环境，还谈什么机器可靠？说不定什么机器硬盘就挂了。
现在很多构建过程都要去下载一些包到本地。网络时好时坏，总是丢包重传，一会影响构建速度，二会破坏构建过程。代码本身没问题，结果因为无法下载某些包从而构建失败就悲催了。（后面会讲搭建内部各种源）。
禁止非授权人员访问构建环境，避免意外更改对构建环境的影响。
构建环境要一致
构建环境一致是指所有同类型的构建服务器的硬件、软件都一致。包括：
硬件配置、驱动版本
软件版本、安装路径、系统变量、软件配置
| 举个例子：两台构建 java 的机器，一个安装了 JDK1.7，一个安装了 JDK1.8；一个yum 直接安装，一个源码编译。这样的两台机器构建同一个项目，很容易造成找不到JDK，编译不过去，编译出来的产品不能部署或者无法正确运行。 一个比较好的做法就是把构建环境固化到文档，同时固化成一个模板。同类型的构建服务器只需要使用模板再部署一套即可。省去了手工一步步去搭建的烦恼，且搭建时间短、过程可靠。文档也是必不可少的，当需要对模板进行变更的时候，也有据可查，不至于让环境搭建出来，因为缺少必要的文档或者知识传承，最后大家都不敢对模板进行修改。 |
小结
使用在保的高性能计算型服务器作为构建服务器
配置管理团队负责构建环境的搭建，且每类环境都有文档记录（环境最好是文档化、模板化、自动化）
只保留运维和配置管理团队对构建环境的访问权限，且运维每次对环境进行操作都需要经过配置管理团队的确认。
使用虚拟化、容器等技术来快速搭建出一致的构建环境。
