持续交付之构建与部署的脚本化

一、构建工具

         比较常见的有： 

• make   编写makefile编译即可。缺点很明显：每个目录下创建一个Makefile，目录和依赖关系复杂后，太复杂了。另外就是依赖于Shell。

• Ant       Apache的工具。跨平台，容易使用Java来扩展。使用XML来作为构建的结构化文档。缺点：XML写脚本；使用不方便，写个样板很麻烦；不方便重用。 

• NAnt/MSBuild    .Net 和微软的Ant。

• Maven： 1、只要项目按照Maven的方式组织，就能很方便地几乎用一条命令执行编译、部署、测试、发布任务。使用惯例配置取代了Ant的模板；2、自动管理Java库和项目间的依赖。缺点是：1、必须按照惯例来，有不同的话很难处理；2、也需要使用XML写得外部DSL；3、默认配置中，是自更新的。（可能在你不知道的情况下，更新了Maven或插件；或者更新了Java库）  

• Ivy：和Ant结合，可以取代Maven

• Rake ： Ruby主流构建工具

• Buildr：   建立在Rake之上。

• Gradle： 现在AS里面用的就是，我不太搞得懂，都是直接使用默认的。

二、脚本化的一些原则

      1、使用恰当的技术部署应用程序（最好开发、测试、运维团队使用相同的构建工具）

      2、使用同样的脚本向所有环境部署（不同可以通过配置文件来体现）

      3、为部署流水线的每个阶段创建脚本（并把脚本纳入配置管理，同样可能涉及配置数据、依赖库、组件库等）

      4、使用操作系统自带的包管理工具（打包的RPM、Installer等）

      5、确保部署流程完成结束点状态是一致的（不论部署环境处于何种状态）

      6、脚本化一般应增量式演进（比如，第一步是自动编译、打包；后面增加安装、配置；在增加冒烟测试；最后增加远程发布）

三、脚本化的一些最佳实践

     1、总是使用相对路径

     2、消除掉手工步骤（当然推荐是渐进式的）

     3、从二进制包到版本控制库的内建追溯性

     4、不要把二进制包作为构建的一部分纳入版本控制库（前面说过很多次了）

     5、冒烟测试的每个用例应尽量执行完，失败的提供错误码（避免冒烟测试中多个错误时，要一个一个地串行发现）

     6、用集成冒烟测试来限制应用程序（对于周期性运行的内容，一定要在安装部署时测试到，提前发现问题）

     

      总之，对持续交付，构建脚本是最最重要的工作成果。