持续交付

持续交付依赖于一系列的工具和实践，下图是一个持续交付的工作流：

还有一系列与开发无关的技能：

1. 自动化
2. DevOps
3. 云基础设施
4. 以软件为中心的哲学

基础设施

在我们使我们的项目可以持续交付软件包的时候，我们需要

本地开发环境

在本地编写代码时，我们需要设置本地的开发环境。假设我们要开始一个 Java Web 项目，在我们的开发机器上，我们需要安装：

• 版本管理工具，如 git，用于管理源代码。
• IDE，如Intellij IDEA，用于搭建开发环境。
• 构建工具，如 gradle，用于安装依赖、运行测试、构建工程等等。
• 语法检测工具，如 checkstyle，用于检查代码语法。
• 单元测试框架，如 JUnit，用于进行单元测试。
• 集成测试框架，如 Cucumber、Selenium，用于做行为测试。

除此，在我们的项目代码里，我们还需要：

• CI运行脚本，用于在 CI 上运行指定的测试。
• 上传包脚本，用于上传 build 完的软件包。
• 部署脚本，用于在本地部署包到测试环境。
• 监控代码，用于监测网站性能和用户行为。

当然我们还需要辅助一些测试工具来测试网站，如性能测试、网络测试等等。

持续集成环境

为什么在这里会出现一个持续集成环境？我也不知道，只是想到了这里。由于我们需要持续集成，所以我们也需要一个运行持续集成服务器的机器。

持续集成服务器是由两部分组成的：Master 和 Agent。即一个用于控制其他运行持续集成服务的机器，以及执行指令的机器。因此，我们需要在一台机器上安装 Master 软件，在另外一台机器上作为 Agent。在我们的 Agent上，我们需要安装相对应的运行服务的软件，如

• 指定版本的语言环境 ，如Java、Python。
• 构建工具。
• 版本管理工具，及对应的密钥。
• 打包工具，如 RPM。
• 虚拟桌面，即可以模拟桌面浏览器的软件。

同时，我们还需要有一个地方放置我们的RPM包。

测试环境

相比于上面两个环境来说，测试环境就比较简单了。我们只需要创建几个不同的环境，即开发者的测试环境、QA 环境、模拟线上环境，在这几个不同的环境上有不同的配置。

持续部署

在持续交付之外的，还有持续部署——这个就更依赖于团队的组织结构了。其与持续交付的对比如下图所示：

我们可以从图中看到，两者的最大不同之处在于：持续部署会直接将构建生成的部署到产品环境。这就意味着，我们不仅要有强大的技术实力，也要有足够的组织支持才能做到。而这部分已经超出了软件开发的内容了~~。