对于不断演进中的产品，持续交付（CD）使其开发到产品交付的过程更加简单。持续集成（CI）位 于持续交付过程的开始阶段，它扮演了这个过程中的重要角色，由它定义软件开发过程。
在书 上和网上可以查到很多持续集成工具的资料，但处于持续集成过程中核心的构建作业却没有太多资料。
典型的持续集成过程如下：开发人员在他们自己的机器上手工构建和测试源代码。然后他们会 把修改提交到一个源码控制管理系统。随后构建工具将运行作业编译和测试这些代码。然后把构建的工 件上传到一个中心资源库，用于接下来的开发和测试。
因此，作业在持续集成工具中的角色是 管理源代码不断的修改、运行测试并通过发布通道管理工件传输的物流。
构建工作的作业任务 少则数个，多则上千，所有作业都执行不同的功能。幸运的是，我们可以用一种更加有效的方式去管理 这些作业。
自动化创建构建作业
那么为什么我们要装置一套自动化创建其他作业的设施 ？
构建工具在用户手册中描述了如何创建构建作业，但却很 少具体解释如何管理这些作业，尽管这些工具完全可以做到这些事情。
通常开发人员要了解他 们的应用是如何构建的，然后为创建和配置构建作业取得独占性控制权限。然而，这个过程存在一些缺 陷：
软件架构约束：由于架构层面的因素，应用很可能有各种不同的构建方式。开发人员可能需要说明 他与另一个开发人员在构建应用时的不同，所以一个作业和另一个作业的构建配置总有些细微的差异。 因此，如果所有的配置都不同，那么大量的作业就会变得极难维护。
人为因素：手工创建作业引入了出错的风险，尤其是采用先复制再修改的方式去创建一个新作业（ 即先复制一个已有的作业，然后再修改这个副本，从而得到一个新作业）。
作业时间轴控制：通常情况下，不会保存每次构建的作业配置，也就是说，如果一个作业的配置被 修改了，那么就有可能破坏之前的构建。
所以综合考虑以上几点，如果创建作业时没有一个一致的方法，开发人员就要用自己的设备执行构 建了，那么迎接我们的最终结果将是极难维护的持续集成构建系统和令人头痛的管理。这违背了建立持 续集成系统的原则：精益和易维护性。
实际上大多数构建工具都具有这样的设施，可以通过API 脚本自动化创建、维护和备份构建作业。然而，尽管构建工具在用户手册里提到过这些功能，但却经常 被忽视而未被采用。
自动化创建构建作业的优点
为简化持续集成构建过程，可以使用一 个主构建作业去自动化创建多个作业，这种做法有以下几个优点。
通过作业模版或脚本创建所有构建作业的配置。它们也可以放在配置控制之下。使用模版或运行脚 本可以非常简单地创建一个新作业。这可以显著地缩减作业创建时间（从若干分钟缩短到几秒种）。今 后，也可以更加简单地修改作业配置；修改构建作业模版的配置就可以保证所有在之后新创建的作业都 会继承这些修改。
所有已有构建作业的配置都保持一致，相比杂乱不一致的系统，这就可以更加简单地通过工具或脚 本全局更新所有的配置了。
开发人员在构建作业时就不再需要构建工具的详细知识了。
自动化创建和拆卸构建作业的能力是敏捷持续集成构建生命周期的一部分。
让我们一起探讨一下下列的几个要点：
要点1：作业配置的配置控制
让持续集成系统 的每个组件都处于配置控制之下是一个好的实践。这些组件不仅仅包括源代码，还包括基础的构建系统 和构建作业。
大多数构建工具把作业配置以文件形式保存在主系统上。这些文件设定为普通的 XML格式，可以直接通过某种REST API前端接口正常地存取这些文件。某些构建工具具备一些内置的特 性，可以利用这些特性把作业配置以文件形式保存到任意位置。
因为可以把作业配置保存为文 件，就能够把作业配置以文件形式保存到配置管理（CM）系统中了。不管是直接修改文件然后再上传到 构建工具，还是修改构建工具的作业配置，保存这个文件后再把它手工上传到配置管理系统，用这两种 方式针对作业配置所做的任何变更都会被记录下来。实际实施哪种方法取决于从构建工具中直接访问作 业配置文件的简易程度。
在配置管理系统中保存作业配置还有一个重要的理由，如果发生灾难 性故障，丢失了所有作业配置，构建系统可以比较迅速地恢复，把所有作业、构建日志和构建历史恢复 回已知的最近的一次良好状态。
要点2：作业维护性
不言而喻，维护上千个不同的配置 将是一件令人头疼的事，正因为如此，才使得作业配置的标准化格外重要。如果必需要做一次变更，同 时它又会影响到大量相似的作业，那么更加简单的做法是编写脚本或创建特定的任务去修改这些作业。
对于持续集成来说，在构建系统中有上千个作业无论如何也不是最好的策略。我们将在下面的 要点4中对此做更加深入的讨论。
要点3：开发人员控制
尽管开发人员被鼓励独立自主地 工作，但他们也要使用一个集中的构建系统构建应用程序，他们需要依照构建过程按照指导方针工作。
开发人员希望他们的代码变更能得到快速反馈，所以不希望在构建工具和作业配置上浪费过多 的时间。假如通过一个按钮为开发人员提供“自助服务”式的解决方案，可以自动化地构建作业，就会 帮助他们更快地完成开发任务。
要点4：精益持续集成系统
尽管软件开发团队在产品研 发中采用了敏捷方法，但在他们却不一定在工作中以相同的方式使用构建工具，也就是说已经适当配置 过的构建工具不应该包含太多长期的构建作业。理想情况下，应该把作业看作构建持续集成生命周期的 一部分，按需来创建。有一种常见的方法是通过任意历史作业配置重新创建构建作业，并保留本次构建 痕迹，即日志、工件、测试报告等，然后只在构建工具中保留少量作业。
当然，这一解决方案 （即按需创建-拆卸作业）或许是一个无法达成的目标，但该要点在此主要强调，应该把构建工具中的 作业数保持在一个可管理的级别。