Cartoon gears and neon rolling marbles rolling through a track

GitHub Actions を使用したテスト自動化戦略上級

Bekah Whittle
Bekah Whittle // Director, Field Services // GitHub

プロジェクトが拡大し、複雑になるにつれ、テストはさらに困難になります。GitHub Actions は、幅広いテスト スタイルを提供し、大規模のニーズにカスタマイズされた豊富なサービスを市場に取り揃えています。このガイドでは、GitHub Actions での高度なテスト戦略の概要を説明し、スケーラビリティの問題に効果的に対処できる可能性について強調しています。Stack Overflow は、同社の運用を合理化したワークフロー最適化についてのディスカッションに再び参加します。

このガイドの学習内容

  •  GitHub Marketplace を検索・活用して高度なテスト要件に対応する方法

  •  マトリックス設定を使用してテスト タイムラインを短縮する方法

  •  「戦略」キーワードとランナー サイズを選択してワークフローを最適化する方法

GitHub Marketplace を活用する

GitHub Marketplace は、さまざまなニーズを満たすテスト ソリューションを多数提供しているため、テスト機能を強化するうえで強力なツールになります。GitHub Marketplace では、ユニット テスト、セキュリティ チェック、Lint、iOS や Android などのプラットフォームに特化したテストなど、特定の必須要件に対応したツールが見つかります。

さらに、Marketplace はコミュニティ主導型であるため、独自のテスト シナリオに対応するツールやアクションが次々と提供されます。ユーザーは GitHub Marketplace を検索し、必要なツールを見つけて組み込み、その結果、テスト戦略を強化して、包括的なテスト カバレッジを達成できます。

テストのスケーリングにおけるマトリックスの威力

GitHub Actions のマトリックスを使用すると、異なるシステムや異なるバージョンのソフトウェアで一度にテストを実行できます。テストを迅速に実施し、ソフトウェアが異なる設定で動作することを確認できます。

たとえば、同時に、Windows と Ubuntu の両方を対象に、異なるソフトウェア バージョンを使用してソフトウェアをテストできます。これにより、時間を節約しながら、ソフトウェアがさまざまな環境で適切に機能することを確認できます。

マトリックスを使用する最大の利点はスピードです。テストは順番に実行されるのではなく同時に実行されるため、プロセス全体が高速化し、フィードバックを迅速に得ることができます。

以下の例では、strategy を matrix を使用して定義しています。このマトリックスには 2 つの配列 version Total Acceptance Rate などの指標により、os. 

jobs:
  example_matrix:
    strategy:
      matrix:
        version: [10, 12, 14]
        os: [ubuntu-latest, windows-latest]

この設定では、以下のようにバージョンと OS の組み合わせが 6 通り自動的に生成されます。

{version: 10, os: ubuntu-latest}
{version: 10, os: windows-latest}
{version: 12, os: ubuntu-latest}
{version: 12, os: windows-latest}
{version: 14, os: ubuntu-latest}
{version: 14, os: windows-latest}

これらの組み合わせは並列実行されるため、複数のソフトウェア バージョンとオペレーティング システムを同時にテストできます。その結果、テスト時間を大幅に短縮しつつ、包括的なカバレッジを達成できます。

当社では GitHub Actions の動的なマトリックスを使用して、個々のプル リクエスト (PR) に合わせたテスト環境を設定しています。 チーム メンバーは PR を作成する際に、パブリック プラットフォーム、Stack Overflow for Teams、独自の構成など、必要なテスト環境の種類を示す特定のラベルを適用できます。その後、ラベルに基づいて動的なマトリックスを自動生成し、そのマトリックスを使用してテストに必要な正確な環境を設定します。このマトリックスは特定のデータ サブセットを環境に入力するためにも使用するできるため、より堅牢で有意義なインテグレーション テストが可能になります。このアプローチを用いれば、開発サイクルを加速し、エラーを減らし、信頼できる高品質の製品を確実に提供できるようになります。

Jason Schwanz
Jason Schwanz // Staff Site Reliability Engineer // Stack Overflow

テストの 'strategy' を設定する

Enterprise 規模のテストでは、strategy キーワードは極めて重要です。このキーワードを使用することで、複雑なプロジェクトのワークフローを体系的に定義、管理できます。特に注目すべき strategy のキーワードは fail fastです。効率化のためのキーワードであり、失敗が検出されると即座にテストを停止する設計になっているため、貴重な時間やリソースを節約できます。複数のプラットフォームを扱う Enterprise は、strategy を使用して、複数の異なるオペレーティング システムやバージョンで同時にテストを実行し、堅牢な互換性やカバレッジを徹底できます。

ランナー サイズを選択する

適切なランナー サイズを選択するには、バランスを考慮します。リソースに過度な負荷をかけたり、リソースの活用不足に陥ったりすることなく、テストが迅速に完了するようにすることが重要です。たとえば、軽量なタスクの場合は 2 コアのランナーで十分な場合もあります。一方、負荷の高いテストでタイムリーな結果を得るには、8 コアのランナーが必要になる場合もあります。

Enterprise の意思決定者は、テストの性質を理解し、それに応じてランナーのサイズを調整し、時間とリソースの両方を最適化することが重要です。

とりわけ、Stack Overflow では小さなチームで大きな GitHub のフットプリントを管理しているため、全てのランナー グループを Enterprise レベルで管理することによって、シンプルさを維持しています。 注目すべきはランナーの容量です。例えば、大規模なランナーを必要とする機能テストのような、リソースが集中するタスク専用のランナー グループがある場合、実験や概念実証プロジェクトに取り組むときは、このグループのランナーの使用を避けて、コストを抑えています。

Jason Schwanz
Jason Schwanz // Staff Site Reliability Engineer // Stack Overflow

次のガイド: GitHub Actions の高度なデプロイ戦略

次のステップに進む準備はできましたか? 次の GitHub Actions を使った高度なデプロイのガイドでは、スケーラブルなデプロイ戦略について説明します。