一个二进制

One Binary

我遇到过几个项目,其中的构建代码会重写一部分,以便为不同的目标环境生成对应的二进制文件。这总是会让事情变得比它原来更复杂,并带来一个风险——对于每个安装包,团队可能都没有个统一的版本号。至少,这些多个编译目标几乎都是该软件的副本,只不过被部署到了不同的地方。这就意味着很多不必要的部分也被移植过去,也意味着错误的可能性更高。

我曾在一个团队中工作过,每个特性变更时都不得不进行一次完整的构建周期检查,因此每次微调时测试员都得随时待命(我有提到过构建时间也很长吗?)。我还在另一个团队中工作过,那里的系统管理员坚持要求在生产环境重新构建(使用我们的脚本),这就意味着我们无法证明生产版本是经过测试的。等等吧。

规则很简单:只构建一个二进制文件,你能够在发布管道内进行所有阶段的识别和升级。保持环境的具体细节在环境中。比如,把它们放进一个组件容器、或已知的文件、或路径。

如果你的团队将代码分离编译或是将所有目标平台设置存到代码里,那就说明这是一个没有经过慎重考虑的设计,不足以将应用程序的核心部分与平台细节分离开。另一种可能:团队知道怎么做,但不能先试着去改变。

当然,也有例外:你可能在为有着显著资源限制区别的目标平台做构建,但这并不适用于我们大多数编写“数据库筛查和返回”应用程序的人。又或者,你可能正遇到一些难以立刻修复的遗留问题。这种情况下,不得不逐步前行——但最好尽快开始。

还有一件事:也要确保环境信息的版本化。没什么比破坏环境配置和搞不清哪里被修改更糟糕的了。环境信息应当独立与代码进行版本化,因为它们会以不同的频率和原因发生变化。一些团队会采用分布式版本控制系统来进行管理(比如bazaar和git),因为它们很容易在生产环境中作出变更——必然的——也能回退到仓库。

0%