《持续交付》(第六章)——构建与部署的脚本化

本章主要讲了使用所有构建和部署工具的原则，给出了在实际工作中所需的基础知识，而且还给出了一系列的提示和技巧，指出更多的信息。

构建与部署脚本化的定义

创建脚本执行应用程序构建、测试和打包的步骤：

• 在命令行中进行构建
• 利用某个比较流行的测试框架，在很多平台上运行测试也想对简单
  自动化部署，需要一系列的步骤，比如配置应用程序、初始化数据、配置基础设施、操作系统和中间件，以及安装所需的模拟外部系统等。
  构建和部署系统必须一直保持活力，即这个系统不仅要从项目刚开始就开发，而且一直要持续到软件开发环境中的维护阶段。

构建工具

所有构建工具都有一个共同的核心功能，即可以对依赖关系建模。
构建工具对：1）它做什么；2）它依赖于什么这两点进行建模。

构建工具的不同点在于它是任务导向，还是产品导向的：

• 共同点：
  构建工具会遍历整个网络，调用（但不一定执行）每个任务
• 不同点：
  • 在任务导向的工具中，每个任务都会知道它自己在构建过程中是否被运行过。
  • 在产品导向的工具中，它们是用一系列的文件建模的。

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

1.为部署流水线的每个阶段创建脚本
确保将所有的脚本都放到版本控制库中，并且最好和源代码放在同一个版本控制库中。
2.使用恰当的技术部署应用程序
在项目一开始，开发人员、测试人员和运维人员必须合作规划部署流程。
部署脚本应该能完成应用程序的安装和升级任务。
3.使用同样的脚步向所有环境部署
将配置信息从脚本中分离出来，并将其保存在版本控制库中，这里有两个关键点：
1）构建和部署脚本在开发机器和类生产环境上都能运行
2）开发人员使用这些脚本进行所有的构建和部署活动
4.使用操作系统自带的包管理工具
5.确保部署流程是幂等的
无论开始部署时目标环境处于何种状态，部署流程应该总是令目标环境达到同样的状态，并以之为结束点。
6.部署系统的增量式演进

部署脚本化

环境管理的核心原则之一就是：对测试和生产环境的修改只能由自动化过程执行。也就是说，我们不应该手工登录到这些环境上执行部署工作，而应该将其完全脚本化。比如：写个脚本，让它登录到每台机器上，运行适当的命令集；写个本地运行的脚本，在每台远程机器上安装一个代理，由代理在其宿主机上本地运行该脚本；利用操作系统本身的包管理技术打包应用程序。

我的收获&疑问

收获

• 消除手工步骤，尽可能使用工具达到自动化
• 部署脚本可以分阶段执行
• 部署脚本和环境配置信息应该分开管理
• 使用想对路径

疑问

• webpack算是构建工具吗？
• 怎样区分构建按工具的产品导向和任务导向？