您使用詹金斯吗？ 很可能是，因为这是迄今为止该类中最受欢迎的项目。 我一直很乐意与一位开发人员交谈，并提出几个棘手的问题。 在这里，我们不仅有开发人员，而且还有詹金斯本人的创建者川口浩介 （ Kohsuke Kawaguchi） 。
如您所知，Jenkins是一个拥有MIT许可证的开源项目。 最近举行了FOSDEM会议，这是世界上最大的致力于自由软件的会议。 免费，开放，有来自世界各地的数十名发言人。 这意味着您可以在那里见到任何人，甚至包括Jenkins的创建者。 在JUG.ru集团的一小部分朋友和同事的陪伴下，我们意外地降落在那里，并能够与Jenkins的创作者进行了精彩的采访。
因此，在我们的虚拟工作室中， 川口晃一郎 （将在下面进行自我介绍并详细解释所有事情），JUG.ru集团的Ruslan Akhmetzyanov ARG89和CIAN的Kirill Tolkachev tolkkv （我们的常任 发言人古鲁Groovy，Gradle，Spring和Netflix技术栈）您可以从“汇报”播客中了解。
罗斯兰：您好。 首先，告诉我们一些关于您自己和詹金斯的事情？
Kosuke：我叫Koske，主要是Jenkins的创建者和CloudBees的CTO。 Jenkins是一种工具，开发人员可以使用它来自动化软件交付过程的各个阶段。 我个人认识一些来自俄罗斯的使用Jenkins的程序员，并且很高兴认识其他人。
基里尔：我也将自我介绍-我是一名开发人员，还将组织莫斯科詹金斯地区聚会（JAM）。 我在使用Jenkins方面有丰富的经验，尤其是脚本/声明性管道。 您能告诉我开发詹金斯公司的CTO在做什么吗？
Kosuke：我团队的任务之一是与社区互动。 我们公司的成功在很大程度上取决于开源项目的成功。 另一个重要的任务是教育公司中的其他人员有关开源如何工作的知识。 总的来说，我们在公司和社区之间建立了非常有趣的关系：每个人都从彼此之间学习到一些东西，并且我们非常重视这种互动。
您还询问了技术主管执行什么功能。 事实是，该功能随着公司的发展而发展。 起初，我就像一位首席程序员，从事了大量的技术工作。 但是随着公司的发展，其他人逐渐开始从事这项工作。 例如，一个单独的团队开始处理Pipeline。 我会定期与他们交流，以了解他们的工作，有时我会提供建议。 但是他们可以自行做出与设计和开发相关的所有决策。 总的来说，这种角色演变非常有趣，我必须不断适应。
Kirill：如果我对您的理解正确，那么您的关注点已经从技术问题转向与社区合作？
Kosuke：是的，我正在做的很多事情都与此有关。 有些事情只有一家公司的创始人才能说。 因此，相对而言，我的活动的一部分是挥舞旗帜，并在需要改变路线时朝某个方向呼吁社区。例如，去年是这样。 此外，我们和团队都致力于推广詹金斯：我们解释我们的目标是什么，我们要克服哪些困难。 此外，当我需要对总体情况进行演讲时，我会激发更多的信心。 这就是我的简要活动。
Kirill：从技术工作向组织工作的这种转变开始于多少年前？ 您能否讲述詹金斯的故事以及随着项目的发展您的角色发生了什么变化？
Kosuke：该项目于2004年问世 ，起初我在晚上和周末进行这项工作，也就是说，这是一种业余爱好。 但是该项目逐渐发展壮大。 我花了很多时间创建这个平台，其他人可以在该平台上编写他们的应用程序。 随着时间的推移，出现了一个生态系统和一个开发人员社区，其中一些来自俄罗斯-例如，Oleg Nenashev（Twitter： @oleg_nenashev ），他在Jenkins之上编写了一个非常有趣的子系统。 随着项目的流行，与用户进行更好的互动以及他们的培训的需求变得更加迫切。 因此，我开始对这些事情做更多的事情。 终于，在2010年左右，詹金斯变得如此受人欢迎，以至于我决定将全部时间都花在他身上，并成立了一家公司。 从这一刻起，就增加了公司组织方面的工作，以便与社区合作。 公司在发展，我开始问自己一个问题-除了我之外，谁都无法开展哪种活动？ 在公司和社区中，都有许多有能力的人乐于准备承担更多责任。 逐渐地，他们开始做很多我以前自己做的事情。 因此，总的来说，我们的道路看起来像。
基里尔：谢谢。 如今，Jenkins是最受欢迎的CI系统。 与其他商业CI系统相比，Jenkins的商业版本有多普遍？ 例如，使用Travis Enterprise还是可以在本地工作的系统？
Kosuke：开源Jenkins是一个大型项目，它有很多用户。 CloudBees的规模要小得多。 因此，如果我们设法将甚至百分之一的Jenkins用户群转换为CloudBees用户，这将是一个非常大的结果。 所有基于开源产品的公司都遵循这一原则。 另一个重要的问题是，我们有多少努力帮助产品应解决的人们。 我们计算技术支持的有效性，如果我正确地记得统计数据，通常来说，我们的服务会满足他们的要求。
基里尔：您是说那些使用付费版本的人吗？ 还是那些有自由的人？
Kosuke：他们两个。 也就是说，如果一个人购买了产品，将获得他的支持，但也可以在不使用专有软件的情况下获得该支持。
Kirill：也就是说，您充当开发人员和用户（开源和商业用户）之间的中介。 我是否正确理解您还有产品愿景的任务？
Kosuke：这并非完全正确，我们有一个单独的产品团队。 我不是用户的代表，但我经常与许多人（用户）会面，不仅是，我与社区保持联系。 例如，我有一个“高级摘要”列，用于公司的其他员工。 在这些帖子中，我讨论了用户如何编写软件以及它对Jenkins的意义。 因此，我试图影响产品团队的决策。
Kirill：显然，您在公司中扮演着重要角色。 让我们继续讨论更多个人问题。 您最喜欢的Jenkins功能是什么，您可以从早上到晚上谈论什么？
Kosuke：好吧，从早到晚的交谈将很困难。 现在，我对组织的工作方式更加感兴趣-我认为这是因为我在组织中的职能。 当我一个人工作时，我的注意力更多地集中在个人功能上。 现在我不这么认为，因此我很难回答您的问题。
Kirill：那么，也许您还记得几年前实现的某些功能，这些功能令我感到非常自豪？
Kosuke：我可以谈谈我们最近开发的一项重要功能-我认为这对用户来说会更有趣。 这是去年的Jenkins Configuration as Code项目 。 我们看到用户逐渐从在GUI中单击鼠标来管理Jenkins过渡到通过git存储库中的配置文件进行配置。 长期以来，人们一直认为需要“配置为代码”项目，并且编写了许多临时拐杖来执行此功能。 但是，其中一项任务还不够大。 最后，我们设法将社区中对这个新项目感兴趣的人们聚集在一起，并创建了一个相当大而周到的工具。 这个项目的许多方面都取得了很好的效果，并且获得了相当广泛的欢迎，这让他们感到高兴。
您可以回想起另一个项目Jenkins X，它是朝着完全不同的方向发展的。 它是专门为与Kubernetes合作而创建的。 得益于这种专业化，我们可以实现平滑的集成，并掩盖由于集成以及连续交付流程的连接而产生的复杂性。 因此，我们认为实施最佳实践非常容易。 我认为，由于有了这个项目，Jenkins将对许多执行标准操作并且不想花很多时间进行配置（需要所有工作）的人可用。
Ruslan：在编写Jenkins时，您是否使用Jenkins？
Kosuke：是的，Jenkins项目有自己的Jenkins。 实际上，我们有一个大型实例，它在每个插件和内核上进行一次常规审查。 此外，还有一份与安全和漏洞有关的特别重要工作的副本，因为安全功能的开发是在单独的专有存储库中进行的。 最后，还有第三个实例来执行更重要的任务，例如对密钥进行签名以及与发布相关的事情。 除了这三个以外，我家里全天候都在工作。
Kirill：您提到了JenkinsX。Jenkins本身就像一把瑞士刀，带有插件，它可以执行任何操作。 相反，Jenkins X是高度专业的，它存在于Pipeline并与Kubernetes一起使用。 您和您的公司坚持哪种技术策略？ 您仅支持Jenkins和Jenkins X吗？ 或者，除此之外，还有用于Mesos集群的Jenkins XX，用于Cloud Foundry的Jenkins XXX等吗？
Kosuke：我认为很大程度上取决于社区的反应。 当然，拥有一个通用平台非常重要。 问题是谁真正实现了这种灵活性。 如今，用户通常可以直接访问它。 如果您是大型公司并且正在做一些不寻常的事情，这将很方便。 但与此同时，我知道许多人不需要这种灵活性。 想象一下您来到饭厅并要求做一个三明治。 您可以选择七种面包，五种黄油，四种奶酪，还需要决定所有食材。 但是您并不需要所有这些选择，您只需要一个美味的三明治，也不想弄清楚如何做对。 我知道许多人对詹金斯持这种态度，并希望所有的灵活性都可以站在我们这边。 Jenkins X是朝着这个方向迈出的第一步。 如果这个项目继续取得成功，我很乐意尝试对固件和物联网，移动平台或机器学习做类似的事情。 我认为在许多垂直市场中，人们只需要一种工具即可使他们快速将产品投入生产。 您来自俄罗斯，所以您最有可能了解JetBrains吗？
基里尔：当然可以。
Kosuke：我认为他们遵循类似的策略。 它们具有非常灵活的基础，在其基础上还有许多专业的附加组件，实质上，相同的元素以不同的方式组装。 用户对此表示感谢，我非常喜欢他们的方法。
西里尔：多年来，当我建议使用某些插件时，我在许多社区中都观察到了相同的画面-顺便说一下，现在https://plugins.jenkins.io可以为我提供很多帮助，所有认可的插件都在那儿。 问题在于人们正在尝试在所有情况下都使用一种通用工具，这通常不适用于特定情况。 因此，现在我通常只推荐一种工具-管道，这是一种适用于所有情况的理想工具。 但是出现了一个新问题。 人们尝试使用脚本化管道或声明性管道而不了解内部的布置方式。 基础架构存在问题，节点之间建立了对应关系，数据共享，代理与主服务器之间出现异常流量，或者主服务器伸缩问题。 从您的角度来看，哪种工具更好：那是指示解决问题的唯一正确方法的工具，例如Jenkins X？ 还是像脚本管道这样的工具会询问您所想的到底是什么？
Kosuke：我不确定我是否正确理解你，但我会尽力回答。 日语中有“ kata”一词，我不知道如何准确翻译。 除其他外，它在柔道中使用。 我们正在谈论的是学生学习的严格定义的动作：例如，以某种方式举起手以偏转一定的打击。 我做了一些这样的事情，所以我知道其中最简单的一个。 面临的挑战是要记住一组简单的动作，某种模式或最佳实践。 但这仅仅是开始。 知道了这个基础，如果情况需要，您可以继续正确地保留它，而不会违反基本运动本身。 您可以研究自己的空间和领土，但同时知道共同的基础也可以为您提供帮助。 如果您不认识她，您总是会问自己-我做对了吗？ 即使您写的东西行得通，您仍然有疑问。
一般而言，您的问题使我想起了kata。 我认为詹金斯也有类似的情况。 Jenkins X提供了基础，当您开始更深入地了解它时，可以在必要时借助插件和其他工具来保留它。 当然，为了提供更好的Kubernetes体验，Jenkins X必须牺牲灵活性。 但是，詹金斯X（Jenkins X）将您推向最佳实践的事实并不意味着您就没有选择的余地。 总的来说，对于任何软件来说都是如此。 只是有了Jenkins X，我们的思维方式发生了重要变化。 以前，我们仅创建系统的关键元素-平台和插件，这取决于用户组装。 有了Jenkins X，社区已经采用了一种新方法，我认为这是非常重要的一步。
基里尔：如果您不介意，我还会有两个问题。 去年哪项功能给您带来了最大的麻烦？ 每个项目都有困难的时期-您能告诉我们他们看起来如何吗？
Kosuke：我们真的严重毁了我们的生命几次。 问题在于，随着Jenkins的成长，我们的项目开始吸引越来越多其他公司及其安全团队的关注，他们开始在Jenkins中寻找漏洞。 因此，来自外部的漏洞报告数量开始呈指数级增长。 有时，这使您感到有些恐惧，尤其是当您考虑到其中一些请求是在截止日期之前提出的，我们需要在截止日期之前关闭漏洞。 当涉及到社区创建的功能时，这尤其困难。 此外，在安装具有固定漏洞的更新时，用户有时会受到干扰。 我们正在努力防止这种情况的发生，因为否则用户将害怕安装安全更新，这是极不希望的。
Kirill：您是否有某个管理机构来决定将在发行版中包含哪些功能？ 请告诉我们如何做出此类决定，用户是否可以要求在发行版中包含某些功能？ 如果可以，那么谁将被赋予优先权-CouldBees或开源Jenkins的用户？ 最后，如果可能，请告诉我们您未来六个月到一年的计划。
Koske：这里有一个有趣的观点：CloudBees不拥有Jenkins，这是两个独立的项目，每个项目都有自己的决策结构。 CloudBees只是Jenkins的最大贡献者，许多CloudBees同时在社区中工作。 在过去的几年中，我们一直在尝试在詹金斯（Jenkins）创建更清晰的控制结构，这些结构完全可以满足您的要求。 为此，我们创建了詹金斯增强流程 ...
西里尔：很抱歉打扰-就像Java中一样，它缩写为JEP吗？
幸助：绝对。 显然，我们不是发明这个概念的，而是从Python，Java和其他社区借来的，因为它已经建立了。 这里的主要思想是，在功能的主要工作开始之前，社区应该能够表达意见并达成共识。 这正是CloudBees打算创建新功能时所做的，因此我们有机会根据收到的响应来更改路线。 这是我们能够在工作中实施的计划元素。 由于我们是一个开源项目，因此我们无法直接告诉其他项目参与者该做什么。 有时他们听我们的声音，有时不听。
至于我们未来六个月的计划，那么很可能我们将继续努力进行目前的许多努力，包括 JenkinsX。一些CloudBees员工和许多第三方贡献者都在为此工作。 我希望Configuration as Code将在插件开发人员中变得更加流行。 总的来说，我们已经为它创建了基础，因此现在我们需要配置一些插件，以便可以通过此系统正确连接它们。 最后，如果出现新的JEP，我们将对其进行处理。
Kirill：好吧，我们希望JEP不会获得专利：)作为Jenkins的作者，您想问一下-他的想法是Scripted Pipeline？
Kosuke：这是一个有趣的问题。 事实是，社区中的许多倡议往往没有达到临界水平，而仍处于试验阶段。 在开始研究Pipeline之前，人们已经在同一空间尝试做类似的事情，并且我们有机会熟悉这些尝试。 因此，我们实际上不是Pipeline的发明者。 其中的前身之一是Build Flow插件，该插件由CloudBees的一名员工在加入公司之前编写。 我认为“生态系统”一词非常成功-一切都像在真正的生态系统中一样发生，由某人创造的技术不断发展和变化。
Ruslan：您是否影响了脚本管道的实施？
Kosuke：是的，其原始版本。
Kirill：我们知道，有两种方式可以以静态和动态方式实现任何DSL。 为什么为脚本管道选择了动态方法？
Kosuke：恐怕我不太了解静态和动态方法的确切含义。
Kirill：在使用静态DSL的情况下，我们对代码在执行之前有一定的信心。 例如，对于Java中的DSL，您需要事先了解所有API和接口。 我们采用动态方法直接在执行时进行验证。 即使代码无效，机器仍会尝试执行它，如果有必要，它只会引发错误。 管道的声明版本允许您通过缩小构建脚本中的可变性来消除许多错误。
Kosuke：说实话，什么时候编译对我来说并不重要。 但是我可以谈谈设计脚本化管道时遵循的常规设置。 在某个阶段，自动化的复杂性极大地阻碍了许多Jenkins用户。 必须确保许多组件的正确交互。 编译代码，运行测试，然后您需要等待直到确认部署为止，依此类推。 , — Infrastructure as Code. , . Scripted Pipeline. , Pipeline , , Scripted Pipeline, . , , . Declarative Pipeline.
: , -, Jenkins, API . -, Scripted Pipeline, DSL. Declarative Pipeline , . — Pipeline Jenkins? , Jenkins.
: , , . , Pipeline, , , . Freestyle Job, Jenkins, . - , , Freestyle Job . , , . , Pipeline . - — , Shared Libraries. , . . , .
: Jenkins. Jenkins 2. API . Jenkins , , , , . , , ?
: , . , . Jenkins. , 800 , 1600 — , , . , . , . « » , , , , , . , , .
: , Java? 15-, 20- . Python 2 Python 3, ? ?
: , , , Java Python. , . , Jenkins , . , . , , . , , , . , , , Jenkins X. , , .
: , !
5-6 JPoint «Superpowers coming to your Jenkins» . , . JPoint ( , ).