持续交付持续交付流水线
| 本文由 Jenkins World 发言人 Neil Hunt 撰写，他是 Aquilent 的高级 DevOps 架构师。 |
在拥有少数几个应用程序和较少部门划分的小公司里，使用当今许多可用的交付编排工具之一来实施支持这些应用程序的 CD 流水线相对比较简单。可支持的工具集可能有限，应用程序和安全实践的种类不多，而且通常参与者也较少。但在我过去的大型组织中，似乎有无休止的独特需求和难以逾越的障碍，要在每个新项目上实现这种程度的自动化。
|
Neil 将在九月份的 Jenkins World 上 展示 更多关于这个概念的内容，使用优惠码 |
Jenkins Pipeline 插件应运而生。我最近离职的前公司，一个拥有 600 多名 IT 人员和 150 多个应用程序组合的大型金融服务组织，着手在全公司范围内实施持续交付。在考虑了几个流水线编排工具后，我们认为 Pipeline 插件（当时称为 Workflow）是我们公司的卓越解决方案。Pipeline 延续了 Jenkins 的传统，提供了一个可扩展的平台，拥有恰到好处的功能集，使组织能够根据自己的需要快速扩展其功能。作为 Pipeline 的早期采用者，我们有着一系列复杂的需求，我们利用它来加速新项目的上线速度，并减少我们应用程序的持续功能交付时间。
在 Jenkins World 的演讲中，我将展示我们用于实现这一目标的方法。以下是一些例子：
-
我们利用 Pipeline Remote File Loader 插件编写共享的通用代码，并寻求社区对这些功能的增强。
Jenkinsfile，加载一个共享的 AWS 实用函数库
awsUtils.groovy，一些 AWS 函数的片段
-
我们从 EC2 代理迁移到运行在 Amazon Elastic Container Service 上的基于 Docker 的代理，这使得我们能够在几秒钟内启动新的执行器，并让团队拥有自己的执行器定义。
流水线运行 #1 使用标准的 EC2 执行器，为每个节点启动 EC2 实例；流水线运行 #2 使用共享的 ECS 集群，几乎即时地在集群中为每个节点实例化一个 Docker 代理。
-
我们还创建了一个通用流水线的 Pipeline Library，使符合某些模型 Thus, 已经准备好的端到端流水线得以使用。以下是一些示例：
-
Maven JAR 流水线：克隆 git 存储库，根据 pom.xml 构建 JAR 文件，部署到 Artifactory，并运行 Maven Release 插件来递增下一个版本。
-
Angular.JS 流水线：执行 grunt 和 bower 构建，然后将 S3 同步到 Dev、Stage 和 Prod 的 Amazon S3 存储桶。
-
Pentaho Reports 流水线：克隆 git 存储库，构建 zip 文件，并执行 Pentaho Business Intelligence Platform CLI，将一组新报表导入 Dev、Stage 和 Prod 服务器。
-
或许最重要的是，对于我们的安全和运维团队来说，手动“input”步骤是这次探索中的救命稻草！尽管持续交付的雄心是尽量减少这些步骤，但这是说服他人接受 Pipeline 可行性的最重要的功能，因为现在交付过程的任何步骤都可以通过 LDAP 授权权限组进行门禁检查。如果不是这个步骤的可用性，我们可能仍然生活在“这似乎是一个很好的开发工具，但我们将有一个独立的生产部署流程。”这样的环境中。相反，一开始我们的流水线充满了许多“input”步骤，然后我们利用收集到的数据，关注延迟最长的步骤，并团结所有人，以战略性地逐个消除它们为目标。
展望未来，我最近加入了 Aquilent 的云解决方案架构团队，我将在这里与我们的项目团队合作，在我们向持续交付迈进的过程中，进一步成熟这些 Pipeline 插件功能的使用。我们已经将 healthcare.gov 项目的几个组件迁移到了 Pipeline。该团队能够将几个 Jenkins 作业合并到一个可见的交付流水线中，在我们的 SCM 中与应用程序代码库一起维护流水线的生命周期，并更轻松地与我们的外部工具集成。
由于 Pipeline 插件早期采用阶段的功能不足以及转移组织政策的政治挑战始终存在，这段旅程一直并且仍然远非一帆风顺。但我们克服了许多这些问题，最终将某些流水线中的手动步骤从 12 个减少到 1 个，并将我们耗时 20 多分钟的 Jenkins 流水线在几个月的迭代后缩短到仅需 6 分钟。我希望您能加入 Jenkins World 的这个会议，了解我们在实现企业级持续交付的过程中所面临的挑战和取得的成功。