持续交付

目录

• 3.1 引言
• 3.2 实现持续集成
  • 3.2.1 准备工作
  • 3.2.2 一个基本的持续集成系统
• 3.3 持续集成的前提条件
  • 频繁提交
• 5.2 什么是部署流程线

3.1 引言

很多软件项目都有一个非常奇怪而又常见的特征，即在开发过程里，应用程序在相当长的一段时间内无法运行。事实上，由于大规模团队开发的软件中，绝大部分在开发过程中基本上处于不可用状态。其原因很简单，没有人有兴趣再开发完成之前运行整个应用。虽然开发人员提交代码后可能会运行自动化的单元测试，但没人会在试运行环境中去启动并使用它。

3.2 实现持续集成

"持续集成" 这一实践并非信手拈来，它需要有一定的先决条件。也许最重要的一点是，"持续集成"依赖于那些能够遵守一些重要实践的团队

3.2.1 准备工作

在开始持续集成之前，你需要做三件事

1.版本控制

与项目相关的所有内容都必须提交到一个版本控制库中，包括产品代码、测试代码、数据库脚本、构建于部署脚本，以及所有用于创建、安装、运行和测试应用程序的东西。

2.自动化构建

你要能在命令行中启动构建过程。无论是通过命令行程序启动IDE来构建应用程序，然后再运行测试，还是使用多个复杂的构建脚本通过互相调用的方式来完成都行，但无论采用哪种机制，必须满足如下条件：人和计算机都能通过命令行自动执行应用的构建、测试以及部署过程。

现在，集成开发环境和持续集成工具的功能都非常强大。通常不需要切换到命令行，你就可以用集成开发环境完成应用程序的构建，并执行测试。然而，我们仍认为，你仍然需要有能力通过命令行执行，而不需要使用集成开发环境的构建脚本。对于这一点，可能存在一些争议，但我们的理由如下。

• 要能在持续集成环境中以自动化的方式来执行整个构建过程，以便出现问题的时候能够审计

• 应将构建脚本与代码库同等对待。应该对它进行测试、并不断地重构，以使它保持整洁且容易理解，而集成开发环境自动生成的构建过程基本上无法做到这一点。项目越复杂，这项工作就越重要。

• 使理解、维护和调试构建过程容易，并有利于和运维人员更好地协作

3.团队共识
持续集成不是一种工具，而是一种实践，它需要开发团队能够给予一定的投入并遵守一些准则，需要每个人都能以小步增量的方式频繁地将修改后的代码提交到主干上，并一致认同"修复破坏应用程序的任意修改时最高优先级的任务"。如果大家不能接收这样的准则，则根本无法如预期般通过持续集成提高质量

3.2.2 一个基本的持续集成系统

如果能够满足前面所述的先决条件，那么当你选择并安装好持续集成工具之后，如果再花几分钟的时间配置一下就可以工作了。这些配置包括让它知道到哪里寻找源代码库，必要时运行哪个脚本继续进行编译，并执行自动化提交测试，以及一旦最新的提交破坏应用程序，通过哪种方式通知你

第一次在持续集成工具上执行构建时，你很可能会发现运行持续集成工具的机器上缺少一些必要的软件和设置。这是一个独一无二的学习机会，请将接下来你所作的工作全部记录下来，并放在自己项目的知识库中。你应该花些时间将应用程序所依赖的所有软件和配置提交到版本控制系统中，并将重建全新环境的整个活动变成一个自动化的过程。

接下来要让所有人开始使用这个持续集成服务器。下面是一个就按单的过程。
一旦准备好要提交最新修改代码时，请遵循如下步骤。

(1) 查看一下是否有构建正在运行。如果有的话，你要等它运行完。如果它失败了，你要与团队中的其他人一起将其修复，然后再提交自己的代码
(2) 一旦构建完成且测试全部通过，就从版本控制库中将该版本的代码更新到自己的开发环境上。
(3) 在自己的开发机上执行构建脚本，运行测试，以确保在你机器上的所有代码都工作正常。当然你也可以利用持续集成工具中的个人构建功能来完成这一步骤
(4) 如果本地构建成功，就将你的代码提交到版本控制中
(5) 然后等待包含你的这次提交的构建结果
(6) 如果这次构建失败了，就停下手中做的事，在自己的开发机上立即修复这个问题，然后再转到步骤(3)
(7) 如果这次构建成功了，你可以小小地庆祝一下，并开始下一项任务。

如果团队的每个人在每次提交代码时都能够遵守这些简单的步骤，你就可以很有把握地说："只要在与持续集成一摸一样的环境上，我的软件就可以工作"

3.3 持续集成的前提条件

持续集成不会独立地帮你修复构建过程。事实上，如果你在项目中中期才做这件事的话，可能会非常痛苦。为了使持续集成能够有效，开始之前，你应该先做好下面这些事情

频繁提交

对于持续集成来说，我们最重要的工作就是频繁提交代码到版本控制库。每天至少应该提交几次代码

定期地将代码提交到代码主干上会给我们带来很多其他好处。比如，它使每次修改都比较小，所以很少会构建失败。当你做了错事或者走做了路线时，可以轻松地回滚到某个已知的正确版本上。它使你的重构更有规则，使每次重构都是小步修改，从而保证可预期的行为。它有助于保证那些涉及多个文件的修改尽量不会影响其他人的工作。它让开发人员更敢于创新，勇于尝试新的想法，而且一旦行不通，可以轻松地回滚到最近提交的一个版本上。它还会让你不时地停下来，伸展一下身体，有助于防止腕关节疼痛或肢体重复性劳损(RSI)。如果发生了问题(比如误删了文件等)。你也不会丢掉太多的工作成果

前面我们特意的提到过"要提交到主干"。很多项目使用版本控制中的分支技术来进行大型团队的管理。然而，使用分支时，其实不可能真正地做到持续集成。因为如果你在分支上工作，那么你的代码就没有和其他开发人员的代码进行即时集成。 那些使用长生命周期分支的团队恰恰面临着我们在本章开始时描述的集成问题，除一些很有限的情况外，我们不推荐使用分支。我们会在第14章更详细地讨论这个问题。

5.2 什么是部署流程线