Elasticでプルリクエストを処理する方法
Elasticで作業を完了させるには相互協力が必要です。
Elasticのエンジニアは、新しい製品や機能を開発するために1日24時間体制で（会社組織が世界中に分散している企業なので、文字どおりの意味で）働いています。その仕事は膨大であり、細部へのきめ細かな注意が要求されます。しかし、どれだけ注意しても私たちは完璧ではなく、Elasticのような複雑なオープンソースプロジェクトの場合は、より良くするためにコミュニティからの支援が必要です。
ブログ「Solving the Small but Important Issues with Fix-It Fridays（小さいが重要な問題をFix-It Fridayで解決）」では、コミュニティの貢献がElasticの製品開発における継続的な成功の促進要因であることを説明しました。オープンソースプロジェクトの優れた利点の1つは、開発者の大規模なコミュニティがあることです。開発者たちはバグを注意して見ており、 それらを修正する機会を待ち望んでいます。
コミュニティの新しいメンバーが初めてプルリクエスト（PR）を送信するとき、またはそのプロセスについて質問があるときは、このブログが役に立ちます。ここでは、Elasticでのプルリクエストの概要、Elasticがリクエストを受信したときのプロセス、リクエスト内容が実装されなくなる可能性がある一般的なミスの回避方法について説明します。
プルリクエストの送信方法
PRを送信する前に、GitHubリポジトリでフォークを作成し、コードを変更する必要があります。これは通常、自身のGitHubアカウントでソースリポジトリのコピーを作成して実行します。Elasticのすべてのプロジェクトは、そのプロジェクト自身のGitHubリポジトリにあります。Elasticのリポジトリの完全なリストについては、GitHubのElastic組織ページをご覧ください。
リポジトリのフォークを作成し、コードを変更したら、変更の提案を製品リポジトリのmasterブランチにプッシュするPRを作成するかどうかを尋ねられます。たとえば、下記のElasticsearchリポジトリで見ていきましょう。シンプルにするために、このブログではElasticsearchリポジトリを例として説明します。
［New pull request］をクリックすると、プルリクエストテンプレートが表示されます。
このテンプレートは、PRが最初のレビューを受けられるようにするためのガイダンスとなります。各製品でそれぞれ一連の基準およびドキュメントが決められているため、必ずすべて読んでください。このテンプレートは、PRが最初のレビューを受けられるようにするためのガイダンスを提供します。
送信時には、次のようなよくあるミスに気を付けてください。
- 送信内容の重複 - まず、オープンされたPRの中で、自分が修正しようとしているバグに関するものがないか検索します。重複しているものは通常、拒否されます。
- テストが含まれていない - コード変更を含むPRには、新しいコードの振る舞いを説明するテストを含める必要があります。このテストでは、PRで修正しようとしている問題を再現できることが理想的です。つまり、そのコードがないとテストが失敗し、コードを適用すると成功するという具合です。
- Masterブランチのみ - コードを変更するためのPRはすべて、関連ディレクトリのmasterブランチに対するものであることを確認してください。
テンプレートに記載されているすべての要件を完了したら、［Create Pull Requests］をクリックします。その後はElastic側での作業となります。
トリアージとラベリング
Elastic側の最初のステップは、そのPRが上記の適切なリクエストとしての要件を満たしているか確認することです。満たしている場合は、さらなる調査の担当者に回すためにそのPRにラベル付けします。ラベルには、たとえば>bug、>featureなどが考えられます。ラベルが付けられたプルリクエストは、適切なサブチームに割り当てられます。そこから先は、該当分野の担当チームがそのリクエストの責任者となります。
プロセスの開始
PRにラベルが付けられると、Elasticの開発者の1人がピックアップします。リクエスト者にできるだけ早く通知するように努めていますが、PRの送信後は少しお待ちいただくようお願いしています。絶え間なく届く各リクエストに適切に対応するには、そのリクエストのレベルや詳細に応じて時間がかかる場合があります。
ドキュメントに関する変更の送信
注：Elasticのドキュメントを修正する、またはドキュメントの変更をリクエストするPRも多数受け取っています。このプロセスはコードの変更よりもシンプルです。必要なのはElasticのドキュメントページの［edit］をクリックして変更を加え、リクエストを送信するだけです。プロジェクトのフォークや、テストの必要はありません。ElasticではこれらのPRに「>doc」とラベル付けし、できるだけ早く対応します。
往々にしてさらに作業が必要
PRは往々にして、マージする準備を整えるために、適応させることが必要です。この時点でPRは、ディスカッションを行うためのコラボレーションスペースとなります。つまり、変更が提案され、さらにコミットが実行されます。
このレビュープロセスの間、PRに対してテストが実行され、それらの結果はGitHubで見ることができます。PRに記載された変更を適用してテストした場合、送信されたテストでは機能していたとしても、失敗することがあります。ただし、これで終わるわけではありません。Elasticは、PRを送信していただいた方がそのコードを修正し、テストに成功するように支援します。
このステージでは、コードおよび命名規則とともに、コードのスタイルも確認します。プルリクエストを送信したユーザーには、そのコードに対して1回以上のレビューラウンドが実施されることを確約します。コードが常に完璧であることはなく（私たちのコードもそうです）、送信時点でマージの準備が整っていることはまずありません。マージに向けてコラボレーションが必要です。
PRをコミットするまでの期間
PRへの対応期間はそれぞれ異なります。1行のシンプルなコードの場合はすぐに対処できる場合もありますが、複雑なコード変更の場合は複数のレビューラウンドが必要になります。ご自身のPRが、一切のアクションがないまま長期間放置されていると思われる場合は、リマインダーとしてチケットを切り、そのPRがまだアクティブであることをお知らせください。
コードのコミット
すべてが完了して準備が整ったら、レビュアーがコメントを付け、承認アクションを実行します。コメントは、たとえばLGTM（「Looks Good To Me （問題ないと判断）」）のようなものになるでしょう。PRが承認されると、Elasticの開発者がそのプルリクエストをmasterブランチにマージし、必要に応じてその変更をdevelopmentブランチに知らせます。
簡潔に説明すると、以上のようになります。もちろん、プルリクストはそれぞれ異なるため、そのプロセスはシンプルな場合も、難しい場合もあります。プロセスを詳細に知る唯一の方法は、真剣に取り組んで徹底的に追求することです。
これで、初めてのPRの送信準備は整いましたか？GitHubで利用可能なElasticリポジトリに目を通し、ガイドラインを把握して実行してみましょう。プロセスに関してさらに質問がある場合は、Elasticのディスカッションフォーラムにアクセスし、トピックを作成していただければ喜んで支援いたします。