【ITニュース解説】How to Add Quality Gates to a GitHub Actions Pipeline (Step by Step)

現代のソフトウェア開発では、コードの品質を高く保ち、安定したサービスを提供することが非常に重要である。この目的を達成するために、「継続的インテグレーション（CI）」と「継続的デリバリー（CD）」という自動化されたプロセスが広く使われている。CI/CDパイプラインは、コードが変更されるたびに自動的にビルド、テスト、デプロイを行う一連の流れを指す。しかし、単にテストを実行するだけでは不十分な場合がある。テストが失敗しても、その問題を修正せずに次の段階に進んでしまったり、最終的に本番環境に問題のあるコードがデプロイされてしまったりするリスクがあるからである。

そこで重要になるのが「品質ゲート」という考え方である。品質ゲートとは、CI/CDパイプラインの特定の段階に設けられる「通過条件」のようなものである。この条件が満たされなければ、パイプラインは次の段階へ進むことができず、問題のあるコードがそれ以上先に進むのを自動的に阻止する仕組みである。品質ゲートを導入することで、開発者は問題が早期に発見され、本番環境にデプロイされる前に確実に修正されることを保証できるようになる。

この記事では、GitHub ActionsというGitHubが提供するCI/CDサービスを使って、どのように品質ゲートをパイプラインに組み込むかを具体的に解説する。GitHub Actionsは、YAMLという記述形式でワークフローを定義し、リポジトリへの変更などをトリガーとして自動処理を実行できるサービスである。今回は、Pythonで書かれた小さなウェブサービスを例に、以下の四つの品質ゲートを順番に構築する。

最初のゲートは「リンティング（Lint）」である。これはコードのスタイルをチェックしたり、構文エラーや未使用の変数など、明らかな問題を素早く検出したりする作業である。リンティングは非常に高速に実行でき、コードの品質を保つ上で基本的なステップとなるため、パイプラインの早い段階で実行するのが効果的である。もしリンティングに失敗した場合、その後のより時間とコストのかかるテストを実行する必要がなくなるため、開発者は素早くフィードバックを受け取り、問題を修正できる。GitHub Actionsでは、.github/workflows/pipeline.yml というファイルを作成し、ruff check . といったコマンドでリンティングツールを実行するジョブを定義する。このジョブは、コードがGitHubにプッシュされたり、プルリクエストが作成されたりした際に自動的に開始される。

次に「単体テストとカバレッジ閾値」のゲートを追加する。単体テストは、プログラムの個々の部品（関数やメソッドなど）が意図した通りに動作するかを検証するテストである。これに加えて、「カバレッジ閾値」という条件を設定する。これは、作成されたコードのうち、どれだけの割合が単体テストによって実行されたかを示す「テストカバレッジ」の割合が、事前に定めた基準（例えば80%）を下回った場合に、テストを失敗させる仕組みである。カバレッジが低いコードは、テストされていない部分に潜在的なバグが隠れている可能性が高い。このゲートは、リンティングジョブが成功した後にのみ実行されるように設定する。pytest というPythonのテストフレームワークと pytest-cov というカバレッジツールを使い、--cov-fail-under=80 というオプションを付けて実行することで、カバレッジが基準を満たさない場合に自動的にジョブを失敗させることができる。これにより、十分にテストされていないコードが先に進むのを防ぐ。

三つ目のゲートは「APIテスト」である。単体テストがプログラムの個々の部品を検証するのに対し、APIテストは、実際にサービス全体を起動し、外部からのリクエストに対して期待通りに動作するかを確認するテストである。サービスが正しく起動しているか、他のコンポーネントとの連携がうまくいっているかなど、より統合的な視点での検証が可能になる。このゲートも単体テストが成功した後にのみ実行されるように設定する。APIテストのジョブでは、まずウェブサービスをバックグラウンドで起動し、そのサービスが完全に準備できるまで待機する仕組み（ヘルスチェック）を組み込むことが重要である。そうしないと、サービスが起動しきる前にテストが始まってしまい、テストが不安定になる可能性があるからである。サービスが正常に起動したことを確認した後、pytest を使ってAPIに対するテストを実行する。

最後のゲートは「手動承認」である。これまでの自動テストがすべて成功した後でも、本番環境へのデプロイには人間による最終確認が必要な場合がある。例えば、特定のビジネスロジックの確認や、デプロイのタイミングに関する判断などがこれにあたる。GitHubでは、「環境」という機能を使って、特定のジョブの実行前にレビュー担当者による承認を必須に設定できる。リポジトリの「Settings」から「Environments」に進み、「production」などの環境を作成し、必要なレビュアーを追加する。そして、デプロイを行うジョブにこの環境を指定することで、APIテストが成功した後、パイプラインは一時停止し、指定されたレビュアーがGitHubのUI上で承認するまで待機するようになる。承認されなければデプロイは実行されないため、人的なミスを防ぐ最終的な防波堤となる。

これらの品質ゲートが正しく機能するためには、誰もそれらを回避できないようにする必要がある。そのためには「ブランチ保護ルール」を設定することが不可欠である。GitHubの「Settings」から「Branches」に進み、main ブランチなどの主要なブランチに対して保護ルールを追加する。「Require status checks to pass before merging」というオプションを有効にし、これまでに設定した「lint」「unit-tests」「api-tests」の各ジョブを選択する。この設定により、これらのゲートのうち一つでも失敗しているプルリクエストは、main ブランチにマージできなくなる。これにより、品質ゲートが強制力を持つようになり、品質基準を満たさないコードが本番ブランチに取り込まれるのを確実に防ぐことができる。

このように段階的に品質ゲートを設けることで、コードが開発される初期段階から最終的なデプロイに至るまで、継続的に品質がチェックされる。リンティングのように安価で高速なチェックから始め、段階的に複雑で時間のかかるチェックへと進むことで、問題が早期に発見され、開発者は迅速にフィードバックを受け取って修正できる。これにより、開発効率が向上し、本番環境でのバグ発生リスクが大幅に低減され、より安定したサービス提供が可能になる。品質ゲートは、単にテストを実行するだけでなく、ソフトウェア開発の信頼性と品質を劇的に向上させるための強力な手段となる。