这个程序员如何以一己之力阻止了 Bug 代码的提交并改变整个 DevOps 世界？
【CSDN 编者按】Jenkins 是基于 Java 开发的一种持续集成工具，能够帮助项目实现高度的工程化，而它的前身则是 Hudson。2004年，Sun 公司的 Java 程序员川口耕介为了让同事的工作更轻松些，创立了持续集成工具 Hudson，但这之后，这个工具打败了许多历史悠久的框架，并在 2007 年开始逐渐取代 CruiseControl 和其他开源构建工具的江湖地位。
但在 2010 年 Oracle 对 Sun 收购带来了 Hudson 所有权问题后，社区采纳了将项目名称从“Hudson”改为“Jenkins”的投票结果，于 2011 年创建了 Jenkins 项目——99% 的 Hudson 开发人员都转向了 Jenkins 开发，包括最初的创建者川口清子。现在，Jenkins 已经支持超过 1000 个插件，并凭借多样而强大的插件成了整个开发生命周期中的一个中心点。
本文中则采访了 Jenkins 之父（现任 CloudBees CTO）川口清子，解答了关于 Jenkins 的来历和未来计划等问题。
以下为译文：
在对着一大群 DevOps 爱好者发表了一番激动人心的演说之后，Jenkins 项目创立者（现任 CloudBees CTO）的川口清子花了些时间，给我们解答了 Jenkins 的来历、未来计划、以及他是不是真的有时间参与其中等问题。
创立持续集成工具 Hudson
最后一点的答案是：没有太多时间。但这也并不一定是坏事，因为川口告诉我们，他曾经有个习惯，就是留下很多 bug。2004 年他在 Sun 微系统公司做 Java 程序员时，他经常收到同事打来的电话。
“他们会突然发现整个项目无法编译了，或者出了别的错误。他们给我打电话说：‘我看到上次修改是你做的。你能看看是怎么回事吗？’通常原因都是我犯的错误。”
就像任何优秀的程序员一样，川口决定用代码来解决这个问题。“我觉得这种事情出过太多次了，所以我决定写个程序。”
这个程序就是后来的 Hudson，一个持续集成工具，之后这个工具打败了许多历史悠久的框架，比如基于 Java 的 CruiseControl 等。
但是，川口并没有考虑过竞争的问题，他只想让同事的工作更轻松些。有了 Hudson，程序员就可以从自己的任务列表上去掉构建和集成这两项工作。“我们能够转交给自动化和计算机的任务越多越好。”
但是，川口已经注意到 Sun 开始走下坡路了。“许多优秀的人都离开了。”他说，但由于有了 Hudson，新入职的人培训速度加快了。他说，“我发现，这也是 Hudson 降低人们思想负担的一种途径，能让新人专注学习他们应该学习的东西，从而更快地提高生产力。”
走向开源
受到当时 Sun 开源部分源代码的启发，也因为这个项目已经变得过于庞大，无法再用个人时间维护，于是川口决定将项目开源。
“嗯，对于我来说这个过程非常自然。实际上我甚至觉得要是不开源就根本不可能实现现在的程序……而且，当时在 Sun 微系统公司，我们也在尝试在开源的基础上开展一切工作。”
川口对于项目开源的结果非常满意：“感觉就像建个所有人都能享受的大帐篷。人们在交换想法的同时改进想法，而交换想法的最好方式就是让更多的代码开源。”
出任 CTO
Sun 的逝去众人皆知。公司于 2010 年被 Oracle 收购，Hudson 这个名字也被收为注册商标。但是，代码早已经分叉，项目于 2011 年以 Jenkins 的名义继续进行。而 Hudson 归属于 Oracle，后来交给了 Eclipse 基金会，并最终于 2017 年被弃用。
由于对 Oracle 感到失望，川口在 2011 年以 InfraDNA 的形式开始对 Hudson 提供支持。同年晚些时候，CloudBees 招募了川口，并任命他为 Jenkins 专家的 CTO。
对于川口来说，成为 CTO 的体验很不错。“CTO 是最奇怪的角色。这个角色定义得并不好……我发现过去将近十年内，我的角色经常发生变化……我必须找出自己的定位。我曾经因此感到十分焦虑，但我现在很喜爱自己的角色。”
关于 Jenkins 和 CloudBees 的未来
作为 CTO，川口承认他被各种选择“惯坏了”。虽然他这些日子在 Jenkins 项目上花的时间少了，但他表示“我能选择的每件事情都很有趣。与客户交涉很有趣，写代码也很有趣，孵化新项目更加有趣。”
关于未来，川口对于 2019 年即将出现的合规和治理模型感到十分兴奋，这个模型可以让管理员在不满足特定条件的情况下停止某个管线。这个模型对于需要合规的企业非常有吸引力。
谈到这些，他说：“合规和治理实际上非常符合我的心意。我认为，大型企业无法快速前进的主要原因就在于此。”
“所以，我认为我们可以帮助他们在软件开发方面做得更好，就像我们给世界带来了重大影响一样。”
川口关心的另一个领域是测试。测试是 CI/CD 过程中重要的一个步骤（至少它鼓励了人们去写更多的测试）。但是他担心，虽然有“更多的测试能让软件开发变得更干净……但并没有太多规则来评价这些测试的质量如何。”
“通常，在进入产品前变更的验证绝大部分时间都被测试占据了。”
测试用例的自动化生成依然是个难题。川口知道利用机器学习能找出错误，但这种过程目前依赖于自动化。相比之下，他更感兴趣的是根据过去的成功和失败的执行产生的大量数据来安排测试的运行顺序。
此外，当然也需考虑最终用户。川口注意到，他访问过的一些公司采取了这样的流程：将一小部分产品流量作为最后一个测试阶段，但必须强调，这种流程必须非常谨慎，“以免影响到客户”。
最后一点秘籍
川口的作品对于开发社区的影响是不可否认的。虽然 Jenkins 之父的参与减少了，但他依然认为“即使在十年以后，Jenkins 社区依然存在自我进化的能力。”
社区带来的持续不断的开发和重新发明让他对该框架充满了信心。“我觉得这正是整个 Jenkins 项目的秘籍。它能够不断重新定义自己。”
英文：How one programmer's efforts to stop checking in buggy code changed the DevOps world
链接：https://www.theregister.co.uk/2018/11/09/jenkins_interview/
作者：Richard Speed
译者：弯月
CSDN 公众号秉持着「与千万技术人共成长」理念，不仅以「极客头条」、「畅言」栏目在第一时间以技术人的独特视角描述技术人关心的行业焦点事件，更有「技术头条」专栏，深度解读行业内的热门技术与场景应用，让所有的开发者紧跟技术潮流，保持警醒的技术嗅觉，对行业趋势、技术有更为全面的认知。
如果你有优质的文章，或是行业热点事件、技术趋势的真知灼见，或是深度的应用实践、场景方案等的新见解，欢迎联系 CSDN 投稿，联系方式：微信（guorui_1118，请备注投稿+姓名+公司职位），邮箱（guorui@csdn.net）。
推荐阅读：