以下に、ほとんどの CI システムに見られる機能をいくつか示します。
環境
ワークフローを実行するハードウェアとソフトウェアの環境を選択して理解することが重要です。Android アプリに関する重要な考慮事項は次のとおりです。
- プラットフォーム: Linux、Mac、Windows とそのバージョン。
- 使用可能なメモリ: アプリをビルドしてエミュレータを実行すると、大量の RAM が使用される可能性があります。メモリ不足エラーを回避するには、JVM のヒープサイズなどのパラメータを調整する必要があります。
- プリインストールされたソフトウェア: CI システムは通常、Java 開発キット（JDK）、Android ソフトウェア開発キット（SDK）、ビルドツール、プラットフォーム、エミュレータなど、すでに利用可能なツールの大規模なコレクションを含むイメージを提供します。
- ランナー アーキテクチャと命令セット: ARM、x86。これは、エミュレータを使用する場合に重要です。
- 環境変数: 一部は CI システムにより設定されます（例:
ANDROID_HOME）。また、ワークフローの認証情報のハードコードを回避するために、独自に設定することもできます。
利用可能なコアの数や、エミュレータを実行できる仮想化が有効になっているかどうかなど、他にも考慮すべき点は数多くあります。
ログとレポート
ステップが失敗すると、CI システムから通知されます。通常は変更を統合できません。問題の原因を特定するには、ログでエラーを探します。
また、ビルドとテストを行うと、通常は特定のビルドのアーティファクトとして保存されるレポートが生成されます。CI システムによっては、プラグインを使用してレポートの結果を可視化できます。
キャッシュと CI の実行時間
CI システムはビルド キャッシュを使用してプロセスを高速化します。最もシンプルな形式では、ビルドが成功したらすべての Gradle キャッシュ ファイルを保存して、新しいビルドの前にそれらを復元します。これは Gradle のビルド キャッシュ機能に依存しているため、プロジェクトで有効にする必要があります。
実行時間と信頼性を向上させる方法には、次のようなものがあります。
- モジュール: 変更の影響を受けるモジュールを検出し、そのビルドとテストのみを行います。
- キャッシュをスキップする: デベロッパーが変更したスクリプトがビルドに含まれている場合、ビルド キャッシュは無視されます。ゼロから構築する方が安全です。
- シャードテスト: 特にインストルメンテーション テストでは、複数のデバイス間でテストをシャードすると便利です。これは、Android ランナー、Gradle で管理されているデバイス、Firebase Test Lab でサポートされています。
- シャーディングされたビルド: 複数のサーバー インスタンスにビルドをシャーディングできます。
- リモート キャッシュ: Gradle のリモート キャッシュを使用することもできます。
失敗したテストを再試行する
不安定性とは、断続的に失敗するテストやツールのことです。不安定なビルドやテストを生成する問題を常に見つけて修正する必要がありますが、その中には、特にインストルメンテーション テストを実行する場合、再現が困難なものもあります。一般的な方法は、テスト実行が失敗した場合、最大再試行回数までテスト実行を再試行することです。
再試行は複数のレベルで発生する可能性があるため、再試行を構成する方法は 1 つではありません。次の表に、不安定なテストが失敗した場合の対応を示します。
エラー |
行動 |
|---|---|
エミュレータが 1 秒間応答せず、タイムアウトがトリガーされた |
不合格になったテストを再実行する |
エミュレータを起動できない |
タスク全体を再実行する |
コードのチェックアウト フェーズ中に接続エラーが発生しました |
ワークフローをやり直す |
システムのどの部分が不安定なのかを記録して追跡し、CI の信頼性と速度の維持に投資して再試行のみを行うことが重要です。