Gregory Szorc认为现代持续集成（CI）平台虽然功能强大，但过于复杂且方向偏离。尽管这些平台如GitHub Actions等为开发者提供了便利，使得软件发布更加频繁和可靠，但其复杂性增加了使用难度。Szorc指出，CI平台本质上是一种远程代码执行服务，但其复杂性可能掩盖了其核心功能，甚至可能被滥用。

现代CI系统的复杂性与方向偏差

Gregory Szorc在其博客中指出，尽管现代持续集成（CI）平台在功能上比几年前更强大，但其复杂性也随之增加，甚至偏离了其核心目标。CI平台的核心功能是作为“远程代码执行服务”，帮助开发者更频繁地发布可靠的软件。然而，随着功能的不断扩展，CI系统逐渐变得与构建系统难以区分。

CI系统的复杂性

现代CI平台（如GitHub Actions、GitLab Pipelines等）通过YAML配置文件提供了丰富的功能，包括模板系统、触发器、条件执行、依赖管理、Docker环境定义等。这些功能虽然强大，但也使得CI系统变得异常复杂。Szorc认为，复杂的CI系统本质上已经与构建系统无异，两者在功能上高度重叠。例如，GitHub Actions的工作流与Makefile的结构非常相似，唯一的区别在于执行模型（CI系统是远程的，而构建系统通常是本地的）。

CI系统的冗余性

Szorc进一步指出，CI系统的功能实际上可以通过构建系统来实现。一个足够先进的构建系统（如Bazel）已经具备了远程执行、缓存等CI系统的核心功能。因此，CI系统的存在显得冗余。他认为，CI功能应该作为构建系统的扩展，而不是一个独立的系统。这样不仅可以减少复杂性，还能让开发者更容易地使用CI功能，例如在本地运行CI任务，而不必先将代码推送到远程服务器。

CI系统的方向偏差

Szorc认为，现代CI平台（如GitHub Actions和GitLab Pipelines）在抽象层次上存在偏差。它们被设计为特定领域的CI平台，而不是更通用的计算平台。理想的CI平台应该能够通过API调度任意的计算任务，而不受限于YAML配置文件。GitLab Pipelines在这方面做得较好，支持父子管道、多项目管道等高级功能，但仍缺乏一个通用的API来直接调度任务。

Taskcluster：一个强大的CI平台

作为对比，Szorc提到了Mozilla的Taskcluster，认为它是一个真正的CI平台。Taskcluster通过API调度任务，支持复杂的任务依赖关系，并且具有强大的安全模型。与GitHub Actions和GitLab Pipelines不同，Taskcluster不依赖于YAML配置文件，开发者可以自由定义任务的执行方式。尽管Taskcluster功能强大，但其学习曲线陡峭，适合需要高度定制化的用户。

未来的愿景

Szorc设想了一个统一的“远程代码执行平台”，能够同时支持构建、CI和批处理任务。这个平台应该具备强大的API，允许开发者通过编程语言定义任务，而不是依赖YAML配置文件。虽然目前已有一些工具（如Bazel、Taskcluster）部分实现了这一愿景，但尚未有一个产品将这些功能整合为一个统一的解决方案。

结论

尽管Szorc的愿景在短期内难以实现，但他认为，随着构建系统和CI系统的复杂性不断增加，统一两者的需求将变得越来越迫切。他呼吁CI平台提供商（如GitHub、GitLab）考虑这一方向，推出更通用的计算平台，而不仅仅是专注于CI功能。

评论内容总结：

1. CI与构建系统的融合：

   • 有评论认为CI和构建系统应该更紧密地结合，甚至可以使用构建系统来实现CI功能。
     • 引用："So here's a thought experiment: if I define a build system in Bazel and then define a server-side Git push hook so the remote server triggers Bazel to build, run tests, and post the results somewhere, is that a CI system? I think it is!" (zokier)
     • 引用："I’ve been using Pulumi automation in our CI and it’s been really nice." (e1gen-v)

2. 对现有CI工具的批评：

   • 许多评论对现有的CI工具表示不满，认为它们过于复杂或不够灵活。
     • 引用："These online / paid CI systems are a dime a dozen and who knows what will happen to them in the future…" (tacker2000)
     • 引用："I’m convinced that the CI industry is mostly snake-oil being sold to technically incompetent managers." (aa-jv)

3. 简单与复杂的权衡：

   • 有评论认为CI工具应该在简单性和复杂性之间找到平衡，过于复杂的工具会增加开发者的负担。
     • 引用："Any universal build system is complex. You can either make the system simple and delegate the complexity to the user, like the early tools, e.g. buildbot." (lukaslalinsky)
     • 引用："Putting too much responsibility in the ci environment makes life as a developer more difficult." (k3vinw)

4. 本地开发与CI的结合：

   • 一些评论强调本地开发的重要性，认为CI工具应该支持本地开发，而不是完全依赖云端。
     • 引用："Local-first, CI-second." (eisbaw)
     • 引用："The key thing is to force yourself to have a 'developer workstation + build server' mentality from the very beginning." (aa-jv)

5. 对Jenkins的推崇：

   • 尽管有新的CI工具出现，但仍有评论认为Jenkins是可靠的选择。
     • 引用："2025 and Jenkins still the way to go" (donperignon)
     • 引用："That's why God created Jenkins. My favourite application ever" (iberator)

6. 对CI定义的讨论：

   • 有评论指出文章中没有明确定义CI，认为CI不仅仅是构建工具，而是持续集成实践的一部分。
     • 引用："The issue that I see is that 'Continuous integration' is the practice of frequently merging to main." (SideburnsOfDoom)
     • 引用："Not a single definition of CI in the posting at all." (m-s-y)

总结：评论中对CI与构建系统的融合、现有CI工具的复杂性、本地开发与CI的结合、以及Jenkins的可靠性等问题展开了广泛讨论。许多评论者认为CI工具应该更加简单、灵活，并且支持本地开发，同时也有对现有CI工具的批评和对Jenkins的推崇。