插播个今天刚发生的事。某神在没数据备份，运维只做了个快照的情况下直接操作线上 gitlab 服务器，结果把某个目录删了。回来让运维从快照恢复数据。运维说快照有问题，恢复不了了。。。居然恢复不了了。然后下班点，大神在公司解决问题，运维回家了。。。正常点回家了。
构建过程可重复，构建产物可重现
这是什么梗呢？为啥构建过程要可重现？其实这条是基于下面的假设的。
假设在一个配置管理员受控的构建系统中，如果使用了相同的构建机器、相同的构建脚本，依然来编译同样版本的代码时，得到的构建产物应该是一样的。
环境相同、配置相同、构建脚本相同、构建过程相同，那么最后的构建产物应该是一样的。
举个🌰：在pek-bld-001这台机器上，/home/cmbuild/workspace 的目录下我用下面的命令签出一份修订版本号为1234的 svn 的代码，然后编译出一个版本号为1.0.1的 abc.jar 文件；
svn co -r 1234 http://svn.scmroad.com/abc
cd abc
mvn package
假设过了一个月后，我依然重复上述操作，要保证我依然可以得到相同的结果，相同的一个 abc.jar 文件。如果说这个编译过程就是个一次性的事情，那构建管理就不好玩了。如果只知道要一个 1.0.1 版本的 abc.jar， 这个时候只有构建环境、构建脚本，但是无法生成相同的产物，多尴尬呀。
影响构建产物的因素
- 构建环境变化，比如有人升级了操作系统。以前的环境下可以正确编译出 abc.jar 这个文件，现在不可以了。
- 构建脚本变化，比如有人改了构建脚本。构建脚本要求所有的 java 项目都要用 gradle 编译，可以前的项目代码用的是 maven
- 代码变化。当时的版本是1234是我们知道的一个版本。如果我们没有记录下当时abc.jar 所对应的修订版本号，是很难回溯到当时代码的版本的。
为什么要做这些
携程线上服务宕机事件大家都知道吧？如果不知道，我后面也会把详细的分析贴出来。在那种线上服务都被删的情况下？作为配置管理员要能做到哪些呢？
- 快速找到当前线上服务所对应的版本库版本。比如线上服务abc.jar 对应的源代码库 abc 的 1234 版本。
- 利用构建脚本迅速从构建环境中构建出产品包。比如1.0.1版本的 abc.jar
- 把这个 jar 文件快速分发到研发自测环境，测试人员用的测试环境、预生产环境
只要测试人员给力，能快速做完回归测试，如果没问题，还是可以直接上线，恢复服务的。当然像携程那么大的网站恢复起来，也不是一时半刻容易的事。
小结
通过各种措施，保证构建过程的可重复，构建产物的可重现是配置管理中对构建管理最基本的要求。从这里也可以看到配置管理中对版本管理的重要性了。没有版本管理的支撑，怎么找到当时的代码，怎么找到当时的脚本和配置？版本管理是做好配置管理的基础，而构建管理是对研发最有帮助的环节。做好这一步绝对是研发团队最可爱的人，做不好你就是团队的坑货。
网友评论