我们的后端C应用都是支持跨平台的，至少目前在Linux和Solaris上运行是没有问题的，这样一来我们在配置持续集成环境时就要考虑如何实现在代码Commit后触发多平台并行(同时)集成这个需求。

之前使用Buildbot时是通过为一个Scheduler配置多个Builder满足这个需求的。但现在要换成Jenkins，我们如何来实现呢？昨天在折腾Jenkins时我把问题想简单了，今天细致查看了一下Build Log后才发现之前的配置并未真正实现多平台并行集成。

最初的Jenkins配置大致是这样的：我在Jenkins上添加了两个节点(Slave Node)，分别为x86-linux-ci-slave和x86-solaris-ci-slave，并且为这两个节点设置了一个相同的标签"foo-ci-slaves"。之后我创建了一个新Job – "foo-multiplatform-ci"，选择的是"构建一个自由风格的软件项目(Build a free-style software project)"。为了使得该Job执行并行集成，我选择了"Restrict where this project can be run"，在"Label Expression"中填上了"foo-ci-slaves"，其他配置这里就不赘述了。

按照我最初的理解，这样配置后点击"立即构建"，两个Slave Node上就会同时进行相关的集成。但Build Log告诉我事实并非我想象的那样：Jenkins只是在一个Slave Node上执行了Job。那使用Jenkins如何来实现前面所说的多平台并行集成呢？查来查去，我发现原来是我在创建Job时选错了配置，我应该选择"构建一个多配置项目(Build multiconfiguration project)"。

与free-style project相比，multiconfiguration project的配置页面中不见了"Restrict where this project can be run"配置选项，但却多出了一个"Configuration Matrix"配置区域。在该区域中，我们可以选择Slaves，在Node/Label中，我们可以看到当前Jenkins中配置的所有Label和Nodes。选择一个Label是无法满足我们的要求的，那样Jenkins只会从Label中的若干个节点中选择一个来执行集成。所以我选择Nodes，将x86-linux-ci-slave和x86-solaris-ci-slave都选上，保存后我们就会在"foo-multiplatform-ci" Job的主页面上看到两个configuration: x86-linux-ci-slave和x86-solaris-ci-slave。点击"立即构建"，这两个configuration对应的小球标志就会同时闪动，这说明"foo-multiplatform-ci"正在两个Slave Node上并行运行呢，这才是我想要的结果。

支持多平台并行集成只是Multiconfiguration Project的一个用途之一，《Jenkins: The Definitive Guide》一书对此有更为细致的讲解，你可以结合自定义Axis(坐标轴)以及parameterized Build实现更为复杂的构建需求。但目前我尚未遇到类似需求，所以这里也不敢乱说^_^。

虽然部门一直在做C应用，但这么多年来，在C应用的安装包制作以及部署方面做得还是很初级，可以说还没有达到规范的程度。各个产品线的C应用安装包种类多样，水平参差不齐：有些产品的源码包即是安装包，把源码包拿到生产环境下编译后使用；有的项目则将编译好的目标文件(.o)以及第三方库放在安装包中，在生产环境下重新链接生成可执行文件；有的组则稍微专业一些，安装包中放的是编译好的可执行文件，但在目标主机上安装和执行时也都遇到了一些问题，诸如运行环境中的第三方库版本号与程序所依赖的不一致等。

去年年底，我就将"C应用安装包制作和部署"的改进作为今年的一个工作重点。这两天我粗略地考量了一下这方面的内容，这里也简单地谈谈。

总的来说，摆在我们面前的有三个主要问题：
1、安装包的组织方式不规范，不统一；
2、安装包的制作方式不规范，不统一；
3、安装包的部署方法不规范，不统一；

好了，下面我们就来针对上述问题逐一说说改进思路（注意以下内容并非普适）。

一、安装包组织方式
在Linux平台上应用的标准安装包是rpm或deb，但这种安装包形式似乎不太适合我们这种C后台应用。我对rpm或deb安装包了解的不多，但印象中这类安装包的安装一般为完全安装，但我们的应用升级版本时多数为增量安装或局部替换，因此做成rpm或deb虽然看起来专业一些，但实际操作起来并不灵活，因此自定义的安装包组织方式似乎更符合我们的需求。

下面是一个安装包的组织结构样例：
INSTALL_PACKAGE/
      – install.sh
      – README
      – app/
           – foo-1.0.1*
      – env/
           – conf/
           – log/
           – bin/
           …
      – deps/
           – libs/
              – bar/
           – tools/
      – scripts/
           – deps_check.sh
           – …
      – others/

其中:
app目录下存放的是可执行文件;
env目录下存放的是可执行程序运行时所需要的目录结构，包括配置文件等;
deps目录下存放的是可执行程序运行时所依赖的第三方库以及一些工具;
scripts目录下存放的是安装包安装过程中所需要的辅助脚本;
others目录下可以存放无法在上述目录下存放的其他数据;
install.sh是总控安装脚本，可以用于在目标主机上安装app、完整安装运行时环境、安装依赖libs或工具，执行scripts下面的必要脚本。

这样的一种安装包格式比较灵活，我们可以根据需要通过install.sh安装可执行文件或某个配置文件或其他数据文件。将INSTALL_PACKAGE目录打包(.tag.gz or .zip)就得到了我们的安装包。

安装包命名是要符合一定规范的，也便于进行配置管理。一个典型的安装包命名规范：程序名-版本号-平台-操作系统-编译模式.tar.gz[.zip]，例如：
foo-1.8.3-x86-linux-64bit.tar.gz
bar-2.9.3-x86-solaris-32bit.tar.gz
zoo-1.3.2-sparc-solaris-64bit.zip

二、安装包的制作方式
以往的安装包都是直接基于项目源码库构建出来的，很多运行时目录、配置文件以及辅助脚本也都与源代码存放在一起，这样一来让源码库看起来很臃肿，二来一份源码控制无法对应部署到多个不同客户现场的安装包，也就是说不同客户生产环境下的配置、数据等都是不同的，但源码库只有一个，我只能保存一份配置，因此在生成不同安装包是似乎要临时修改，且无法将这些修改做版本管理。

我的一个想法就是将安装包涉及到的相关文件和目录从源码库中剥离出来，针对每个项目源码，我都会建立若干个安装包工程，安装包则是这些工程(project)的产物，且可以针对不同客户做有针对性的安装包修改和版本管理。记得Microsoft的Visual Studio就有单独的安装包制作工程模板，这里也算借鉴Visual Studio中安装包工程的思想了^_^。

下面是一个安装包工程的示例：
foo_INSTALL_Proj/
      – Makefile
      – distributions/
         – foo-2.9.3-x86-linux-64bit.tar.gz
      – src/
         – install.sh
         – README
         – app/
         – env/
           – conf/
           – log/
           – fifo/
           – bin/
           …
         – deps/
           – libs/
           – tools/
         – scripts/
           – deps_check.sh

         – others/
其中src下面的内容就是上面提到的安装包的组织，通过安装包工程我们就可以灵活控制安装包中的每一个元素，而对源码没有任何影响。

三、安装包的安装模式
有了前面两个问题解决作为铺垫，这个问题就很好办了。我们的应用大致有两种安装模式：本地安装和远程安装，实际上也是一回事。本地安装就是手工将安装包放在某个目标主机上，然后解压，并利用安装包中的install.sh来安装需要的文件；而远程安装多半是用远程控制工具将安装包上传到目标主机（可能是多台），并通过远程命令在远程主机上执行本地安装。

这里想到的一个改进就是在目标环境中部署应用前，首先执行一次部署约束检查，检查目标环境是否满足新应用部署和运行的约束条件。这在以前的部署步骤中是没有的，约束检测脚本可随安装包携带，比如放在scripts目录下。

总之，规范化的安装包组织形式、制作方式以及部署方式不仅是一种专业化的表现，它与一些自动化工具的结合还会促进团队或组织整体效率的提升
。