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

其他持续交付相关文章：《持续交付》系列文章目录

第六章 构建与部署的脚本化

1. 引言

要实现

自动构建

自动部署

构建和部署系统一直要保持活力，这个系统不仅要从项目开始就开发，而且一直持续到产品到上线维护阶段，细心设计和维护它，像对待项目源代码一样，并定期使用，确保我们每次想用时，都能正确运行

2. 构建工具概览

由于我使用Java，用Maven构建，所以其他相关工具略过

2.1. Make

略

2.2. Ant

略

2.3. NAnt与MSBuild

略

2.4. Maven

惯例由于配置

三个问题

项目结构死板

扩展它要写代码（mojo插件）

默认情况下，自动更新，可能会导致某次构建无法重现

依赖和配置惯例参见第十三章

2.5. Rake

略

2.6. Builder

略

2.7. Psake

略

3. 部署构建脚本化的原则与实践

3.1.为部署流水线的每个阶段创建脚本

刚开始可能只需要一个脚本，但是项目大了之后就要拆分，易于管理和维护

记住，部署脚本一定要放在版本控制库中

3.2. 使用恰当的技术部署应用程序

部署脚本应该能完成应用程序的安装和升级任务，在部署之前，他要能关闭当前运行的版本，而且既支持在当前数据库上升级，又能从头创建数据库

3.3. 使用同样的脚本向所有环境部署

将部署脚本和需要用到的配置信息分离开来，详情可参见第二章

3.4. 使用操作系统自带的包管理工具

让自己的应用程序包的安装也想apache的安装一样

3.5. 确保部署流程是幂等的

确保每次部署都以已知状态良好的环境作为起点

很难实现，作为目标前进吧

3.6. 部署系统的增量式演进

逐步完善，每自动化一个过程，就是一个进步

4. 面向JVM的应用程序的项目结构

推荐使用Maven，Maven最大的贡献就是标准化了项目结构

任何生成的配置或元数据都应放在target下

单元测试与源代码对应

版本控制库应该忽略target目录

确保应用程序所有依赖都与应用程序的二进制包一起打包

5. 部署脚本化

核心原则：对测试和生产环境的修改只能由自动化过程执行

5.1. 多层的部署和测试

第一层（最底层)，硬件

第二层，操作系统，操作系统配置

第三层，中间件，中间件配置

第四层，应用/服务/组件，应用配置

保证下一层是准确的，可控的，稳定的配置，再开始上一层的部署

5.2. 测试环境配置

简单的冒烟测试，证明我们的配置可以工作，可以从如下几方面入手

确认能从数据库拿到一条记录

确认能连上网站

断言消息代理中的已注册的消息集合是正确的

透过防火墙发送几次“ping”命令，证明线路是通的，且各服务器之间提供了一个循环分配负荷

关于基础设施管理，第十一章有更详细的描述

6. 小贴士

6.1. 总是使用相对路径

如果不可避免要使用绝对路径，尽可能将这部分内容独立出来，不要让它影响构建系统的其他部分

6.2. 消除手工步骤

枯燥，极易出错，文档容易过时

当做第二次时要警觉，当你需要重复做第三次时，就把它自动化

6.3. 从二进制包到版本控制库的内建可追溯性

保证知道哪个二进制包是哪个版本库的哪个版本生成的

6.4. 不要把二进制包作为构建的一部分放到版本控制库中

6.5. “test”不应该让构建失败

不要一碰到错误就失败，最好都执行一遍流程，报告出所有错误，再失败

6.6. 用集成冒烟测试来限制应用程序

部署前简要测试一下机器是否正确，环境是否正确等

6.7. .NET小贴士

略

7. 小结

以迭代的方式来识别最令你痛苦的步骤，并将其自动化，沿着部署流水线，逐步完善自动化构建和部署能力。请时刻牢记最终目标，即在开发、测试和生产环境中共享同一种部署机制，但不要过早地纠结于工具的创建