我们已经写了不少与 CI/CD 有关的文章，尤其是 Jenkins 的专题文章，从顶级 Jenkins 插件到 CI 系统并行功能对比的内容均有涉及。不过，让自称“意外创造了 Jenkins”的Jenkins 创始人川口浩介 (Launchable)，也就是 Kohsuke Kawaguchi (KK)，同 Cloudbees (Oleg Nenashev)、Verifa (Ewelina Wilkosz)以及 Incredibuild (Dori Exterman) 的 DevOps 专家小组聚在一块儿（线上形式）谈论 CI/CD 的发展历程？这样一幕简直可以说是梦想成真。我们把讨论分为过去、现在和未来三个部分（相信大家也猜到了）。
这篇文章包含了此次网络研讨会中提到的部分见解。 如需观看完整网络研讨会视频，请点击此处。
过去
了解专家小组对过去发生的事件有着怎样的看法非常有趣，因为在 DevOps 被正式命名为 DevOps 前，甚至是 CI/CD 或 Agile 出现之前，他们就已经在该领域从事相关工作了。我们希望能够了解他们对正确的以及本可以有不同结果的事情有着怎样的看法，代领我们探索 CI/CD 的源头和发展历程。
川口浩介表示，“现在，我们能够围绕软件开发驾驭更多计算机[……]”（我们十分认同这一观点！），但那时候你能使用的就只有你面前的一台计算机或笔记本电脑，或者是我当时使用的 Sun 工作站，但随着计算能力变得更加丰富，利用这一优势也更为合理。”
根据川口浩介的说法，现在存在的另一个过去不太明显的问题就是协作：“过去二十多年里，软件开发协作性变得更强了。那时更多的只是个人工作，而协作需要人们对世界的形式有着共同的理解。CI 系统提供了一个人们认同的普遍真理，比如哪些测试通过了，是什么变化导致某个部分遭到破坏。”
Oleg Nenashev 描述了 CI/CD 领域的发展，并强调了 Jenkins 对于这种发展的贡献：“每隔几年，我们所生活的世界就会发生翻天覆地的变化，因为我们环境、开发工具和编程语言全都在变。创建 Hudson 时，我们甚至都没有虚拟机，之后我们有了虚拟机，然后是容器，现在我们又有了 Kubernetes 集群，而针对环境的每一【部分】，你都可以建立一个将进行彻底优化的新解决方案。在我看来，Jenkins 最大的成就在于它为新一代的工具铺平了道路，因为只要你去了解这些工具就会发现，它们实际上都有 Jenkins 的影子。”
Ewelina Wilkosz 从开发者的角度分享了她对往日的 Jenkins 和 CI 的一些看法。“我记得自己对持续集成的第一印象就是它非常神秘，但神秘的面纱下又能看见 Jenkins 的大概轮廓。不过它与我们当时正在做的事情非常不同。我不知道这个工具是什么，也不知道到底是谁在维护它，在我成为 DevOps 团队的成员后才慢慢开始了解，但在开发人员和为他们维护 CI 系统的人之间却隔着一堵墙。”
CI 的其中一个优点就是，它为开发人员加快了反馈周期。Ewelina 也承认这一优点，但同时也提到了其中的不足：“这一点非常棒，因为作为开发人员，我们得到了反馈，而且获得反馈的速度非常快，但是我们得到的并不总是我们需要的反馈，因为我们并没有参与工具的创建，也没有配置或使用过这个工具，我们所做的就只是观察，一些相对而言更加主动的人也是花费了一些时间才真正打破那堵墙，然后逐渐揭开它神秘的面纱。之后工作开始有了一些重叠的部分，开发人员也参与到与 Jenkins 相关的一些工作中，但我还清楚记得，这是一件部分聪明人在某个地方所做的事，而他们只会把最终结果交给我们。”
基于这一点，Ewelina 认为事情原本可以有更好的结果：“我认为，我们其实一开始是可以把这件事做得更好的，我们应该更早地让 CI 系统成为开发人员工作的一部分。”
Dori Exterman 总结了围绕曾经的 CI 进行的讨论，并赞许了 Jenkins 以及该工具毋庸置疑的成就：“我认为，今天 Jenkins 在这么多行业中得以广泛使用，以及它作为庞大且极具影响力的生态系统这一现实已充分证明这一平台的理念是合情合理的，而且多年来都是如此，这就是我们唯一需要的证明。
不过，Dori 也指出了原本可以做得更好的地方：“我们本可以在可视性和质量方面拥有更好的理念，它与 Jenkins 平台紧密关联，从而将各种想法联系起来并产生更多见解[……]它在进行联结的同时，能从 CI/CD 过程中使用的通常处于零散和孤立状态的各种工具中衍生出更多想法。这是我认为从一开始就应该做的或者说从一开始就该实现的东西[……]。我现在仍然觉得我们缺少了一个能够让我们进入 Jenkins 庞大生态系统中的更为完善的途径，例如，如果这个特定模型中的某个变化经常导致一组特定的测试失败，那么作为开发经理我会想要了解具体情况，所以我可以在把开发人员的代码提交到 CI/CD 流程前，将测试左移给开发人员执行，或者为相应的代码添加更好的文档支持，防止开发人员创建此类变化导致持续测试失败或是在生产过程中创建回归 bug。而如今的 Jenkins 有着 1500 个插件，无论是出于道义还是可见性的考虑，我相信把它们全部连接起来仍是需要我们完成的使命。”
现在
如今的选择和方法多到让人眼花缭乱。原来的情况则比较简单——只有以 Jenkins 为首的少数几个工具，而今天却有着各种各样的工具。我们问专家小组成员： “就实施最新和最佳工具与优化传统工具和方法而言，究竟应该从哪里着手开始？”
Oleg 率先回答了这个问题，并表示现在虽然有了好几代的工具，但 Jenkins 依旧是必需品：“目前主要有三代工具；经典的工具包括Jenkins、TeamCity 还有许多其他工具，然后是相对比较固执的第一代，专注于 GitLab CI、GitHub Actions 等持续交付产品，现在还出现了更专注于 UNIX 方式的第五代，所以单个工具不可能完成所有事，现实是一个小工具能很好地完成某项工作并与其他工具整合。”
他又补充说：“所以，在我看来，目前市场上有三种类型的工具，所有这些工具都有合理存在的意义，所有这些工具都应该继续发展，对我来说，根据具体情况，你可以选择其中一种使用。所以，如果你需要一个高度定制的系统，在将所有东西整合到一起时，你会更想选择 Jenkins 或者是第五代工具。”
Oleg 继续解释为什么 Jenkins 的地位不可撼动：“但要把东西整合在一起，你还需要一个编排器，因此你可能会用到 Jenkins。在我看来，现在，就像你问到的，如果我要开始一个新项目，我要么选择 Jenkins 或自动化框架，要么开始建立完全云原生的东西，并将所有这些新技术结合起来，但即使我这样做，我仍然倾向于为自己‘隐藏’Jenkins 的用户体验，因为从开发者体验的角度来看，无论你的系统是不是云原生系统其实都无所谓，我只是希望有好的报告和见解，实际上从历史角度来看，Jenkins 一直是非常合适的选择，它在 CI/CD 系统中拥有出色的单元测试和覆盖率报告，即使生活在云原生世界，这依然是我们作为用户可以利用的特性。”
随后，Ewelina 也参与到讨论中，她在面对当前众多工具选择时也感到不知所措：“如今的工具数量太过庞大，而且在不断发展。我完全跟不上这样的发展脚步。按理说我就是专门研究这些工具的人，但可以肯定的是，这些工具中大部分我都不了解，所以这真的有点可怕[……]”。
谈到 CI 时，她重点讨论了开发者体验以及偏好的问题：“主要驱动力是用户体验和用户满意度，因为一天的工作结束后，开发人员应该对自己工作和创建软件的方式感到满意。”
此外，Ewelina 认为云在如今的开发者体验中扮演着关键角色：“如今非常了不起，也是五年前在我看来十分难以想象的一点就是，云正在成为一些大企业的标准。我原本以为他们会出于安全考虑坚持传统部署模式，但是他们都选择了云技术。大多数开发人员都可以轻松创建自己的虚拟机，并尝试不同的工具，所以他们不再局限于猜想，而是可以尝试各种东西，可以实验，可以找到最符合他们需求的东西，根据他们正在做的事，他们可以随时使用需要的工具，所以对他们而言，再去拥有一个必须亲自维护的完整实例也就没有多大意义了[……]。”
之后，Dori 将讨论的重点转向生产力：“作为一个热衷于提倡开发生产力的人，我个人认为，生产力和敏捷就是我的焦点所在，至少对于一个已经拥有 CI/CD 循环周期的公司而言，我相信缩短开发周期是支撑无止境的持续改进过程的重要支柱。但从这一角度出发，这也十分合理，而且这种方法也得到一个相对较新的角色的支持，它在开发领域不断获得巨大动力，这一新角色就是生产力工程师，而生产力工程师的主要目标就是不断改进开发工作流程和生产力以及开发周期性能。”
根据在 Incredibuild 的工作经验，Dori 补充道：“我在 Incredibild 工作的十年中，经常看到的现象就是，一旦开发周期缩短，一旦你开始这样做，你会发现这个周期会比之前周期更为频繁地执行。例如，如果你把 gtest 的执行时间从 11 小时缩短到 11 分钟，这其实是个真实案例，那么这种转变的结果就是你会直接得到一个更为频繁执行的周期，当然，除了能够明显减少耗费的时间和提高生产力外，将 11 小时缩短到 11 分钟意味着你现在每天可以执行一个周期 20 次而非 2 次，那么你每天就多了 18 个周期来学习和进行改进[……]。你可以增加额外的质量步骤，增加额外的工具，更频繁地学习，更为频繁和快速地尝试失败，并开展更多实验，因为如果一次实验需要花半天时间却只能作出些许调整的话，我相信你并不会频繁地去做实验，然后改进的机会也就会变少，所以说我极力倡导提高生产力和性能，当你有了坚实的基础，你就可以着手改进你的整个生态系统。”
针对速度方面的问题，川口浩介提出了不同观点，他认为做衡量的重要性尤为突出：“我认为进行衡量和从系统中获得更多的想法[……]。我可以尝试用非技术人员能够理解的话来进行描述，用一种能够展示相关进展情况的办法，这样，我认为这项工作就能获得更多支持[……]。”
Dori 对川口浩介的说明作了补充：“我完全同意这一点，我相信当我们在进行衡量时，特别是当你想证实投资回报率时，这是非常正确的做法。我认为，我们的很多客户或者 DevOps 经理忽略的一点就是，他们试图量化有形的衡量数据[……]节省的时间、提高的生产力，但是他们的工作还有其他类型的投资回报，这些投资回报是不大可能进行量化的，例如及时投入生产，预测生产情况，减少回归[……]。我认为，无形的投资回报也很重要，开发经理需要学习如何向他们的经理呈现这一类投资回报。”
未来
从未来的视角看，二十年前的我们几乎生活在石器时代。很奇妙的是，二十年后的我们回头看今天，想必会因为这一切看起来都是那么古老而感到好笑。但在那一天到来之前，我们能做的就只有猜测。
我们也问过专家小组的成员，他们认为未来会有怎样的趋势，或者他们有哪些预测和期望，以及如何才能与时俱进或为未知做准备？
Ewelina 提到了安全方面的趋势，这也可能会是我们在一段时间内所做工作的主要部分：“自从公司不再固守传统部署模式并向云端转移，之前重要的安全问题现在突然间都变得十分突出，我从来没有在三、四、五年前听到这么多与安全问题相关的讨论。还有整体合规性要求方面，总是有很多关于安全的要求。我们在云端完成部署后，有人便可以找到一个后门，然后进入到公司内部基础设施，这确实非常危险，很多人都在关注这一问题，人们也在了解相应领域的知识。”
展望未来时，Dori 对趋势和大趋势作了区分：“大趋势驱动着行业中细分的趋势。例如，在我们的领域中，我相信一个更有趣的趋势与质量、敏捷以及快速和可预测的上市时间有关，所以今天在大多数开发组织和开发团队中，尤其是在大型企业级软件中，自动化测试和测试覆盖方面都存在着巨大的技术深度，阻碍着持续交付实践的全面应用，我相信所有这些都是属于推动软件社区优化方法论和生产力的敏捷和上市时间大趋势的一部分。我认为这是开发领导人将面临的巨大挑战。为了向持续交付的目标迈进，开发经理必须从方程中消除人为因素，并依靠他们信任且能不断做出改进的端到端自动化流程。我已经能看到这种巨大的测试技术深度正带动技术向着振奋人心的方向发展。”
Dori 还谈到了人工智能，这也是众所周知的趋势（在我们的 DevOps 趋势文章中也有提及）：“我尤其关注和在意的一项技术就是编写单元测试的人工智能，或者是加快开发人员编写测试速度的人工智能，比如 Diffblue，它也是人工智能领域一家非常有趣和振奋人心的新兴工具，为填补测试自动化技术债务的巨大市场空缺，相信我们会看到更多类似的技术出现。当然，一旦这些测试由人工智而非开发人员编写，大型项目中将会有几十万个这样的测试，而大量的测试必然会减缓运行速度，这又回到了我的第一个观点，也就是生产力解决方案，包括 Incredibuild、分发和缓存等，或是运行重要测试，例如作为川口浩介工作重心的 Launchable。所以我觉得未来几年的 CI/CD 领域会变得非常有趣，我也迫不及地待想要知道哪些趋势会在这段时间里大放光彩。”
如需了解更多未来趋势和预测，以及相关问题的回答，请观看网络研讨会完整视频。
