Firefox/Geckoの開発環境 —20年続いているOSSプロジェクトの現在—

Firefox/Geckoの開発環境 —20年続いているOSSプロジェクトの現在—

1. 1. Firefox/Gecko の開発環境 20年続いているOSSプロジェクト の現在—
2. 2. 喋る人 ✓なまえ: 中野雅之 ✓株式会社 Birchill 所属 ✓ Mozillaからの業務の委託を受けてFirefoxのGeckoエンジンを開発 ✓担当モジュール ✓ Event Handling (共同モジュールオーナー) ✓ Editor (モジュールオーナー) ✓ Global Key Bindings (モジュールオーナー) ✓ 他、キーボード絡みのトラブル全般、デスクトップ版のIME関連バグ全 般 ✓2000年頃からボランティアでバグ報告や報告内容の検証 (この 頃は大阪市内の会社でSIer) ✓2004年よりMozilla Japanでフルタイマとしてパッチを書き始める ✓2017年よりMozillaのcontractorとしてパッチを書き続ける ✓2019年より現職 Mozillaの方から来ただけなのでオフィシャルな内容で はありません
3. 3. Mozillaのブラウザ ◆Firefox ◆デスクトップ向け ◆Windows版、macOS版、Linux (GTK3)版 ◆Geckoエンジン ◆UIもXUL/CSS/JSによるWebアプリケーションの一種 ◆Firefox for Android (Fennec) ◆Android端末向け ◆開発終了 ◆Geckoエンジン ◆UIはAndroidネイティブ ◆来年までGecko 68.0.xでセキュリティの修正は行われる ◆Firefox Preview (Fenix) ◆Android端末向け ◆Fennecをリプレースするために鋭意開発中 ◆GeckoView ◆UIはKotlinで開発 ◆GeckoViewはWebViewライクなAndroidコンポーネントでアプリがテスト済みの バージョンを取り込んで配布できる ◆マルチプロセス化されてびっくりするほど高速化
4. 4. ◆Firefox for iOS ◆iPhone/iPad用 ◆App Storeの制約によりGeckoではなくWebKit ◆拡張機能が使えない ◆Firefox Focus ◆Android版、iOS版 ◆Android版はGeckoView、iOS版はWebKit ◆プライバシー保護を主目的に開発されたブラウザ Mozillaのブラウザ
5. 5. Mozillaの ソースコード管理 ⚫Geckoエンジンと、Firefox(Fennec含む) ⚫ Mercurialで管理されている ⚫ mozilla-central (開発用trunk、Nightlyチャンネル) ⚫ mozilla-beta (Betaチャンネル) ⚫ mozilla-release (Releaseチャンネル) ⚫ mozilla-esrNN (ESRブランチ、mozilla-esr68) ⚫ これら以外にもcomm-central等、ThunderbirdやSeaMonkey用のツリーも存在している ⚫ Gitでもアクセスできるようにクローンされ続けている ⚫ 詳細はMDN参照 ⚫ GitでMercurialプロトコルを使えるgit-cinnabarを使って、gitで開発している 人も多い ⚫ Mozillaのglandiumさん作 ⚫ Gitではなく、Mercurialを使っている理由 ⚫ MozillaがCVSから移行を検討している段階ではGitがWindowsをサポートしていなかったらし い ⚫Firefox Preview(Fenix)、Firefox for iOS、Firefox Focus ⚫ Gitで管理されている ⚫ Firefox Preview (Fenix) ⚫ Firefox for iOS ⚫ Firefox Focus for Android ⚫ Firefox Focus for iOS ⚫ 他にも新しいプロジェクトはだいたいGit ⚫ そしてこれらのプロジェクトではGitHubを中心に開発が行われている
6. 6. このスライドでは、 GitHubを利用していない GeckoエンジンとFirefoxの開発環境を 説明していきます。
7. 7. Mozillaの 修正の流れ 1. Bugzillaにバグを報告する 2. ローカルにcloneした”mozilla-central”上でパッチを 書く 3. パッチをPhabricatorに提出 4. レビュアがDifferentialを使ってレビュー 5. Landoからパッチを”autoland”リポジトリにコミットす る 6. 各修正ごとに自動テストが全て実行される 7. 日に二回、”mozilla-central”にマージされ、Nightlyビ ルドが作成される 8. Bugzillaの”バグ”が”RESOLVED FIXED”とマークされ、 閉じられる
8. 8. Mozillaの 修正の流れ 1. Bugzillaにバグを報告する 2. ローカルにcloneした”mozilla-central”上でパッチを 書く 3. パッチをPhabricatorに提出 4. レビュアがDifferentialを使ってレビュー 5. Landoからパッチを”autoland”リポジトリにコミットす る 6. 各修正ごとに自動テストが全て実行される 7. 日に二回、”mozilla-central”にマージされ、Nightlyビ ルドが作成される 8. Bugzillaの”バグ”が”RESOLVED FIXED”とマークされ、 閉じられる
9. 9. Mozilla製品のBTS ⚫Bugzilla ⚫Netscape社が社内で使っていたシステムが元になってい る ⚫mozilla.orgが1998年に登場する際にオープンソースで公 開したBTS ⚫現在でも全てのMozilla製品のバグ報告を受け付けるため のツールとして開発・改良が続いている
10. 10. Bugzillaのホーム とてもシンプルなホーム画面。 「とりあえず検索」というUI。
11. 11. Bugzillaの”バグ” Webが一般に広がりだしたころの BBS(掲示板)にバグのステータスを 追加したようなUI。 複雑なステータス部分(上半分)は 普段は隠されていてユーザへの圧 迫感をできるだけ減らしている。
12. 12. Bugzillaの バグのステータス ステータスを編集するために展開 すると非常に多項目(これでもまだ 一部は隠れている)。 開発者自身やマネージメントに都 合が良いようにフィールドが多数存 在している。
13. 13. Bugzillaの バグの依存関係 このスクリーンショットは、 ”beforeinput”イベントを新規で追 加するためにどれだけのバグがこ れまでに修正されたのか、どのよう なバグをさらに修正していかないと いけないのかを把握しやすい。
14. 14. Bugzillaの ”Advanced Search” バグのステータスが複雑な分、検 索項目も膨大だが、日常的に全て を使うわけではない。 この例では2019年8月1日以降に 報告された標準以上の重要度を持 つ”DOM Events”に関わるバグを検 索できる。 プラットフォームや、報告者、担当 者といった項目でも検索可能。
15. 15. Bugzillaの 検索結果 検索結果はこのようなリスト形式で 表示される。 表示される項目はユーザアカウン トごとにカスタマイズ可能なので、 開発者にもマネージャにも使いや すい。
16. 16. Bugzillaの バグ報告画面 まずはプロダクトを選択することで 入力フォームを簡素化している。
17. 17. Bugzillaの バグ報告時の 詳細入力画面 開発者自身がより細かいステータ ス情報を入力するための”Show Advanced Fields”ボタンも画面上部 に見られる。 コメントは最近、マークダウンに対 応。 単にBugzillaのアカウントを登録し ただけだとより簡単なウィザード形 式の画面を利用することになる。
18. 18. Bugzillaのまとめ ✓開発者、マネージャ等、それぞれの作業に対応するた めに必要なステータス情報が多数存在している ✓各人の作業に関係ない情報はできるだけ隠してしまう ことで可能な限りUIをシンプルにしている ✓さらに新規Bugzillaユーザのためにより簡素なUIも用 意されている ✓ダッシュボードとemail、どちらでも自分の進捗をマ ネージメント可能(emailの場合、各項目の情報が独自 ヘッダで追加されているのでMUAによるフィルタリング が容易)
19. 19. Mozillaの 修正の流れ 1. Bugzillaにバグを報告する 2. ローカルにcloneした”mozilla-central”上でパッチを 書く 3. パッチをPhabricatorに提出 4. レビュアがDifferentialを使ってレビュー 5. Landoからパッチを”autoland”リポジトリにコミットす る 6. 各修正ごとに自動テストが全て実行される 7. 日に二回、”mozilla-central”にマージされ、Nightlyビ ルドが作成される 8. Bugzillaの”バグ”が”RESOLVED FIXED”とマークされ、 閉じられる
20. 20. Mozillaの ソースコードを読む 1. 修正しないといけない場所を探さなくてはいけない 2. もちろん、ローカルにコピーしたソースコードを開い て読んでいくこともありますが…… 3. Searchfoxというツールでmozilla-central等、一部の Gitでも提供されているソースコードをブラウザから 参照可能 1. インスタンスはsearchfox.org 2. アプリ自体はGitHubで公開
21. 21. Searchfox.orgで mozilla-central フォルダやファイルの一覧が表示 される。 上部のフィールドから検索可能。
22. 22. Searchfox.orgで dom::KeyboardEvent を検索 部分一致するクラスやメソッドをイ ンデックスから探してきてくれる。 インデックスに存在しないものであ ればプレーンテキストとして探して きてくれる。
23. 23. KeyboardEvent. keyCodeの実装を 調べたい場合 ソースコード内のメソッド名をクリッ クするとコンテキストメニューに”Go to definition of …”と出てきて、ワン クリックでジャンプできる。
24. 24. KeyboardEvent. keyCodeの実装を 調べたい場合 複数の行をハイライトしておい て、”Permalink”から、そのリビジョ ンへの永続URLが得られるので Bugzilla等でのディスカッションにも 便利(何年後にそのURLを参照して も、リビジョンが指定されているの でディスカッション当時のソース コードが参照できる)
25. 25. KeyboardEvent:: KeyCodeの callerを調べたい ソースコード内のメソッド名をクリッ クするとコンテキストメニュー に”Search for function …”と出てき て、ワンクリックで検索できる。 変数(クラスのメンバ変数含む)につ いても参照箇所、設定箇所を検索 できる。
26. 26. KeyboardEvent:: KeyCodeのcaller を調べたい場合 インデックスを元に検索してくれるので、 別のクラスに`KeyCode`という名前のメソッ ドがあっても検索結果には出ない(例えば `Init`というメソッドを調べる時とかに便利)。 呼び出し元それぞれのメソッド名をクリッ クするとその呼び出し元が検索できる(呼 び出されるスタックの一覧は得られないも のの全ての呼び出し元を手軽に追いかけ られる)。 ただし、JavaScriptでは(`this.`以外では)残 念ながら同名のfunctionが全て検索結果 に出てしまう。
27. 27. ある行が何故、 いつ、追加された のか 行頭にマウスカーソルを移動させ ると直近のバグへのリンク、その際 のdiff、それが変更された際のリビ ジョン、それが変更される直前のリ ビジョンを表示させるポップアップ が表示される。
28. 28. Searchfoxの 仕組み 公式サイトの図が分かりやすい。 言語ごとにコンパイル・分析を行っ てリンクを生成していくので単純な テキスト検索では検索が難しい場 合には特に便利。
29. 29. Mozillaのソース コードをビルドす る ⚫ビルド環境の構築方法はMDNで詳しく書かれている ⚫LinuxとmacOSではbootstrap.pyというファイルをダウンロー ドして実行するだけ(macOSではXcodeのインストールが先 に必要) ⚫WindowsではVisual StudioとWindows 10 SDKのインストー ルが必要 ⚫ MSYS、Python等、ビルドに必要なツールを一式そろえたパッケージを MozillaBuildとして用意しており、GUIでインストールできる ⚫ソースコードをMercurialでcloneした後に`./mach bootstrap`コマンドを走らせるだけで、最新のclangやrust等 をセットアップしてくれる ⚫ FirefoxはWindowsでもclangでビルドされている ⚫ これらのアップデートが必要になった場合にもこのコマンドで行える ⚫ これにより、各開発者が同じバージョンのコンパイラを使って開発が行え る体制になっている ⚫あとは`./mach build`するだけ
30. 30. Mozillaの 自動テストを 走らせる ✓コマンドで自動テストを走らせることも可能 ➢全てのテストを走らせるには何十時間も必要 ➢全てのプラットフォームで長時間テストを走らせるのは事 実上不可能 ➢そもそもテスト環境依存の微妙なテストも多い ➢ OSのバージョン依存 ➢ DPI依存 ➢ インストールされている何か依存 ➢ インストールされていない何か依存 ➢ランダムに失敗するテストもあってさらに大変 ➢パフォーマンステストなんてさらに環境作りが無理 ✓そうだ、クラウドにあるリファレンス環境で走らせよう ➢Try Server
31. 31. MozillaのTry Server 1. コマンドで簡単にchooserを起動できる ➢ ./mach try chooser → ブラウザにUIが表示される
32. 32. Try Server上の ジョブの管理 treeherderというツールでブラウザから管 理できる。 失敗したら、オレンジ、もしくは赤で表示さ れ、その詳細やデバッグビルドであればコ ンソールへの出力結果もログファイルで 確認できる。 ランダムな失敗としてBugzillaに登録され ているものが失敗の候補として表示もさ れる。 この例では取り消し線が引かれた解決済 みのバグしか出てこないので自分のバグ だと分かる。
33. 33. Try Serverの構成 ⚫各環境はDockerのイメージ ⚫Taskclusterというツールでジョブ管理 ⚫これもMozillaのOSSプロダクト ⚫Treeherder ⚫これもMozillaのOSSプロダクト ⚫もちろん、TryServer上の成果物は順次削除されていく ➢ビルドされたバイナリはWebサーバに14日間だけ ➢Treeherderの情報は4ヵ月
34. 34. Mozillaの 修正の流れ 1. Bugzillaにバグを報告する 2. ローカルにcloneした”mozilla-central”上でパッチを 書く 3. パッチをPhabricatorに提出 4. レビュアがDifferentialを使ってレビュー 5. Landoからパッチを”autoland”リポジトリにコミットす る 6. 各修正ごとに自動テストが全て実行される 7. 日に二回、”mozilla-central”にマージされ、Nightlyビ ルドが作成される 8. Bugzillaの”バグ”が”RESOLVED FIXED”とマークされ、 閉じられる
35. 35. Phabricator Git/Mercurial/SVN対応のレビュー ツール PhacilityのOSSプロダクト。 Archanistというコマンドラインツー ルからパッチをポストできる。 ただし、Arcanistは使いにくいので、 moz-phabやphalayというツールを 使ってより手軽にアクセスできるよ うにもしている。
36. 36. Phabricatorから Bugzillaへ 自動ポスト Phabricatorにポストする際に BugzillaのバグIDを入力すると、そ のバグへ”attachment”として自動 的にコミットメッセージと共にポスト される。 これにより、バグ報告をトラッキン グしておけばパッチの完成を知る ことができる。
37. 37. Mozillaの 修正の流れ 1. Bugzillaにバグを報告する 2. ローカルにcloneした”mozilla-central”上でパッチを 書く 3. パッチをPhabricatorに提出 4. レビュアがDifferentialを使ってレビュー 5. Landoからパッチを”autoland”リポジトリにコミットす る 6. 各修正ごとに自動テストが全て実行される 7. 日に二回、”mozilla-central”にマージされ、Nightlyビ ルドが作成される 8. Bugzillaの”バグ”が”RESOLVED FIXED”とマークされ、 閉じられる
38. 38. Differentialで コードレビュー インデントレベルの変更等も意識し た、インラインレベルの変化を視覚 化してくれるDiffビューア。 インラインでコメントを追加すること も、パッチ全体に対してコメントを 追加することも可能。
39. 39. Mozillaの 修正の流れ 1. Bugzillaにバグを報告する 2. ローカルにcloneした”mozilla-central”上でパッチを 書く 3. パッチをPhabricatorに提出 4. レビュアがDifferentialを使ってレビュー 5. Landoからパッチを”autoland”リポジトリにコミットす る 6. 各修正ごとに自動テストが全て実行される 7. 日に二回、”mozilla-central”にマージされ、Nightlyビ ルドが作成される 8. Bugzillaの”バグ”が”RESOLVED FIXED”とマークされ、 閉じられる
40. 40. Landoで 自動チェックイン 複数の依存関係にあるパッチを同 時にチェックイン可能。 LandoもMozillaのOSSプロダクト。
41. 41. Mozillaの 修正の流れ 1. Bugzillaにバグを報告する 2. ローカルにcloneした”mozilla-central”上でパッチを 書く 3. パッチをPhabricatorに提出 4. レビュアがDifferentialを使ってレビュー 5. Landoからパッチを”autoland”リポジトリにコミットす る 6. 各修正ごとに自動テストが全て実行される 7. 日に二回、”mozilla-central”にマージされ、Nightlyビ ルドが作成される 8. Bugzillaの”バグ”が”RESOLVED FIXED”とマークされ、 閉じられる
42. 42. “autoland”に 入ったパッチの 自動テスト 自動的に全てのプラットフォームでビ ルドが行われ、自動テストも全て走る。 ランダムな失敗を除き、全てのテスト に合格できなかったものはバックア ウトされる。 パフォーマンステストも走るので、そ のregressionが検知された場合には バグとして報告される。 使われているインフラはTry Serverと 同じもの。
43. 43. Mozillaの 修正の流れ 1. Bugzillaにバグを報告する 2. ローカルにcloneした”mozilla-central”上でパッチを 書く 3. パッチをPhabricatorに提出 4. レビュアがDifferentialを使ってレビュー 5. Landoからパッチを”autoland”リポジトリにコミットす る 6. 各修正ごとに自動テストが全て実行される 7. 日に二回、”mozilla-central”にマージされ、Nightly ビルドが作成される 8. Bugzillaの”バグ”が”RESOLVED FIXED”とマークされ、 閉じられる
44. 44. Nightly Buildの リリース Landoからコミットされる”autoland”リポジトリはmozilla- centralを安定化させるためのワンクッション。 ”autoland”で全てのテストにパスすることを確認したも のだけが一日に二回、”mozilla-central”にマージされ、 Nightly Buildの作成が始まる。 これが無かった時はmozilla-centralからpull/cloneしたリ ビジョンがたまたまビルドすらできないものだったりする ことがあり、数十分ビルドした後にがっかりすることが 多々あった。
45. 45. Mozillaの 修正の流れ 1. Bugzillaにバグを報告する 2. ローカルにcloneした”mozilla-central”上でパッチを 書く 3. パッチをPhabricatorに提出 4. レビュアがDifferentialを使ってレビュー 5. Landoからパッチを”autoland”リポジトリにコミットす る 6. 各修正ごとに自動テストが全て実行される 7. 日に二回、”mozilla-central”にマージされ、Nightlyビ ルドが作成される 8. Bugzillaの”バグ”が”RESOLVED FIXED”とマークされ、 閉じられる
46. 46. Bugzillaのバグが 閉じられて終わり “mozilla-central”にマージされると、 そのマージされた修正へのリンク がバグに登録され、各種ステータ スが更新される。
47. 47. Mozillaの 開発環境の特徴 ✓全てWebアプリとして提供されている ➢世界中の開発者がリモートで利用可能 ➢自宅からでも開発可能 ✓ツールで簡単に操作できるようにし、多くの開発者の時 間を無駄にしないようにしている ➢諸々の事情でサーバ側の仕様が変わっても教育コストを最小 限に抑えている ➢マニュアルをしっかりと用意しておくことにより、世界中のボラ ンティア開発者が調べやすくなる ✓多くのツールを内製し、オープンソースプロダクトとして公 開している ➢多くの開発現場が同等の環境を作れる(かも?) ➢Mozillaのツールをうまく使えば働き方改革になる かも? ➢ちなみに、私は先日、脊椎を骨折しましたが、これらのツールの おかげでたったの一週間休むだけで仕事が再開できました ヽ(´▽｀)ノ
48. 48. Q&A? ※ただし、Geckoの開発者なので サーバサイドの細かいことは全く 答えられません🙇