配置管理之构建管理(2)
易理解的构建脚本
为什么要把构建脚本单拿出来重点说？因为我发现在工作中，尤其是存活时间长的公司，基本上都有一个研发都不愿意触碰的构建脚本。这些脚本一般有以下特点
- 语法晦涩诡异，各种暗魔法，各种黑科技
- 所做的事情名目繁多，令人抓头
- 脚本的参数一大串，只有少数人知道代表着什么，怎么传
- 脚本里都是写死的变量、地址、用户信息
- 通常都是一个有着 N 多功能的大文件
研发遇到这样的脚本，第一反应就是：“嗯，好的，我本地已经编译通过，代码提交到代码库了。剩下的事情就交给你们配置管理了。”然后一边叼着烟卷、喝着咖啡当大爷去了。只有配置管理苦逼兮兮的把代码获取下来，然后用构建脚本跑。
构建过程不要求有多么完备，所有的功能都塞到一个文件里去完成。看得人是会很累的。
构建脚本模块化
如何写好一个易理解的构建脚本呢？
- 首先写最基本的编译部分，这部分不依赖任何其它额外的东西，运行这部分就是为了纯粹的编译。之所以就是可以让研发人员在本地也可以自己运行来编译。如果他本地都编译不成功，提交到构建服务器上也是跑不过的。先让他们自我审查一下。
- 把构建分成几步，分别由不同的脚本完成
- 建立工作空间（或清理工作空间）
- 环境初始化
- 获取代码
- 编译、链接
- 打包
- 上传
- 清理
- md5，数字签名（可选）
- 脚本要有明确的参数以及含义说明
- 构建脚本的质量。构建脚本要有明确的版本发布概念、以及相应质量保证。我们经常看到研发人员的业务代码有很多的质量保证措施，包括代码审查，风格检查、代码安全扫描等等，唯独构建脚本没有。
都在说 Devops，很多时候都是 ops 多一些， Dev 少一点。
构建脚本配置化
构建脚本的大多数值应都是固定的，降低不可配置的部分。如果有不可配置的部分也要单独出来，这样一旦出错也容易排查。
之所以很多研发不愿意触碰构建脚本，就是构建脚本太复杂了，很多他们不需要的功能都糅杂到了一起，研发很难在很短的时间内找到一个理解的途径，一个快速运行的方法。从这一点上说 xml 和 yml 格式的构建脚本是最好的。
构建脚本语言
dirty but quick - shell
为什么大多数构建脚本都是解释型语言写的? 这是因为在项目建立之初，需要一种快速实现项目编译的方法，三两行的 shell 就可以完成，谁还会去写个 C 语言的？随着工程规模变大，要做的事情也越来越多，随之三两行的构建脚本，变成了一堆三两行的构建脚本。
- 脚本语言上手容易。写个简单的构建脚本，几分钟就可以弄出个原型来。C 语言呢？估计还在 include 各种库。
- 容易改变且改变后不需要编译。解释型语言在规模不是很大的时候容易调试。出现问题直接修改，修改完毕后立刻可以运行。不需要编译一遍。如果编译构建脚本？那是不是还必须为这些构建脚本弄台专有的服务器？
- 跨平台，容易部署。对于 Linux 服务器，基本上写了一个 shell 脚本，分发到服务器上就可以执行；Windows 上可以看看 Powershell 和 Python，不推荐写 bat 脚本。如果是 java 写的构建脚本，是不是每台构建服务器上还得需要装个 jre？有人说变编译型语言执行起来速度快啊。说实话，节约的那点时间，真的无法比拟脚本语言带来的各种好处。
构建系统
仅仅有一个简单的构建脚本是不够的，就像上面列出来的，还需要做很多编译之外的事情，比如环境设置、打包、上传、操作数据库等等。我们还需要一个构建系统。没有人来帮忙? 那只能配置管理团队自己撸了。如果真的现实情况如此，那么能快速实现的 Ruby, Python 则是不错的选择。
小结
写一个简单明了容易理解且功能丰富各种大而全的构建脚本是不可能完成的。但我们可以把各种功能分拆的相对清晰一点、通过各种模块来完成，这点还是可以做到的。
如果要真的需要推荐些工具和语言，那么我觉得 python 在各个平台各种语言环境下都是需要的。 Linux 还需要 shell; Windows 平台使用微软推荐的做法就可以，选择其它的反而揪心。
