Dropboxでは毎日、35,000回近いビルドと数百万件の自動テストを実行している。実行されるテストの中には、コードの変更が原因で失敗したり、再現不可能な方法で失敗するものもある。不安定なテストを手動で無効にしたり、不正なコミットを元に戻したり、テストのオーナに失敗を通知するというのは、Dropboxの規模では困難だ。このような作業を自動化する目的で、Athenaは開発された。Athenaは、確定的なテストの失敗をオーナに通知し、不安定なテストを検出して隔離する。ただし、テストを失敗させたコミットの取り消しは行わない。
コードをコミットする作業のサイクルは、基本的な"送信前"テストから始まり、マスターブランチとマージした後、"送信後"のテストを行う。送信後のカテゴリには、UIやエンドツーエンドなど、高価なテストが含まれている。後者のカテゴリのテストは、時刻、日付、基盤となるインフラストラクチャなど、環境的要因によって失敗する可能性がある。並行性や乱数生成など、コード固有の特性が原因で失敗する場合もある。これまでのDropboxには、このような変更を元に戻すローテーションチームがあった。InfoQは今回、DropboxのソフトウェアエンジニアであるUtsav Shah氏から、Athenaの詳細について聞くことにした。
Athenaは、テストが不安定かどうかの判断に、マルチステップアルゴリズムを使用する。一定期間内に複数回失敗した送信後テストにはマークが付けられ、コードの通過が許可される。失敗したテストはその後も実行され、失敗の原因がフレキネス(flakiness)あるいは不正なコードにあるかどうかが判断される。さらにAthenaは、テストが失敗するようになったコミットを特定することもできる。このようなテストを自動隔離することにより、Dropboxでは、運用オーバヘッドの削減に成功した。Shah氏によると、Athenaは現在、"Dropboxのすべてのサービス(バックエンド、フロントエンド)の、テストのほとんどを監視しています。デスクトップまたはモバイルアプリケーションのテストはまだ監視していません。"
許諾を得て使用
継続的インテグレーション(CI)はDropbox全社で使用されているが、デプロイメント戦略はサービスによって異なる。Shah氏が詳しく説明する。
Dropboxには、個々のチームが所有する多数のバックエンドサービスと、dropbox.comを運用するメインのWebアプリケーションがあります。各サービスのデプロイを可能にするためには、無効サイトや実験サービスを除き、関連するすべてのテストがグリーンである必要があります。サービスの継続的デプロイを好むオーナもいれば、手作業でデプロイするオーナもいます。
Shah氏が説明によると、Athenaにはステータスを監視し、開発者に可視性を提供するためのUIが用意されている。
テスト単位の進行状況と、それぞれのコミットでテストを実行した結果を表示します。各テストにはそれぞれ、成功と失敗の分岐点(bisect)がどのコミットにあるかを示すメッセージと、テストを失敗させた可能性のあるコミットの範囲(下限および上限)があるので、緊急性のある場合は、ユーザ自身で問題の検出と修正を行うことができます。
Athenaシステム自体の監視についてはどうだろう？この点に関しては、まだ行うべきことがある、とShah氏は言う。
分岐点のバグのようなビジネスロジックのリグレッションの検出を支援するために、内部CIシステムの偽物(fake)を使用するユニットテストのスイートを用意しています。API保証が満たされていることを確認するための、CIシステムに対する統合テストもあります。この２つで、ほとんどの問題をキャッチします。
Dropboxのサービスオーケストレーションシステムには、多くの基本的な問題を検出する、便利な自動生成アラートがあります。ただし、Athenaのカスタムリアルタイムモニタリングには、まだ着手できていません。CIシステムに問題がない限り、システムは通常動作します。CIシステムに問題があれば、私たちは事前に気付くでしょう。監視機能のないことは、特定のアップストリームAPIが遅く、タイムアウトが発生する場合に、何度か問題を引き起こしているので、それらをキャッチするために、基本的なアラートをいくつか追加したいと思っています。
Athenaのロードマップには、テストを失敗させたコミットの自動取り消しと、デスクトップテストが含まれている。内部的な依存関係のため、オープンソース化は計画されていない。