手工Build的烦恼
要不是为了和女朋友留在一个城市,小李肯定去北上广奋斗去了。
现在他只能留在这个2.5线城市,进入这家软件开发公司,7,8个人,10来条枪,是个典型的软件小作坊。
上班第一天,CTO兼架构师兼项目经理兼开发组长老张把小李叫去,谆谆教导说:
“小李啊,我看了你的简历,我对你在公司的发展还是挺看好的,不过作为新人,你对新业务还不熟悉,没法开发核心系统,这段时间,你要一边学习,一边帮着项目做个很重要的工作:Build“
小李心说你还给我拽英语啊, 虽然心里这么想, 小李还是不动声色,面带微笑的问:
“这Build是什么东西?”
老张说:“我非常忙, 没时间给你解释,这儿有个文档,你看看就知道了”
说着,老张甩给了他几张纸 ,补充到: “有问题问小王, 他比你早来一个月,做Build已经很熟了”
小李仔细看了一遍,上面写着:
XXX公司Build 流程 (测试环境)
(1) 设置Eclipse 工作区, 编码为UTF-8, java 编译级别为JDK 1.7
(2) 从SVN下载最新源代码到Eclipse工作区
(3) 确保Eclispe工作区没有编译错误
(4) 手工修改下面20个配置文件
database.properties
cache.properties
user.properties
。。。。。。
(5) 把Eclipse中的Web项目导出成War 包
小王还特别在这里用红色的笔加了标注: Web项目所依赖的其他java项目也会被自动包含到War包的 WEB-INF/lib目录下
(6) 上传到测试服务器,安装
(7) 做冒烟测试
小李笑了:这不就是一个编译,打包,部署,测试的流程吗? 还Build !
正在这时,开发骨干小梁叫小李了:“小李, 我改了几个Bug,马上要测试,赶紧给我做一个测试环境的Build”
小李不敢怠慢,立刻按照文档做了一遍,花了将近半个小时才折腾完。
可是到了最后一步,做冒烟测试的时候, 系统却启动不了了 !
小李查了好久才发现,原来测试环境的JDK是1.6 , 但是Build文档上写的是1.7 当然跑不起来了。
小李暗暗的骂前任小王: 你小子肯定知道这里有个坑, 怎么不在文档上标注出来?
赶紧做个新的Build 放到测试环境, 这次冒烟测试顺利通过了。
刚松了口气, 测试小赵就叫了起来: “小梁, 你那个Bug 没有修复啊”
开发骨干小梁本能的反应到: “这不可能! 我的代码本地都测试过了, 代码也提交了“
小梁接着把矛头就指向小李: “哎对了小李,你的Build是不是又搞错了。”
小李心头一惊 , 赶紧去查,果然,在第4步,手工修改配置文件的时候把数据库改错了 ,指向了开发库,而不是测试库。
赶紧改吧, 原来做Build的小王也跑过来凑热闹, 在前Build专员小王,开发小梁和测试小赵三双眼睛的严厉注目下, 小李头上都要冒汗了。
还好,第三次终于成功了。 所有的测试都顺利通过。
(实际上,小李在紧张的忙碌中也忘了去更新那个文档,把JDK 改成1.6)
就这样过了一周, 小李每天都得战战兢兢的做四五个Build, 虽然做的越来越熟,出错越来越少, 但是每天还是占用了不少时间。
大好年华就要在Build中蹉跎了吗, 坚决不行。
自动化Build
小李决定把这个手工的、费事的、容易出错的Build给自动化起来, 将来谁要是做测试环境的Build,只要运行一个命令即可。
用什么语言来实现呢? 当然是Java大法好 ! 小李在大学修炼了那么久,自认为对OO,设计模式已经炉火纯青了, 现在终于有了用武之地。
小李白天工作, 晚上回到住处就开发这个自动化的Build, 每天干到12点才罢休。
但是小李不觉得累, 每天都恋恋不舍的去上床睡觉, 因为创造一个新工具,造福大家的想法一直激励着自己,有时候甚至觉得很快乐。
一个月后, 自动化工具新鲜出炉, 这其实是一套Java 的API, 小李把它称为BuildTool V1.0 专门用于下载源码,编译,打包,部署,测试。
例如,如果你想编译java 代码, 可以这么写:
小李对于FileSet这个抽象很得意, 它能代表一个文件集合, 既可以是java 源文件路径, 也可以是 classpath 的路径。
其他的API像下载源码, 打包,部署,测试也是类似。
现在小李真的只需要运行一个命令,就可以为测试环境生成一个build :
java BuildTool test
工作量一下子少了好多, 并且机器运行,基本上不会出错。
小李因为这个自动化的BuildTool, 获得的公司的嘉奖,还涨了一点工资。
对小李来说,这都不是最重要的, 最重要的通过设计和实现这个BuildTool, 自己的能力有了很大的提升。
自己已经不仅仅是一个只会用SSH框架的一个HTML填空人员了!
码农翻身评: 大部分人只会抱怨项目很无趣,没有挑战, 遇到问题也只会安于现状,
少数人会发现工作中的“痛点”问题,并且真正动手解决它, 给公司带来了价值, 这是提高自己, 让自己和别人区分开来的重要方法。
JAVA vs XML
今年的形势很好,公司业务发展的不错,招了一批新人,一下子接了3,4 个新项目, 小李主动请缨,替这些项目建立一个自动化的Build 。
但是小李很快就发现了问题, 直接用Java语言来编写,功能虽然能实现, 但是看起来就太繁琐了。
自己写的代码过几天看也得思考一下才能明白。
是自己的BuildTool API设计的不好吗? 那可是精心设计的啊。
仔细思考了两天,小李终于意识到了问题所在: 不是自己设计的不好, 是Java 语言太“低级”了 !
自动化Build要描述的其实是任务,是业务层面的东西。
而用java 是个什么都能干的通用语言, 用它来写肯定引入了太多的细节,导致了阅读和编写的难度!
小李想:能不能开发一套新的,专门为自动化Build 所使用的语言呢?
(码农翻身注: 这其实就是所谓的领域特定语言(Domain Specific Language , 简称 DSL ))
但是开发一套新语言那成本可就有点高了, 有点得不偿失。
小李百思不得其解, 直到有一天听到小梁和项目经理在讨论hibernate 的配置文件,突然想到 像spring , hibernate 都是用XML来描述系统的。
“那我的BuildTool也完全可以用XML来描述啊” 小李赶紧把那个编译java 的程序用XML描述了一下:
果然是清爽多了! 和原来的Java程序比起来, 这段XML几乎就是自解释的 !
XML可扩展性极强, 可以任意自定义标签诸如<javac> <srcDir> <classpath> 用它来描述Build的逻辑。
但是唯一不爽的地方就是: XML 无法像 Java程序那样运行, 只是纯文本而已。
不过这也无妨,只要用Java写一个解析器,用来解析这些XML文件然后在Java中执行就可以了。有了BuildTool V1.0作为基础, 写一个解析器不是什么难事, 很快 BuildTool V2.0 就新鲜出炉了。
小李不再帮其他项目组去写Build 程序,因为用XML描述以后,大家很快就能学会, 并且乐在其中。
CTO老张看到这个工具,大为赞赏, 它给小李说: “别叫什么Build Tool, 太俗, 别人听了一点感觉都没有, 我给你起个名,叫 ANT ”
"ANT? " 小李似乎看到很多小蚂蚁在不辞劳苦帮着做Build, 心里暗暗佩服老张: 这个名字起的太好了, 姜还是老的辣啊。
声明:原创文章,未经授权,禁止转载
你看到的只是冰山一角, 更多精彩文章,尽在“码农翻身” 微信公众号, 回复消息"m"或"目录" 查看更多文章
有心得想和大家分享? 欢迎投稿 ! 我的联系方式:微信:liuxinlehan QQ: 14703250
公众号 : 码农翻身
“码农翻身”公众号由工作15年的前IBM架构师创建,分享编程和职场的经验教训。