ジェンキンスの作成者である川口幸介氏との素晴らしいインタビュー

Jenkinsを使用していますか？ 最も可能性が高いのは、これがこのクラスのこれまでで最も人気のあるプロジェクトだからです。 私は常に開発者の一人と話をして、いくつかの難しい質問をすることに興味がありました。 ここには、開発者だけでなく、ジェンキンス自身の作成者である川口耕介がいます。

ご存じのように、JenkinsはMITライセンスを持つオープンソースプロジェクトです。 ごく最近、FOSDEM会議が開催されました-フリーソフトウェアに捧げられた世界最大の会議です。 無料でオープン、世界中の何十人ものスピーカーがいます。 これは、Jenkinsの作成者であっても、そこで誰とでも会えることを意味します。 JUG.ruグループの友人や同僚の小さなグループと一緒に、私たちはそこに突然上陸し、ジェンキンスの作成者との良いインタビューを記録することができました。

そのため、当社の仮想スタジオであるKoske Kawaguchi （自己紹介と以下ですべてを詳細に説明します）、JUG.ruグループのRuslan Akhmetzyanov ARG89 、およびCIANの Kirill Tolkachev tolkkv （私たちの常任スピーカー、グルGroovy、Gradle、Spring、Netflixテクノロジースタック）デブリーフィングポッドキャストから知ることができます。

ルスラン：こんにちは。 まず、あなた自身とジェンキンスについて少し教えてください。

Kosuke：私の名前はKoskeです。主にJenkinsの作成者およびCloudBeesのCTOとして知られています。 Jenkinsは、開発者がソフトウェア配信プロセスのさまざまな段階を自動化するツールです。 私は個人的に、ジェンキンスを使用しているロシアのプログラマーを何人か知っています。他の人に会えてうれしいです。

キリル：私も自己紹介をします-私は開発者であり、モスクワジェンキンスエリアミートアップ（JAM）を開催しています。 私はJenkins、特にScripted / Declarative Pipelineを使用した経験が豊富です。 Jenkinsを開発している会社のCTOが何をしているのか教えてください。

Koske：私のチームの仕事の1つは、コミュニティとやり取りすることです。 当社の成功は、オープンソースプロジェクトの成功に大きく依存しています。 もう1つの重要なタスクは、オープンソースがどのように機能するかを社内の人々に教育することです。 一般に、会社とコミュニティの間には非常に興味深い関係があります。誰もがお互いから何かを学び、この相互作用に多くの注意を払っています。

また、テクニカルディレクターが実行する機能を尋ねました。 事実は、会社が成長するにつれてこの機能が進化したということです。 最初は、私はリードプログラマのようなもので、多くの技術的な仕事をしました。 しかし、会社が発展するにつれて、他の人々が徐々にこの仕事を始めました。 たとえば、別のチームがPipelineの処理を開始しました。 彼らが何をしているのかを知るために定期的に連絡を取り、時にはアドバイスをします。 しかし、彼らは設計と開発に関連するすべての決定を自分で行います。 一般に、私の役割のこの進化は非常に興味深いものであり、私は常に適応しなければなりません。

キリル：私があなたを正しく理解していれば、あなたの焦点は技術的な問題からコミュニティとの共同作業に変わりましたか？

Kosuke：はい、私がしていることの多くはこれに関連しています。 会社の創始者だけが言えることはあります。 したがって、私の活動の一部は、比較的言えば、旗を振って、コースの変更が必要なときに特定の方向にコミュニティを奨励することです。たとえば、昨年のように。 さらに、私たちとチームはジェンキンスのプロパガンダに取り組んでいます。私たちは私たちの目標が何であり、私たちが克服しようとしている困難を説明しています。 さらに、一般的な状況についてプレゼンテーションを行う必要がある場合、私は自信を深めます。 これが私の活動の概要です。

キリル：そして、何年前に技術的な仕事から組織的な仕事への移行が始まったのですか？ Jenkinsのストーリーと、プロジェクトの成長に伴ってあなたの役割がどのように変わったかを教えてください。

Kosuke：このプロジェクトは2004年に登場し、最初は夕方と週末に仕事をしました。つまり、一種の趣味でした。 しかし、プロジェクトは徐々に成長しました。 他の人が自分のアプリケーションを作成できるこのプラットフォームを作成するのにかなりの時間を費やしました。 やがて、エコシステムと開発者のコ​​ミュニティが出現しました。その一部はロシアからのものでした。たとえば、ジェンキンスの上に非常に興味深いサブシステムを書いたオレグ・ネナシェフ（Twitter： @oleg_nenashev ）です。 プロジェクトの人気が高まるにつれて、ユーザーとのより良い対話とトレーニングの必要性がより深刻になりました。 したがって、私はこれらのことをもっと始めました。 最後に、2010年ごろ、ジェンキンスは非常に人気を博したので、私はすべての時間を彼に捧げて会社を設立することにしました。 この瞬間から、会社の組織に関する作業がコミュニティとの作業に追加されました。 会社は成長していたので、私は自分自身に質問を始めました-私以外の誰も実行できない活動は何ですか？ 会社にもコミュニティにも、追加の責任を引き受けて喜んでいる有能な人がたくさんいます。 徐々に、彼らは私が自分自身でしたことの多くをし始めました。 概して、私たちの道は次のように見えました。

キリル：ありがとう。 今日、ジェンキンスは最も人気のあるCIシステムです。 そして、Jenkinsの商用バージョンは、他の商用CIシステムと比較してどれくらい一般的ですか？ たとえば、Travis Enterpriseを使用するのか、ローカルで動作するシステムを使用するのですか？

Kosuke：オープンソースのJenkinsは大きなプロジェクトであり、多くのユーザーがいます。 CloudBeesのスケールははるかに小さくなっています。 したがって、Jenkinsユーザーベースの1％でもCloudBeesユーザーに変換できた場合、これは非常に大きな結果になります。 オープンソース製品に基づくすべての企業は、この原則に基づいています。 もう1つの重要な質問は、当社の製品が解決すべき問題を抱える人々をどの程度支援できるかです。 テクニカルサポートの有効性を計算し、統計を正しく覚えていれば、一般に、サービスはそれらを満たします。

キリル：有料版を使っている人のことですか？ または、無料の人もいますか？

Kosuke：両方。 つまり、製品を購入するとサポートが提供されますが、独自のソフトウェアを使用せずに入手することもできます。

キリル：つまり、あなたは開発者とユーザー、オープンソースとコマーシャルの間の仲介者として行動しています。 製品ビジョンのタスクも持っていることを正しく理解していますか？

Kosuke：これは完全に真実ではありません。別の製品チームがあります。 私はユーザーの代表ではありませんが、私は常に多くの人々、ユーザーとのミーティングを行っています。つまり、私はコミュニティと連絡を取り合っています。 たとえば、会社の他の従業員用の「Summary with advanced」列があります。 これらの投稿で、私たちのユーザーがソフトウェアを書く方法と、それがジェンキンスにとって何を意味するかについて話します。 だから、製品チームが下す決定に影響を与えようとしています。

キリル：あなたは会社で重要な役割を果たしているようです。 さらに個人的な問題に移りましょう。 朝から夜まで話すことができるお気に入りのJenkins機能は何ですか？

Kosuke：まあ、朝から晩まで話すのは難しいでしょう。 私は今、組織がどのように機能するかにもっと興味を持っています-これは私の機能のためだと思います。 私が一人で働いていたとき、私の注意は個々の機能にずっと集中していました。 今はそうは思わないので、あなたの質問に答えるのは難しいです。

キリル：それから、おそらく、何年も前に実装された機能のうち、非常に誇りに思っているものを覚えていますか？

Kosuke：私たちが取り組んだ最近の重要な機能の1つについて話すことができます-それはユーザーにとってより興味深いものになると思います。 これは昨年のJenkins Configuration as Codeのプロジェクトです。 ユーザーがGUIでマウスをクリックするだけでJenkinsを管理することから、g​​itリポジトリの構成ファイルを使用して構成するように徐々に移行していることがわかりました。 Configuration as Codeプロジェクトの必要性は長い間感じられ、多くの一時的な松葉杖がこの機能を実行するために書かれました。 しかし、これらの取り組みはどれも十分なものではありませんでした。 最後に、この新しいプロジェクトに興味を持ったコミュニティの人々を集め、かなり大きく思慮深いツールを作成しました。 このプロジェクトの多くの側面は非常によく判明し、非常に幅広い人気を得ましたが、それは喜ばしいことです。

別のプロジェクト、Jenkins Xを思い出すことができます。これは、まったく異なる方向への進化です。 Kubernetesとの連携専用に作成されました。 この専門化のおかげで、スムーズな統合を実現し、統合と継続的な配信プロセスの接続によって生じる複雑さを隠すことができます。 その結果、私たちの意見では、最高のプラクティスを簡単に実装できます。 このプロジェクトのおかげで、Jenkinsは非常に標準的なアクションを実行し、すべての機能が必要な構成に多くの時間を費やしたくない多くの人々に利用可能になると思います。

Ruslan： Jenkinsを書くときにJenkinsを使用していますか？

Kosuke：はい、Jenkinsプロジェクトには独自のJenkinsがあります。 実際、各プラグインとコアでプルリクレビューを実行する大きなインスタンスがあります。 さらに、セキュリティ機能の開発は独立した独自のリポジトリで行われるため、セキュリティと脆弱性に関連する特に重要な作業のコピーがあります。 最後に、キーの署名やリリースに関連するものなど、さらに重要なタスクのための3番目のインスタンスがあります。 これら3つに加えて、24時間体制で別のコピーが私の家で機能します。

キリル：ジェンキンスXについてお話しました。ジェンキンス自体はスイスのナイフのようなもので、プラグインがあれば何でもできます。 しかし、ジェンキンスXは、それどころか、高度に専門化されており、Pipelineに存在し、Kubernetesと連携しています。 あなたとあなたの会社は、どのような技術戦略を遵守していますか？ JenkinsとJenkins Xのみをサポートしていますか？ または、これに加えて、Mesosクラスター用のJenkins XX、Cloud Foundry用のJenkins XXXなどがありますか？

Kosuke：コミュニティの反応に大きく依存すると思います。 普遍的なプラットフォームを持つことは確かに非常に重要です。 問題は、誰がこの柔軟性を正確に実装するかです。 現在、ユーザーは通常、直接アクセスできます。 これは、大企業で何か異常なことをしている場合に便利です。 しかし同時に、そのような柔軟性を必要としない多くの人々を知っています。 あなたがダイニングルームに来て、サンドイッチを作るように頼んだと想像してください。 7種類のパン、5種類のバター、4種類のチーズから選択できます。すべての材料を決める必要があります。 しかし、あなたはこのすべての選択を必要とせず、ただおいしいサンドイッチを必要とし、それを正しくする方法を見つけたくありません。 多くの人々がジェンキンスに対してこのような態度を持ち、すべての柔軟性が私たちの側に残ることを望んでいることを知っています。 Jenkins Xは、この方向への最初の重大なステップです。 このプロジェクトが引き続き成功する場合は、ファームウェアとIoT、モバイルプラットフォーム、または機械学習で同様のことを試してみたいと思います。 多くの垂直市場では、製品を迅速に生産できるツールが必要なだけだと思います。 あなたはロシアから来たので、JetBrainsについて知っている可能性が高いですか？

キリル：もちろん。

Kosuke：彼らは同様の戦略に従っていると思います。 これらは非常に柔軟な基盤を備えており、その上にさらに多くの特別なアドオンがあり、本質的に同じ要素が異なる方法で組み立てられます。 ユーザーはこれに感謝しており、私は彼らのアプローチが本当に好きです。

キリル：長年、私は多くのコミュニティで同じ写真を観察してきましたが、1つまたは別のプラグインを使用するようアドバイスすると、 https：//plugins.jenkins.ioが私を大いに助けてくれます。承認されたすべてのプラグインがあります。 問題は、人々がすべてのケースで1つの汎用ツールを使用しようとしていることです。これは特定のケースには適さないことがよくあります。 したがって、今では通常、パイプラインという1つのツールのみをお勧めします。これは、あらゆる状況に適した理想的なツールです。 しかし、新しい問題が発生します。 人々は、内部での配置方法を理解せずに、スクリプトパイプラインまたは宣言型パイプラインを使用しようとします。 インフラストラクチャに問題があります。ノード間の通信の確立、データの共有、エージェントとマスター間に異常なトラフィックが発生する、またはマスターのスケーリングに関する問題があります。 Jenkins Xのように、問題を解決する唯一の正しい方法を示すツールは、あなたの観点からはどちらが優れていますか？ または、Scripted Pipelineのような、あなたが何を念頭に置いていたのかを尋ねるツールですか？

suke介：あなたを正しく理解しているかどうかはわかりませんが、答えようとします。 日本語には「カタ」という言葉がありますが、正確に翻訳する方法がわかりません。 特に柔道で使用されます。 生徒が学ぶ厳密に定義された動きについて話します。たとえば、特定の打撃をそらすために特定の方法で手を上げることです。 私はこれを少しやったので、最も単純なものを知っています。 課題は、一連の単純な動き、ある種のパターン、またはベストプラクティスを記憶することです。 しかし、これはほんの始まりに過ぎません。 このベースを知っていれば、基本的な動き自体に違反することなく、状況がそれを必要とする場合、それを正しく残すことができます。 あなたはあなた自身のスペース、あなたの領土を勉強しますが、同時に、共通の基盤を知っていることはとにかくあなたを助けます。 あなたが彼女を知らない場合、あなたはいつも自分自身に尋ねます-私は正しいことをやっていますか？ あなたが書いたものが機能していても、あなたはまだ疑問を抱いているでしょう。

一般的に、あなたの質問はカタを思い出させました。 ジェンキンスについても同様の状況があると思います。 Jenkins Xがベースを提供します。さらに深く理解し始めたら、必要に応じてプラグインなどの助けを借りてそのままにしておくことができます。 もちろん、Jenkins XはKubernetesでより良い体験を提供するために柔軟性を犠牲にしなければなりません。 しかし、ジェンキンスXがベストプラクティスに向かってあなたを押し進めているという事実は、あなたが選択肢を奪われているという意味ではありません。 概して、これはどのソフトウェアに関しても当てはまります。 Jenkins Xでは、考え方に重要な変化があっただけです。 以前は、システムの重要な要素であるプラットフォームとプラグインのみを作成しました。それらを組み立てるのは、ユーザー次第です。 Jenkins Xでは、コミュニティは新しいアプローチに移行しました。私の意見では、これは非常に重要なステップです。

キリル：気にしない場合は、さらに2つの質問があります。 昨年、どの機能が最も苦労しましたか？ 各プロジェクトには困難な期間があります-あなたの場所でどのように見えたか教えてください。

Kosuke：私たちは人生を何度も真剣に台無しにしてきました。 問題は、ジェンキンスが成長するにつれて、ジェンキンスの穴を探し始めた他の企業とそのセキュリティチームから、私たちのプロジェクトがますます注目を集め始めたことです。 そのため、外部から寄せられる脆弱性レポートの数は指数関数的に増加し始めました。 特に、これらのリクエストの一部に期限があり、脆弱性をクローズする必要があると思われる場合、これから少し怖くなることがありました。 これは、コミュニティによって作成された機能に関しては特に困難でした。 また、脆弱性が修正されたアップデートをインストールすると、ユーザーが混乱することがあります。 そうしないと、ユーザーがセキュリティ更新プログラムをインストールすることを恐れるので、これは非常に望ましくないためです。

キリル：どの機能をリリースに含めるかを決定する運営機関がありますか？ そのような決定がどのように行われ、ユーザーがリリースにいくつかの機能を含めるように求めることができますか？ 可能であれば、CouldBeesまたはオープンソースのJenkinsのユーザーを優先するのは誰ですか？ 最後に、可能であれば、今後6か月から1年の計画について教えてください。

Koske：ここで興味深い点があります。CloudBeesはJenkinsを所有していません。これらは2つの別個のプロジェクトであり、それぞれ独自の意思決定構造を持っています。 CloudBeesは単にJenkinsの最大の貢献者であり、多くのCloudBeesが同時にコミュニティで働いています。 過去数年にわたって、私たちはジェンキンスでより明確な制御構造を作成しようとしてきました。 この目的のために、 Jenkins Enhancement Processを作成しました...

キリル：中断して申し訳ありません-Javaのように、JEPと略されますか？

Kosuke：もちろんです。 明らかに、私たちはこの概念を発明しませんでしたが、Python、Java、および他のいくつかのコミュニティからそれを借用しました。 ここでの主なアイデアは、機能に関する主要な作業を開始する前に、コミュニティが意見を表明してコンセンサスに到達できるようにすることです。 これは、CloudBeesが新しい機能を作成するときにまさに行うことなので、受け取った応答に応じてコースを変更する機会があります。 これは、作業で実装できた計画要素です。 私たちはオープンソースプロジェクトであるため、他のプロジェクト参加者に何をすべきかを直接伝えることはできません。 時々彼らは私たちの声を聞きますが、時々聞きません。

次の6か月の計画については、次のような現在の取り組みの多くに引き続き取り組みます。 JenkinsX。CloudBeesの一部の従業員と多くのサードパーティの貢献者がそれに取り組んでいます。 Configuration as Codeがプラグイン開発者の間でより一般的になることを願っています。 概して、その基礎はすでに作成されているので、このシステムを介して正しく接続できるように、いくつかのプラグインを構成する必要があります。 最後に、新しいJEPが発生した場合は、それらに取り組みます。

キリル：さて、JEPが特許を取得していないことを期待しましょう:)質問は、Jenkinsの著者であるあなたです-そのアイデアはScripted Pipelineでしたか？

Kosuke：これは興味深い質問です。 事実、コミュニティの多くのイニシアチブは、しばしばクリティカルマスに達せず、実験レベルのままです。 Pipelineの作業を開始する前に、同じ空間で人々はすでに似たようなことをしようとしていたので、これらの試みに慣れる機会がありました。 したがって、私たちは実際、パイプラインの発明者ではありませんでした。 これらの前任者の1つはBuild Flowプラグインで、CloudBeesの従業員の1人が会社に入社する前に作成しました。 「エコシステム」という用語は非常に成功していると思います。実際のエコシステムのようにすべてが実際に起こります。誰かが作成したテクノロジーは常に進化し変化しています。

Ruslan： Scripted Pipelineの実装に影響を与えましたか？

Kosuke：はい、元のバージョンでは。

キリル：知っているように、DSLを実装するには、静的と動的の2つの方法があります。 スクリプトパイプラインに動的なアプローチが選択されたのはなぜですか？

Kosuke：静的なアプローチと動的なアプローチがあなたが何を意味するのか、私にはよくわかりません。

キリル：静的DSLを使用すると、実行前のコードにある程度の自信があります。 たとえば、JavaのDSLを使用する場合、すべてのAPIとインターフェースを事前に知る必要があります。 動的なアプローチにより、実行時に検証を直接実行します。 コードが無効であっても、マシンはそれを実行しようとしますが、必要であればエラーをスローするだけです。 パイプラインの宣言バージョンでは、ビルドスクリプトのバリエーションを絞り込むことで多くのエラーを排除できます。

Kosuke：正直に言うと、コンパイルがいつ行われるかは正確には重要ではありません。 ただし、スクリプトパイプラインを設計するときに従った一般的な設定については説明できます。 ある段階では、かなりの数のJenkinsユーザーが自動化の複雑さによって大きく妨げられていました。 多くのコンポーネントの正しい相互作用を保証する必要がありました。 コードがコンパイルされ、テストが実行された後、展開が確認されるまで待機する必要があります。 また、すでにこのプロセスをコードの形で記述したいという要望がありました-ほぼ当時、コードが非常に人気があったためインフラストラクチャでした。 開発者は、誰もがプロジェクト管理システムのファイルを使用して管理できることを望んでいました。 これら2つのニーズのうち、Scripted Pipelineが生まれました。 ただし、その使用には重要な知識が必要であり、直観的ではなかったため、複雑なオーケストレーションを実装するためにスクリプトパイプラインを使用することを余儀なくされた人だけでなく、誰もがPipelineにアクセスできるようにしたいと考えました。 多くは、チューリングの完全性ではなく、明快さ、利便性、アクセシビリティを必要としていました。 これが、宣言的パイプラインの始まりです。

Kirill：今日、まずJenkinsプラグインがあります。これには通常、アノテーションとメタプログラミングを備えた静的APIがあります。 次に、追加のDSLをアナウンスするScripted Pipelineプラグインがあります。 宣言的パイプラインはほぼ同じことを行いますが、柔軟性が低くなります。 保守が簡単なもの-Pipelineまたは通常のJenkins用のプラグイン？ つまり、ジェンキンスからです。

Kosuke： 2つの異なる言語について話しているという考えを持ちたくありません。 これまでのところ、Pipelineの言語を見つけることができなかったようです。Pipelineは、単純なタスクには便利であるが、新しいユーザーにはアクセスできますが、柔軟性に優れています。 ジェンキンスが常に立っていたフリースタイルジョブは、もともと非常にうまく設計されていました。 複雑な操作を行う必要がある場合は、プラグインを作成し、Freestyle Jobでこれらのプラグイン間のスペースを埋めることができます。 それはバーのようなもので、チョコレートにナッツを注ぐことで得られます。 Pipelineでは、同様のソリューションを適用する必要があると思います。 私たちはすでにこの方向で何かをしている-例えば、共有ライブラリ機能。 それでも、この分野でやるべきことがまだたくさんあることは明らかです。 これについては、製品チームと開発者と長い間話し合ってきました。 私が彼らに影響を与えることができたことを願っています。

キリル：私の最後の質問は、ジェンキンスのライフサイクルについてです。 このプロジェクトの重要なマイルストーンはJenkins 2のリリースでした。その中の多くの機能とAPIには脆弱性がありました。 Jenkinsとそのプラグインのソースコードを見ると、非常に複雑なアーキテクチャがあり、かなりの数の問題があります。その人自身がプロジェクトの歴史の一部ではなかった場合、それを見つけるのは非常に困難です。 あなたの観点から、これが必要な場合、以前のバージョンと以前のアーキテクチャソリューションとの互換性が損なわれる可能性はありますか？

Kosuke：このプロジェクトでは、進化し続けることが重要です。 実際、あなたが成長するにつれて、特定の技術的負債が蓄積されます。 しかし、ジェンキンスの複雑さについてのあなたの評価には同意できません。 これは約800人が作成したプロジェクトで、1,600のプラグインがあります。これを念頭に置いて、非常にアクセスしやすいと思います。 状況は、あなたが説明するほど重大ではありません。 それでも、開発は本当に必要です。 昨年、私は比Shift的に言って旗を振って、セキュリティの場合を除いて、後方互換性の厳格な順守を含む、ユーザーによるレビューの初期約束のいくつかを促す「シフトギア」というタイトルの投稿を書きました。 このトピックがまだコミュニティで議論されることを願っていますが、今のところあまり多くは聞かれていません。

Ruslan：後方互換性ポリシーは、Javaが準拠しているものと似ていますか？ 結局、15年、さらには20年前のバージョンとの下位互換性があります。 または、Python 2とPython 3の状況に似たものがありますが、これらはまだ互いに機能しませんか？ 重要な機能を実装するために後方互換性を破る準備はできていますか？

Koske：正直なところ、JavaとPythonのどちらで互換性を観察するかという問題を提起するのは正しいとは思いません。 ユーザーが必要とするソフトウェアの種類について考える必要があります。 重大な問題の1つは、Jenkinsのプラグインが互いに独立して作成され、それらを連携させるのが不当に難しいことです。 この問題を解決する際にユーザーインスタンスを壊した場合、そのようなソリューションは必要ありません。 そして、結果としてより良く、より速く動作するシステムが得られれば、互換性違反が正当化されるかもしれません。 この点に関しては、言語開発者よりも柔軟性があると思います。互換性を厳しく守るとは約束していません。 Jenkins Xなどの新しいバージョンを作成することを考えています。最終結果が直接互換性の要件を満たしている限り、この問題についてはもう考えません。

Ruslan：素晴らしい、答えてくれてありがとう！

Koskeは、4月5〜6日に開催されるJPointカンファレンスでJenkinsに登場するSuperpowersに関するプレゼンテーションを行います 。 さらに、報告後にディスカッションエリアで彼とチャットすることもできます。 JPointの詳細とチケットの購入については、会議の公式Webサイトで確認できます（ 3月1日にチケットの価格が上昇することを忘れないでください）。