持续交付（第六章）—构建与部署的脚本化

在上一章中跟随作者一起了解了部署流水线的整个流程，着重奖励从开发，发布，部署这一流程，一键式部署或者说“自动化”还是重点。在本章中，作者向我们介绍了关于构建部署中脚本的一些规则和要点和一些部署工具。

持续集成

构建工具介绍

对于一些简单任务我们使用IDE进行部署没有问题，但是对于一些相对来说比较复杂的项目，如果不想让它变得更复杂和难处理，就需要施加更多的控制，比如使用脚本来执行应用程序的构建，测试和打包工作，选择一些适合自己项目的构建工具。
构建工具可以分为两类，一个是任务导向，另一个是产品导向。这样对工具的分类可以对优化构建流程起很大帮助。下面列出一些常见的构建工具。

• Make
  它是一种强大的产品导向的构建工具，能在单次构建中追踪依赖关系，还能只狗剪那些受到本簇修改影响的组件。
• Ant
  是Make与XML的融合，适用于Apache的构建工具，完全跨平台，是一个任务导向的构建工具。
• NAnt与MSBuild
  在.net中将Ant移植过来，所以就有了NAnt，Microsoft后台在NAnt中哦你引入少量的变化，并形成了一个变体——MSBuild。
• Maven
  Maven能自动化管理javaa库和项目间的依赖，支持一种复杂且严格的软件分区方案，是你能将复杂的解决方案分解成较小的组件。
• Rake
• Builder

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

1.为部署流水线的每个阶段创建脚本
2.使用恰当的技术部署应用程序
3.使用同样的脚本向所有环境部署
4.使用操作系统自带的包管理工具
5.确保部署流程是幂等的
6.部署系统的增量式演进

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

Maven最重要的一个贡献就是引入了项目代码结构的标准惯例，如果你想使用它的服务，那你必须遵守它的书写规范。
Maven分别可以从源代码管理，测试管理，构建输出管理，库文件管理等方面对软件代码进行分区。
这样现象其实也在其他的一些框架中有所体现，比如使用express，vue自带的环境就会发现它会帮你创建好运行和文件分区环境，和Maven的文件结构挺相似。

部署脚本化

环境管理的核心原则之一就是：对测试和生产环境第修改只能由自动化过程执行。也就是说我们不应该手工远程登录到这些环境中进行部署工作，而应该将其完全脚本化，我们可以通过远程做部署，可以邪教本登录到每台机器上，运行适当的命令集，也可以写个本地运行的脚本，在每台机器上安转代理，或者使用操作系统自导的包管理系统。

总结

我的收获

• 默认所有位置都使用相对路径
• 消除手工步骤，尽可能的使用工具达到自动化
• 部署可以通过脚本实现自动构建发布，也可以将冗长的脚本分阶段执行。

我的疑惑

• webpack算是构建工具么，
• 构架工具的任务导向和产品导向是怎么区分的，两者的执行顺序是一样的么？
• 脚本也是通过命令来启动的吧，脚本文件里面是一些命令集么
• 操作系统自带的包管理系统，就像我们使用的npm么

疑惑的部分解答：

• 所以打包的意思就是打一个计算机可以认识和运行的二进制文件。（个人觉得不太全面），webpack的打包是对文件的梳理和模块化，不改变文件的性质

• 构建的作用是更简单的打包，打包是为了发布。

• 部署的意思就是让一段程序得到它所要的资源，并好好的运行起来。