在 DeliveryConf 大会上，VMware 主管工程师 Bryan Liles 讨论了构建持续集成交付（CI/CD）管道的一系列原则。Liles 建议，应将 CI/CD 视为模式而非 Jenkins 或 Spinnaker 这样的具体实现；需要构建一种平台，它由独立于技术堆栈的可组合部分和可替换组件构成。
演讲一开始，Liles 介绍了会有多少企业按照传统的方式构建 CI/CD 管道，并阐明建立此类管道的目的是实现应用从开发环境到生产环境的迁移。交付过程在本质上就是从源代码管理方获取应用的代码，进而在管道中编译应用，形成工件并打包（bundle）存储在仓库中。最后，管道将打包文件交付给各个环境，例如开发、测试和生产。Liles 指出，如果交付管道看上去非常复杂，那么这意味着技术栈不应该再继续复杂下去了。
在 Liles 看来，工程人员应该将部署管道看成是一些可组合的块和模式，而非仅注重实际使用的 Jenkins 或 Spinnaker 等具体实现。例如，管道中的一部分可以是完成应用构建、运行测试和创建工件的集成块，该部分可以使用 Jenkins 实现，但也支持使用 Circle CI 等其他工具。管道中的另一个块可以部署应用、征求批准和执行数据迁移的交付过程。集成和交付块都具有一些相同的基本组件，例如 Webhook 触发器、工作流、通知和批准等。集成块和交付块是部署管道这一更大的可组合部分中的一部分。
Liles 提出：“必须更多地考虑系统的可组合性。”部署管道应该是一种将应用交付至指定目的地的应用发布“平台即服务”（PaaS）。Liles 建议将部署管道重新定义为可组合的 PaaS，工程人员可轻易更改其中的各个组件。该模式的典型例子就是 Kubernetes。作为构建平台的平台，部署管道可基于Kubernetes 实现与上述集成块和交付块一样的基本组件，同时支持使用其它各种不同的工具。例如，集成部分可以使用 Tekton 或 Argo 实现触发器、工作流、通知和批准块。
Liles 进而指出，Jenkins、Spinnaker 或 ConcourseCI 之类的工具可用于定义如何构建 CI/CD 管道以及如何使用它们，但应在使用中汲取前车之鉴，避免入坑。由此，他建议应以破旧立新的思维去利用工具：
我们确实需要换种思维去使用各种工具。技术现状驱动我们到达了当前的位置，但这并非我们所需要的高度。我们应该拓展思维，破旧立新。
Liles 最后总结道，工具本身是复杂的，但从生态系统角度看，我们应致力于去构建更小且可组合的工具集。他建议工程人员琢磨一下如何共同改进生态系统，而不是沉溺于如何在现有工具上锦上添花。他认为自己提出的构建方式仅是抛砖引玉，“关注点应是更多地考虑系统中的可组合性。”
原文链接：
Reimagining CI/CD Pipelines as Composable Blocks with Bryan Liles
评论