关于构建自动化

软件产品开发过程中，代码编写完成后，编译出版本调试，是必须也是至关重要的一个步骤。但是这一步往往不好做耗时且容易出错，因为代码太多、划分的模块、进程也较多且涉及的面很广，比如一个软件有后台存储过程是sql，主机服务端是c，客户端是java、python等，同时不同的编译还依赖不同操作系统以及底层平台的一些库和第三方文件，这种情况下，该类产品的构建往往是一个大问题，单纯依赖手工敲命令行逐个编译不仅容易出错，而且耗时特别久，同时即使编译出来也不能保证编译出来的版本就是正确的。因此如何快捷准确的构建版本，对于较大代码量，涉及面较多的软件项目来说是个至关重要的问题。

在这个问题上，业界主流的做法都是搭建一套构建自动化系统，依赖配置文件、流程脚本、以及众多的编译机器排除人为因素来达成这一目标，同时通过流程、任务调度、机器增加等方法提高构建的速度。google一个较大型项目（百万级代码量）从开始代码更新（SVN、CC等版本控制管理工具）到门槛用例（基本）验证完成，整个过程自动化进行且只需要10分钟左右。这意味着比如要验证一个android操作系统源码问题，google的开发人员从改完代码到可以进行验证只需要10分钟不到。因为10分钟是版本构建+门槛验证时间，因此版本构建出来绝对在10分钟之内。这是个什么概念，这样说吧我电脑（虽然比较老），但是在啥都不干，只编译android操作系统源码情况下，编译完成最快也需要2个小时。敏捷开发的今天，一个版本的开发周期通常不会很长，但是开发任务量绝不会少。因此开发人员不仅要提高开发速度，而且要保证开发质量，快速验证是必须的。同时在版本层面，在项目经理看来快速的版本构建能够保证一天之内版本可以构建多次，能够很快速的发现并消除新引入问题，保证这个产品任何一天的版本都是可用的。

回到构建自动化的具体实施上，编译肯定需要编译机器，因此物理的编译服务器必不可少，这种编译服务器可以是个人PC，但是专业和业界主流都是使用机架式服务器，然后通过vmware虚拟化软件，将一台机架式服务器根据其资源虚拟出若干编译PC(windows,linux(suse,redhat...)等系统，根据产品编译情况进行虚拟）以及测试PC，然后在这些PC上部署编译用的一些第三方软件（jdk,ant,.net,gcc,make）等等。然后最关键的就是部署构建自动化的实现插件，这个插件各个公司的实现不尽相同，不过最终结果都是一样的，这个插件是个分布式系统。

准备好物理服务器以及部署好软件后，构建自动化的通用平台就有了，下来就是各个产品根据自己现状，进行构建流程脚本的编写。然后通过脚本在编译服务器上的运行，实现版本的自动化构建。通常情况下自动化构建脚本逻辑控制都是ant脚本（使用xml编写），然后通过加载配置，调用具体干活的shell和bat。

前不久在处理一个比较难定位的问题，然后在不停的加打印，不停的编译调试，然后就觉得很麻烦（老需要手工在个人机器与个人编译服务器之间拷贝文件，然后用编译工程编译进程，编好后，传回本地再上传到测试环境中去），无法专心聚焦于代码分析。因此就想可不可以做个自动化编译脚本，然后集成于source insight，通过快捷键指派，来一键式进行代码编译并替换环境中待调试版本的对应进程。借鉴于上面版本构建自动化的经验，3个小时就实现了这个一键式编译的东东。

实现细则：编写一个bat，用于一些工具的环境变量设置，主要是ant；一个配置文件来描述环境信息，然后具体的ant脚本完成编译于环境进程替换。这个东西调试OK后，通过source insight提供的Runcmdline方法，定义一个宏使用Runcmdline来调用刚才写的bat，完成在source insight中通过快捷键实现代码的快捷调试。因为代码是要linux中编译的，所以这个东东要使用jsch，来实现windows和linux之间的文件传输。