Chromiumでの作業方法

オリジナルの作者からの序文：

2011年3月に、Google Chromeを担当するチームが製品を開発およびリリースする方法についてのドラフト記事を書きました。その後、私は安全に忘れてしまいました。 ほんの数日前、私は偶然それを見つけました。 いくつかの場所でそれを時代遅れにしましょう（Chromeは2013年にBlinkでWebKitを分岐させ、私自身はGoogleで働いていません）、そこに含まれるアイデアはまだ有効であると信じています。

今日は、Chromiumの仕組みを説明します。 いいえ、 Chromeブラウザに関するものではなく、ブラウザの作成に関わる人々のグループであるChromiumに関するものです。



何百人ものエンジニアがChromiumプロジェクトに取り組んでいます。 一緒に、毎週約800件の変更をコードベースにコミットします。 また、 V8 、 Skia 、 WebKitなど、他の大規模で急速に発展している多くのプロジェクトにも依存しています。



6週間ごとに、明らかにスケジュールどおりに、数億人のユーザーに新しい安定したリリースを送信しています。 さらに、さらに高速に更新される他のいくつかの早期アクセスチャネルをサポートしています。最速のチャネルであるカナリアの 「静かに」ほぼ毎日の自動更新です。



これはどのように機能し続けますか？ この「バス」の「車輪」がまだ「落ちていない」のはなぜですか？ すべての開発者がまだクレイジーではないのはなぜですか？



技術的な観点から見ると、Chromiumチームの速度は、信頼性が高く効率的で「静かな」自動更新のおかげで達成可能になりました。



人的資源の観点から見ると、これは献身的で勤勉でスマートなQAチームとリリースエンジニアのメリットです。これがなければ、プロジェクト全体が数週間で崩壊します。 また、デザイナー、プロダクトマネージャー、ライター、PR、弁護士、情報セキュリティ、その他すべての安定版リリースで協力するすべての人。 今日は、Steve Yeggの精神で巨大なポストに滑り込まないように、エンジニアリングのトピックのみに集中して、全員について話すことはしません。



クイックリリースを可能にするために特別に構築されたChromium開発プロセスについてお話します。 リリーススケジュールがどのようなものであるかに関係なく、他のプロジェクトに役立つ可能性がある興味深い発見についてです。 私たちの困難に言及します。

枝なし

多くのプロジェクトでは、新しい「主要な」機能で動作するブランチを作成するのが一般的です。 この選択の考え方は、新しいコードによる不安定化が他の開発者やユーザーに影響を与えないということです。 機能が完了すると、 トランクにマージされ、その後、通常は不安定な期間が続きますが、統合の問題は解決されます。



Chromeでは、このアプローチは機能しません。毎日リリースされるためです。 大量の新しいコードが突然trunkに出現することを許可することはできません。この場合、 カナリアまたはdevの更新チャネルが長時間失敗する可能性が高いためです。 さらに、Chromeのトランクは、開発者がブランチ上で長時間孤立し続けるのは実用的ではないような速度で前進しています。 ブランチを保持するまでに、 トランクの外観が大きく異なるため、統合に時間がかかり、エラーが発生しやすくなります。



各ベータリリースの前に運用ブランチを作成しますが、次のベータリリースまで、最長6週間というそれほど長くはありません。 そして、私たちはこれらのブランチで直接開発を行うことはありません。リリースに含まれるべきすべての遅延修正は、最初にtrunkで行われ、その後ブランチに対してチェリーピックが行われます。



このようなプロセスの快適な副作用：プロジェクトには、生産ブランチでの作業に専念している「セカンドクラス」開発者の特別なチームがありません。 すべての開発者は、常にソースコードの最新の最新バージョンを使用します。

ランタイムスイッチ

ブランチを作成しませんが、ユーザーから不完全な機能を隠す方法が必要です。 これを行う自然な方法は、コンパイル時のチェックを使用することです。 その問題は、そのようなアプローチがコードでブランチを作成することと大差ないということです-実際、あなたはまだ2つの独立したコードベースがあり、いつかはsnozhzhenyでなければなりません。 また、新しいコードはデフォルトでコンパイルおよびテストされていないため、開発者がこのコードを誤って壊すことは難しくありません。



代わりに、Chromiumプロジェクトはランタイムチェックを使用します。 開発中の各機能は、最初からすべての構成でコンパイルおよびテストされています。 最初にテストするコマンドラインフラグがあります。 他の場所では、ほとんどの部分のコードベースはどの関数が利用可能かわからない。 この戦略は、新機能の作業が可能な限り最初からプロジェクトコードに統合されることを意味します。 少なくとも、新しいコードがコンパイルされるため、新しい関数が機能するために必要なメインコードのすべての変更がテストされ、ユーザーはすべてが通常どおりに機能し、違いに気付かないと考えています。 さて、 コマンドラインを一時的に「再定義」して 、まだ利用できない機能のパフォーマンスをチェックする自動テストを簡単に作成できます。



機能が完成に近づいたら、オプションをchrome：// flagsのフラグの形で提示し、上級ユーザーがテストを開始してフィードバックを提供できるようにします。 その結果、機能のリリース準備が整ったと思われる場合は、コマンドラインフラグを削除して、デフォルトで使用可能にします。 この時点までに、コードは通常、広範囲にわたってテストされ、多くのユーザーによってロールインされているため、アクティベーションによる潜在的な損害が最小限に抑えられています。

膨大な量の自動テスト

毎日リリースされるためには、コードベースが常に良好な状態にあることを確認する必要があります。 これには自動化されたテストが必要であり、非常に多くのテストが必要です。 これらの行が作成された時点で、Chromeにはクラスレベルのテストが12k個、自動化された統合テストが2000個、パフォーマンステスト、膨張テスト、スレッドセーフティ、メモリセーフティテスト、その他の多くのテストがあります。今は覚えていません そして、これらすべてがたった1つのChromeで。 WebKit、V8、およびその他の依存関係は個別にテストされます。 1つのWebKitには、Webページが表示され、正しく機能することを確認する約27kのテストがあります。 私たちの基本的なルールは、すべての変更がテストに伴うべきであるということです。



テストスイートでコードの新しい変更を常に実行するパブリックビルドボットを使用します 。 「グリーンツリー」ポリシーを遵守します。変更がテストを「中断」した場合、すぐにロールバックされ、開発者は変更をコミットして再投稿する必要があります。 次の理由により、このような「重要な」変更をツリーに残しません。

• これにより、誤ってさらに「重要な」変更を行うことが容易になります-ツリーがすでに赤である場合、それが赤くなると誰も気付かない
• これにより、誰もが壊れたものに取り組むことを余儀なくされるため、開発が遅くなります。
• これにより、開発者はテストに合格するために不注意な迅速な修正を行うことができます。
• これにより、リリースできなくなります！

開発者がツリーの問題を回避できるように、リリース前にすべてのテストおよび構成で変更を「プッシュ」する方法であるトライボットがあります。 結果は開発者にメールで送信されます。 また、変更をテストし、すべてのテストが成功した場合にそれらを自動的に適用するコミットキューもあります。 ハッキングに長い夜を費やした後、私はそれを使用するのが好きです-私はボタンを押してベッドに行き、しばらくして、私の変更が注がれたことを期待して目を覚まします。



実行されたすべての自動テストのおかげで、 開発チャンネルで最小限の手動テストを行うことができ、「カナリア」ではまったく実行できません。

容赦ないリファクタリング

テストの対象範囲はかなり広いため、リファクタリングを積極的に行う余裕があります。 Chromeプロジェクトは、いくつかの主要な領域でリファクタリングに常に取り組んでいます。たとえば、2013年の期間では、これらはCarnitasとAuraでした。



私たちの規模とペースで、コードベースをクリーンで理解しやすい状態に保つことが重要です。 私たちにとって、これらの品質は回帰を防ぐことよりも重要です。 Chromeプロジェクト全体のエンジニアは、システム内の任意の場所で改善を行う権利を有します（ただし、その際、モジュール所有者の必須レビューを要求する場合があります）。 リファクタリングの結果、何かが最終的に故障し、テスト段階でこれを検出できない場合、私たちの観点からは、リファクタリングを行ったエンジニアではなく、テストで十分に機能がカバーされていないエンジニアのせいではありません。

Deps

WebKitは、これほど速いペースで開発されています。 そして、いつかメインのものに突然マージする機能のブランチを用意する余裕がないという事実と同様に、WebKitの毎月の変更セットを一度に遅らせることはできません。これにより、ツリーが数日間不安定になります。



代わりに、成功するまでChromeをWebKitの最新バージョン（ほとんどの場合、このバージョンは半日以内）でコンパイルしようとします。 Chromeプロジェクトのルートには、現在コンパイルに成功しているWebKitのバージョンを含むファイルがあります。 チェックアウトして作業コピーを作成するか、Chromeソースコードを更新すると、 gclientツールはファイルで指定されたWebKitのバージョンを自動的に取得します。



エンジニアは1日に数回、バージョン番号を更新し、統合中に新しい問題があるかどうかを確認し、適切なエンジニアにバグを割り当てます。 その結果、WebKitの小さな変更は常に一度に行われ、同様のアプローチでソースツリーへの影響は通常最小限に抑えられます。 また、WebKitビルドボットにボットを追加したため、WebKitのエンジニアがChromeを壊すような変更を加えると、すぐにそのことを知ることができます。



DEPSシステムの大きな利点は、Webプラットフォームに非常に迅速に変更を追加できることです。 WebKitで導入された機能は、 カナリアチャンネルでChromeユーザーが数日以内に利用できるようになります。 これにより、アップストリームのWebKitですぐに改善を行うことが奨励されました。WebKitをアプリケーションで使用するすべての人にとって有用であり、Chromeでローカルに適用することはできません。 正直なところ、基本的なルールは、WebKitにローカルな変更を一切加えないことです（Chromeが依存する他のプロジェクトも同様です）。

問題

完全なテストは未解決の問題のままです。 特に、「不安定な」統合テスト（不安定な統合テスト ）は、私たちにとって常に問題になっています。 Chromeは大きく、複雑で、非同期で、マルチプロセスで、マルチスレッドです。 そのため、統合テストでは、時々発生する微妙な同期の問題により失敗しやすくなります。 私たちの規模のプロジェクトでは、1％の時間で失敗するテストは、1日に数回失敗することが保証されます。



テストが「不安定」になるとすぐに、チームはすぐにそれを無視する習慣になります。その結果、コードの同じ部分の別の作業テストのファイルを見逃しやすくなります。 そのため、「不安定な」テストをオフにし、カバレッジの割合を失い、ユーザーに基本的なリグレッションを発行しやすくします。



別の問題は、そのような速度では「美を誘発する」ことが難しくなることです。 私にとっては、チームが無期限にあらゆる小さなことに集中し、常に維持しようとするよりも、珍しい「知名度の高い」リリースですべての詳細の正しい実装を達成する方が簡単です。 多くの場合、ツールバーのボタン間の距離などの小さな詳細をテストするのは難しいため、このような場所ではエラーが簡単に発生する可能性があります。



最後に、ストレスは非常に現実的な問題であるように思えます。 常に変化するこのすべてのコードを考えると、人が自分の責任の領域のみに集中しようとしても、プロジェクトの別の部分で何かが起こっても傷つけられないという意味ではありません。 Chromeの一部を常に動作させようとすると、遅かれ早かれ、火山のように住んでいるように見え始め、安心する余裕はありません。



最後の問題に対処するには、コードベースをメインモジュールに分割します。 Carnitasのエンジニアは、いくつかの主要コンポーネント間でより明確で厳しいインターフェイスを確立しようとしています。 現時点では、コードの大部分がより明確で明確になっていますが、これがグローバルレベルでストレスを軽減する方法を説明するのは時期尚早です。

結論として

それで、「車輪」がまだ「落ちていない」ことに感謝しますか？ 要するに、ブランチ、ランタイムスイッチ、大量の自動テスト、冷酷なリファクタリング、依存関係のHEADに可能な限り近い位置を維持することのない生活のおかげです。



これらの手法は、急速に変化するアップストリームの依存関係を持つ大規模なプロジェクトに最も役立ちますが、小規模なプロジェクトに適用できるものもあります。