Jenkins （在与Oracle发生纠纷后从Hudson分叉）已经存在了很长的时间，并已成为创建持续集成（CI）和持续交付/部署（CD）管道的领先平台。 其背后的想法是，我们应该创建执行某些操作（例如构建，测试，部署等）的作业。 这些作业应链接在一起以创建CI / CD管道。 成功如此之大，以至于其他产品紧随其后，我们得到了Bamboo ， Team City和其他产品。 他们都采用了类似的逻辑，即拥有工作并将它们链接在一起。 操作，维护，监视和作业创建大部分是通过其UI完成的。 但是，由于其强大的社区支持，没有其他产品能够压制詹金斯。 有超过一千个插件，而一个插件很难想象至少其中一个插件不支持的任务。 詹金斯（Jenkins）所具有的支持，灵活性和可扩展性使其始终保持着它作为最流行和广泛使用的CI / CD工具的统治地位。 基于UI大量使用的方法可以被视为第一代CI / CD工具（即使之前有其他工具）。

随着时间的推移，新产品应运而生，随之而来的是新方法的诞生。 Travis ， CircleCI等将流程移至云中，并基于自动发现以及主要与YML相同的配置，这些配置与应在管道中移动的代码位于同一存储库中。 这个主意很好，令人耳目一新。 这些工具不会在集中的位置定义您的工作，而是会检查您的代码并根据项目的类型执行操作。 例如，如果他们找到了build.gradle文件，他们将假定您的项目应该使用Gradle进行测试和构建。 结果，他们将运行gradle check来测试您的代码，如果测试通过，则遵循gradle assemble来构建工件。 我们可以将这些产品视为第二代CI / CD工具。

第一代和第二代工具存在不同的问题。 詹金斯（Jenkins）等产品具有强大的功能和灵活性，使我们能够创建可处理几乎任何级别的复杂性的定制管道。 这种力量是有代价的。 当您有几十个工作时，它们的维护非常容易。 但是，当该数目增加到数百时，对其进行管理可能会变得非常繁琐且耗时。

假设一个平均管道有五个工作（构建，部署前测试，部署到过渡环境，部署后测试以及部署到生产）。 实际上，通常有五个以上的工作，但让我们保持乐观的估计。 如果我们将这些工作与属于20个不同项目的20条管道相乘，则总数达到100。 现在，假设我们需要将所有这些工作从Maven更改为Gradle。 我们可以选择开始通过Jenkins UI对其进行修改，也可以勇敢地直接在代表这些工作的Jenkins XML文件中应用更改。 无论哪种方式，这种看似简单的更改都需要一定的奉献精神。 此外，由于其性质，一切都集中在一个位置，这使得团队很难管理属于自己项目的工作。 此外，项目特定的配置和代码属于其余应用程序代码所在的同一存储库，而不是位于某些中央位置。 詹金斯并不孤单。 其他大多数自托管工具也都具有它。 它来自一个时代，当时人们认为繁重的集中和水平划分任务是一个好主意。 大约在同一时间，我们认为UI应该可以解决大多数问题。 今天，我们知道许多类型的任务比通过某些UI更容易定义和维护为代码。

我记得Dreamweaver很大的日子。 那是在90年代末和2000年初。（请记住，那时的Dreamweaver与今天有很大的不同）。 看起来梦想成真了（因此得名？）。 我可以用鼠标创建整个网页。 拖放一个小部件，选择几个选项，写一个标签，然后重复。 我们可以很快地创建事物。 当时还不那么明显的是，结果是一笔需要支付利息的贷款。 Dreamweaver为我们创建的代码几乎不可维护。 事实上，有时候重新开始比修改使用它创建的页面容易。 当我们不得不执行其小部件之一中未包含的某些操作时，尤其如此。 那是一场噩梦。 如今，几乎没有人使用拖放工具来编写HTML和JavaScript。 我们自己编写代码，而不是依靠其他工具为我们编写代码。 这并不意味着不再使用GUI。 它们是，但是出于非常特定的目的。 Web设计人员在将结果传递给编码器之前可能需要依靠拖放操作。 还有很多其他示例。 例如，至少在婴儿期，Oracle ESB同样是错误的。 拖放不是要依赖的东西（但对销售有利）。

我要说的是，不同的方法属于不同的上下文和任务类型。 詹金斯（Jenkins）和类似的工具，从其UI监视和状态的视觉表示中受益匪浅。 它失败的部分是作业的创建和维护。 通过某种代码可以更好地完成此类任务。 有了Jenkins，我们拥有了强大的实力，但需要以维护工作的形式为此付出代价。

“第二代” CI / CD工具（Travis，CircleCI等）将维护问题减少到几乎可以忽略的程度。 在许多情况下，无事可做，因为他们会发现项目的类型并“做正确的事”。 在其他情况下，我们必须编写travis.yml ， circle.yml或类似文件，以为工具提供更多说明。 即使在这种情况下，该文件也往往只有几行规范，并且与代码一起驻留，从而使项目团队可以轻松地对其进行管理。 但是，这些工具并不能代替“第一代”，因为它们往往只在具有非常简单的管道的小型项目上才能很好地工作。 “真正的”连续交付/部署管道比那些工具所能完成的要复杂得多。 换句话说，我们的维护成本较低，但是却失去了功能，在很多情况下还失去了灵活性。

今天，像詹金斯（Jenkins），竹子（Bamboo）和团队城市（Team City）这样的老手继续在市场上占主导地位，并被推荐用于除小型项目之外的任何工具，而诸如Travis和CircleCI之类的云工具则主导着较小的环境。 同时，维护Jenkins代码库的团队认识到有必要引入一些重要的改进以将其提升到一个新的水平（我将其称为CI / CD工具的“第三代”）。 他们介绍了Jenkins Workflow和Jenkinsfile 。 它们共同带来了一些非常有用和强大的功能。 借助Jenkins Workflow，我们可以使用基于Groovy的DSL编写整个管道。 该过程可以编写为利用大多数现有Jenkins功能的单个脚本。 最终结果是代码的大量减少（工作流脚本比XML中传统的Jenkins作业定义小得多）和作业的减少（一个Workflow作业可以替代许多传统的Jenkins作业）。 这样可以简化管理和维护。 另一方面，新引入的Jenkinsfile允许我们在代码库中定义工作流脚本以及代码。 这意味着负责项目的开发人员也可以控制CI / CD管道。 这样，责任就更好地划分了。 Jenkins的总体管理是集中的，而各个CI / CD管道则放置在它们所属的位置（以及应在其中移动的代码）。 此外，如果将所有内容与“多分支工作流”作业类型结合在一起，我们甚至可以根据分支微调管道。 例如，我们可能有Jenkinsfile中定义的完整过程位于master分支中，而每个功能分支中的流程更短。 每个Jenkins文件中放置的内容取决于维护每个存储库/分支的人员。 有了Multibranch Workflow作业，只要创建新分支并运行文件中定义的内容，Jenkins就会创建作业。 同样，删除分支后它将删除作业。 最后，还引入了Docker Workflow ，使Docker成为Jenkins的头等公民。

所有这些改进使Jenkins达到了一个全新的水平，从而确认了其在CI / CD平台中的至高无上地位。

如果还需要更多，则有CloudBees Jenkins平台–企业版提供了惊人的功能，尤其是当我们需要大规模运行Jenkins时。

DevOps 2.0工具包

如果您喜欢本文，则可能对DevOps 2.0工具箱：使用容器化微服务自动执行连续部署管道一书感兴趣。 在许多其他主题中，它更详细地探讨了Jenkins Workflow ， Multibranch Workflow和Jenkinsfile 。

本书介绍了不同的技术，这些技术可以帮助我们更好，更有效地构建软件，并将微服务包装为不可变的容器 ，并进行测试并连续部署到由配置管理工具自动 配置的服务器上。 它是关于零停机时间和回滚功能的快速，可靠和连续的部署。 它涉及到可扩展到任意数量的服务器，能够从硬件和软件故障中恢复的自我修复系统的设计以及集群的集中式日志记录和监视 。

换句话说，这本书使用一些最新和最好的实践和工具来涵盖整个微服务开发和部署生命周期 。 我们将使用Docker，Kubernetes，Ansible，Ubuntu，Docker Swarm和Docker Compose，Consul，etcd，Registrator，confd，Jenkins等。 我们将介绍许多实践，甚至更多的工具。

翻译自: https://www.javacodegeeks.com/2016/01/short-history-cicd-tools.html