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

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

个人站点 http://ronnie.wang

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

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. 小结

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