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

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

个人站点 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. 小结

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

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值