OpenStack技術委員会の委員長でリリースマネージャーのThierry Carresへのインタビュー

Mirantisブログで、OpenStackプロジェクトの技術マネージャーとの一連のインタビューの4番目を紹介します。 私たちの目標は、技術専門家の幅広いコミュニティを教育し、人々がOpenStackプロジェクトにどのように貢献し、利益をもたらすかを理解できるようにすることです。 当然のことながら、Mirantisではなくインタビュー対象者の視点を以下に示します。



以下に、OpenStack Technical Committeeの会長でリリースマネージャーのThierry Carrezへのインタビューを示します。



Mirantis：自分について教えてください。



ティエリー・カレス：もちろん！ 今年、私は40歳になりました。 私は妻と2人の子供と一緒にフランスの中心部にある小さな村に住んでいます。



Q：とてもいいです。 世界中の開発者の間で文化の違いに気付いていますか？



A：はい、これらの違いは顕著であり、グローバルコミュニティの課題の1つは、それらを克服する単一の全体を形成することです。 さらに、専門的な経験の多様性から生じる違いがあるため、地理的な問題だけではありません。



Q：例を挙げていただけますか？ たとえば、東ヨーロッパでは、コードレビューは批判または不承認として認識されていますが、実際には、そのようなレビューは開発者がコードを改善するのを支援することを目的としています。



A：たとえば、日本の「-1」コードスコアの認識にも問題があります。 また、大企業の開発者は、コードの変更の隣に、名前が明示的かつ絶えず示されているのを恐れています。 これにより、開発者コミュニティに完全に参加できなくなります。 オープンソースプロジェクトやスタートアップで始めた開発者にとって、透明性は問題ではなく、チャンスです。



Q：OpenStackでの仕事の歴史は何ですか？ なぜプロジェクトに参加することに興味がありますか？



A：私は、CanonicalのUbuntu Serverの技術プロジェクトマネージャーであり、Ubuntu Enterprise Cloud製品に取り組んでいました。 OpenStackを作成するとき、私はRackspaceの同僚と一緒にプロジェクトの整理を手伝い、リリース管理機能を実行しました。



「オープンイノベーション」の原則に基づいた開発モデルの推進に特に興味があります。つまり、業界全体の開発者がOpenStackの設計と開発に協力できるスムーズな技術作業環境を作成することです。 このプロジェクトでの私の目標は、このモデルを確実に順守し、そのサポートと開発に貢献し、その成功を証明することです。



Q：企業は「オープンイノベーション」開発モデルをどのように採用していますか？



A：オープンイノベーションの原則に取り組む場合、企業はプロジェクトに取り組むために開発者を雇いますが、プロジェクト自体を管理することはありません。 これらは、暗黙のうちに、プロジェクト内の開発者の優先順位と関心を仲介者として導きます。 しかし、一般的に、すべてのプロジェクト参加者とその中のリーダーがプロセスを自分で制御します。 企業は、影響力のためにコントロールを放棄しなければならない状況を受け入れることを余儀なくされています。



Q：多くの企業がOpenStackを使用していますが、経験を交換していません。 変更する必要がありますか？ もしそうなら、どのように？ または、これはオープンソースプロジェクトでの一般的な慣行ですか？



A：Apacheライセンスにより、企業はコードを受け取り、貢献することはできません。したがって、これは間違いなく一般的な慣行です。 ただし、これは良い考えではありません。 プロジェクトに投資することなく、技術面への影響を大幅に削減できます。 また、新しいコードや追加機能がコードレシピに違反するリスクもあります。 結局のところ、それは価値がありません。



Q：OpenStackの構築の原則は誰が決定しますか？決定はどのように行われますか？



A：機能開発プロセスは非常にオープンです。 誰でも変更を提案できます。変更は、コードをチェックする主な従業員がレビューのために送信します。 そうは言っても（特に破壊的な機能について）、設計と開発のメーリングリストに参加して開発セミナーに参加すると、テストが成功する可能性が高くなります。 このようにして、コミュニティは、あまりにも手間がかかる前に機能を承認できます。 意思決定プロセスは、プロジェクトの開発者間の最小限の労力で達成される妥協案です。 プロジェクトごとに、最終決定を下すことができる技術プロジェクトマネージャーが選出されますが、これは非常にまれなケースで必要です。



Q：技術委員会の委員長およびリリースマネージャーとしてのあなたの責任は何ですか？



A：技術委員会は、OpenStackの技術的な能力主義の最終的な表現です。 委員会のメンバーは、さまざまなプロジェクトの参加者によって選出されます。 その役割は、OpenStackでの開発が提案されている新しいプロジェクトを検討し、プロジェクト間の潜在的な問題を解決することです。 委員会の委員長として、私は委員会によって提出された問題を追跡し、IRCミーティングを開始し、これらのミーティングの結果を他のコミュニティに広める責任があります。



リリース管理には2つの側面があります。 最初の（明らかに）さまざまなOpenStackプロジェクトのリリースを調整することですが、自動化ツールを使用すると、非常に簡単です。 リリース管理作業の大部分は、6か月のリリースサイクルの管理、行われていることの追跡、およびプロジェクト間の干渉の防止の試行で構成されます。



Q：OpenStackに興味がある人は、IRCの使用についてコメントすることがよくあります。 「なぜIRCを使用しているのですか？ これは古くなっています。 他のみんなと同じようにTwitterを使ってみませんか？」



A：うーん。 誰もが独自のメッセージングプラットフォームに縛られることを望んでいるわけではありません！ 私は過去20年間IRCを使用していますが、これは迅速なオンラインディスカッションや会議の開催に最適なツールだと思います。 特定のトピック専用のチャネルと、個々のチームのチャネルがあります。 これはコミュニケーションのための公共空間であり、24時間体制で機能します。 アクションのログを保持します。つまり、データは消えません。 プロキシを使用して接続することもできます。 これは私たちのオープンソースプロジェクトに参加している開発者の間で非常に広まっており、私たちのほとんどはそれらをOpenStackの外部で使用しています。



Q：あなたは6ヶ月のリリースサイクルについて言及しました。 それらの価値は何ですか？



A：リリースサイクルの最も明白な価値は、リリースを促進することです。 これにより、機能の開発からリリースまでの重大なエラーのバグ修正に焦点を移し、リリースの品質を向上させることができます。 私にとって、リリースサイクルの最大の価値は、努力のリズム、特定のパルスの作成です。これは、同じプロジェクトでの作業における団結という点で、仮想コミュニティおよびグローバルコミュニティにとって非常に重要です。



Q：ブレーンストーミングから実装と統合まで、OpenStackのリリースサイクルを説明できますか？



A：開発ワークショップから始まります。このワークショップでは、次のサイクルで特定のプロジェクトに取り組みたい開発者がアイデアを提示し、他の開発者と議論します。 その後、実装が開始されます。これは、プロジェクトの作業を分割するために、人為的に3つの短い「ステージ」に分割されます。



開発の第3段階の後、機能フリーズモードに切り替えます。このモードでは、リリース前に重大なエラーのリストを修正することに焦点が移ります。 すべての重大なエラーが修正された後、リリース候補を作成します。 リリースにとって重大なエラーが見つからない場合（この場合、修正して新しいリリース候補を再構築できます）、リリース時にすべての候補が集まり、OpenStackプロジェクトの最終的な統合リリースを作成します。



Q：OpenStackのリリースの頻度は何によって決まりますか？



A：メインブランチを常に起動できるようにしようとしています。 リリースは実際には単なる特定の時点であり、特別なケースとしてマークするリポジトリ内のタグです。 リリースサイクルは、重大なリグレッションが「リリース」に侵入するリスクを軽減するように設計されているため、「リリース」はランダムランダムコード修正よりもリスクが低くなります。 興味深いのは次のとおりです。安定したブランチを維持し、重大なバグ修正と脆弱性修正のためのパッチを適用します。これらの安定したブランチはリリースポイントから作成されます。



現在のOpenStackのリリース頻度は、反復を加速したいという要望、開発者セミナーを実施する能力、機能を凍結した後にドキュメントを更新する必要性、凍結機能の頻度、安定したブランチをサポートするリソースの可用性の間の妥協点です。



Q：3か月のリリースサイクルの長所と短所は何ですか？



A：OpenStackの開発の開始時に、3か月の開発サイクルがあったことを覚えているかもしれません。 現在、通常は、機能の追加を停止してから作業候補リリースを受け取るまでに4週間が経過しています。 6か月のリリースサイクルでは、機能を1か月間凍結することができます。 3か月のリリースサイクルでは、この期間は短くなります。 3か月ごとにリリースすると、安定したブランチの数が半分になります。 したがって、サイクルの残りの期間（凍結機能の期間中ではない）で重大なエラーを修正する人が増え、安定したブランチとセキュリティ更新プログラムを維持する人が増えると、3か月のサイクルに確実に進むことができます。 各サイクルの始めに開発者セミナーを開催したいので（これはより良い結果を達成するのに役立つと思います）、開発者に2倍のイベントを支払うようファンドに納得させる必要があると思います！



Q：セミナーをスキップすることを余儀なくされた場合、または開発者セミナーへの旅行に余裕がない場合、開発者はどのように参加できますか？



A：Developer Workshopへの参加は、OpenStackにコードを追加するための必要条件ではありません。 ディスカッションは、メーリングリストまたはコード検証システムで実施できます。 開発者ワークショップは、ブレーンストーミングと実装の段階を迅速に通過し、実際の個人的な議論から早期のフィードバックを受け取るための便利な方法です。



Q：OpenStackコミュニティは、Ubuntuコミュニティにオンラインのみの開発者ワークショップをフォローすることを考えていますか？ これはOpenStackで機能しますか？



A：Ubuntu開発者ワークショップは基本的にフィードバック演習に変わり、主要な開発者が今後数か月の作業計画を提示します。 これらの目的のために、仮想環境は理想的であり、多くのお金を節約します。 OpenStack開発者ワークショップは、他の何かに使用されます。今後6か月間、グローバルおよび仮想開発者コミュニティを動機付け、開発アイデアについてブレーンストーミングを行い、異なる開発グループと話し合うことで作業の重複を減らします。 しかし、参加者の個人的なコミュニケーションを離れる最も重要な理由は、コミュニティの常識の維持です。 6か月間の仮想コミュニケーションで蓄積された競合を解決するには、個人的な会議が必要です。



Q：最近、継続的インテグレーションのテクニカルプロジェクトマネージャーであるMonty Taylorにインタビューしました。 OpenStackにとって継続的インテグレーションが非常に重要だと思うのはなぜですか？



A：継続的な統合により、メインブランチのコンテンツが機能し、リグレッションが含まれていないことを信頼できます。 OpenStackは複雑なデバイスであり、誤って壊してしまう可能性があります。 以前は、リリースをローカルに展開し、基本的な機能が壊れていないことを確認するために定期的にいくつかの手動テストを実行しました。



今日のインフラストラクチャでは、以前に実行したテストの数千倍以上のテストが実行され、提案されたすべての変更についても同様です。 継続的な統合により、私は静かに眠ることができます。 彼女がいなければ、私たちは今いる場所にいないでしょう。



Q：開発プロセスにはまだ自動化されていないが、将来は自動化される領域がありますか？



A：いいえ、改善の余地はありますが、すべての側面が自動化されています。 一部のプロジェクトでは、より多くの統合テストを使用する場合があります。 継続的な統合はテストと同じくらい良好です。



Q：OpenStackのコードの作成に関与したい開発者は、プロジェクトに何をもたらす必要がありますか？



A：ユーモアのセンス。 OpenStack開発者は、優れた人々のコミュニティであり、常にこのようになることを望んでいます！



Q：初心者-貢献したい開発者、およびOpenStackを中心にビジネスを構築したい企業に、どのようなアドバイスをしますか？



A：OpenStackプロジェクトは、私たちが作成したものです。 参加して、後悔しないでください！



Q：ティエリー、ありがとう！



A：ありがとう！