コードマッピングは、エラーとリポジトリ内のソースコードを結びつけるものです。エラーは、リポジトリのツリー構造とは異なる経路を持つことがあります。
エラーまでの正確なパスを決定するためには、コードマッピングが必要不可欠です。 このコードマッピングは、エラーまでのパスとリポジトリURLとの組み合わせによって成立します。
Sentryは、コードマッピングを使用して、課題の詳細ページでコンテキストと役立つデータを発行します。 例えば、以下のようなものです。
- Issue Detailsページから直接リポジトリ内のソースコードに移動することができます
- パスルールを定義するか、リポジトリにあるコードの所有者ファイルを使用することで、課題（Issue）をチームに割り当てることができます。
- エラーが発生した際、どのプログラムのどの行で起きたのか、また誰が触ったかを分析することができます。 変更を加えた人を担当者としてアサインし、問題を解決することができます。
これらの機能によって、実装中に起きたエラーなどの解決にかかる時間を短縮することができます。また、エラー原因のコードの所有者（修正者）を迅速に特定することができます。
これまでは、コードマッピングを設定するためのプロセスが複雑であることが課題視されてきました。そして、使いこなすことが難しいという課題を多くの開発者は以前から抱えてきました。そんな課題を解消するため、私たちは、そのプロセスを簡略化しました。
また、コードマッピングを自動化する機能も新たに追加しました。コードマッピングの自動化に成功したプロセスについては、これからご説明します。また、どのように役立つのか、そして今後のリリース計画についてもぜひご覧ください。
現在、自動コードマッピングは、GitHubインテグレーションをインストールしているお客様（Teamプラン以上）にのみ提供されています。 また、限られた言語でのみ利用可能です。
技術的な課題
スタックトレースに対してコードマッピングを自動生成する機能を、私たちは数日で開発しました。しかし、『大規模プロジェクトで実行させる』という機能が最も大きな課題として私たちを悩ませました。
Sentryは、数万を超える組織やプロジェクトにご利用いただいています。そして、彼らが書いた多くのコードが格納される数多くのリポジトリを保有しています。私たちは、1時間に何十万通りにも及ぶさまざまなイシュー（フィードバックやバグ）を受け取ります。
受け取ったイシューごとに処理を実行しなければなりませんが、この実行にかかるコストは高くつきます。ですので、より経済的でスケーラブル（拡張性がある）設計が必要になりました。
GitHubが設定した利用制限を守らなければならないため、GitHubのAPIをどのように使うかについて検討を積み重ねました。コードマッピングの導出は、GitHubのAPIを使用する唯一の機能ではありません。
そのため、キャッシュを効率的かつ適切に使う必要がありました。これは、他のSentryの機能（GitHubからコミットを取得するなど）の動作に影響を与えるため、とても重要な検討事項です。
GitHubのAPIを利用したコードマッピングの導出
スタックトレースに記載されているファイルを検索するためには、以下の2つの情報が必要です。
- ソースコードが存在するリポジトリ
- ファイルパスと一致させるために必要な変換工程
例えば、このスタックトレースフレーム sentry/shared_integrations/client/base.pyは、Github の以下のソースファイルに接続しているとします。src/sentry/shared_integrations/client/base.py
ソースコードがどこにあるのかを判断するためには、顧客の組織内のすべてのファイルとすべてのリポジトリのリストが必要です。リポジトリごとにファイルのツリーを作成するには、GitHub のふたつの API を使います。それは『組織リポジトリの一覧取得』APIと『ツリーの取得』API です。
1つ目の『組織リポジトリの一覧取得』APIは、その組織に関連するすべてのリポジトリをフェッチします。
次にこれを使用して、各リポジトリのツリーをフェッチします。
2つ目の『ツリーの取得』API は、与えられたリポジトリのすべてのディレクトリとファイルを表すリポジトリツリーを返します。このAPIは 1回の呼び出しで、あるリポジトリのすべてのファイルにアクセスできるため、非常に便利です。
レスポンスからツリー情報を抜き出し、ソースコードファイルでないものはすべて破棄します。エラーを発生させる可能性のあるファイルのみに絞り込むためです。
すべてのリポジトリのツリーを入手したら、スタックトレースがあるプロジェクトの課題を選んで処理します。すべてのリポジトリの中で一致するファイルを見つけるために、すべてのフレームファイルのパスを探します。
その際、リポジトリ内の任意の深さで正確なパスを検索します（例えば、src/foo/bar.py と project/src/foo/bar.py は sentry/foo/bar.py にマッチする、など）。
ここで、Githubの検索APIを使うこともできたのですが『1時間に25リクエストまで』というAPI利用制限がありました。
SentryはSentryをどのように使ったか
新機能の本番前に、私たち自身、Sentryを使って期待通りに動くかどうか確認することがよくあります。
コードマッピング機能で、PerformanceとDashboardプロダクトを使い、プロジェクトの分析機能を構築しました。
Issue Detailsページでは、プロジェクトに関連するCode Mappingがあるかどうかを判断するために、APIを使用しています。このAPIでは、以下の質問に答えるために様々なタグを追加しています。
- 派生したコードマッピングはスタックトレースと一致しましたか？
- コードマッピングから生成されたURLは、GitHubのソースファイルと一致しましたか？
どのトランザクションにコードマッピングがあるのかを判断するために、APIトランザクションにタグを付けました。このタグは、GitHubでファイルを見つけたかどうかを知るのに大変役立ちました。
これによって、ウィジェットを使ったダッシュボードを作成することができました。これらのダッシュボードには、派生したコードマッピングの成功率に関する情報が含まれています。
例えば、JavaScript由来のコードマッピングの場合、開発者が手動で定義したら60%程度の成功率です。しかしSentryを使った場合は、成功率が85%以上になります。
次の展開は？
派生したコードマッピングは、現在GitHubインテグレーションをインストールしたお客様にのみご利用いただけます。対応している言語はPython、JavaScript、Node、Rubyなどです。
派生コードマッピングは、組織がGitHub統合をインストールし、すべてのリポジトリへのアクセスを許可している場合にのみ機能します。そのため、アクセス権限がない場合は、リポジトリに対してコードマッピングを派生させることはできないためご注意ください。
今後は、さらに多くの言語に対応し、GitLabやBitBucketのようなソースコード管理ツールへの展開も視野に入れて開発に注力しています。
IchizokuはSentryと提携し、日本でSentry製品の導入支援、テクニカルサポート、ベストプラクティスの共有を行なっています。Ichizokuが提供するSentryの日本語サイトについてはこちらをご覧ください。またご導入についての相談はこちらのフォームからお気軽にお問い合わせください。
