静的解析と自動テストを自動化しよう

この章では、GitHub ActionsでPull Request時にflake8とpytestを自動実行する仕組みの構築をハンズオン形式で学習します。これにより、CIの基本であるコードチェックの自動化ができるようになります。

1. 本章の概要

1.1 本章の目的

CI/CDパイプラインでは、コードが変更されたタイミングで自動的に品質チェックを走らせ、問題のあるコードがmainブランチにマージされないようにするのが基本的な考え方です。特に静的解析と自動テストは、pushのたびに走らせて損はない土台的な仕組みで、CIの入り口として押さえるべき要素です。

1.2 ハンズオンの流れ

PythonのシンプルなサンプルコードをGitHubリポジトリに配置し、Pull Requestの作成をトリガーにflake8（静的解析）とpytest（自動テスト）を並列実行するワークフローを構築します。わざとコードを壊してワークフローが失敗する様子も確認します。

1.3 事前準備

前提となる講座

この章では、以下の知識を前提としています。自信がない場合は先に関連講座を実施してみましょう。

必要なツール

この章では、以下のツールを使用します。まだインストールしていない場合は、リンク先の手順に沿って準備をお願いします。

必要なアカウント

この章では、以下のアカウントを使用します。まだ用意していない場合は、リンク先の手順に沿って準備をお願いします。

2. リポジトリの準備

CI/CDパイプラインを構築するためには、まず対象となるソースコードを管理するGitリポジトリが必要です。GitHub Actionsはリポジトリに格納されたコードに対して動作するため、ここでは自身のGitHubアカウントにリポジトリを用意し、ローカル環境でコードを編集できる状態を整えます。

2.1 GitHubでの空リポジトリの作成

今回のハンズオンの主役は「GitHub Actionsのワークフロー」であり、題材となるPythonコード自体はごく簡単なものを使います。ゼロから本格的なアプリケーションを作る必要はなく、このあとの手順で数ファイルだけ作成すれば十分です。

実務に近い形を体験するために、ご自身のGitHubアカウントで新しいリポジトリを作成し、そこにサンプルコードを配置する流れで進めます。自分が作ったリポジトリに対してCIを構築することで、実感が湧きやすい体験ができます。

GitHubにログインし、右上の+ボタンからNew repositoryをクリックします。

以下の設定でリポジトリを作成します。

Create repositoryボタンをクリックしてリポジトリを作成します。

作成後、「Quick setup」の画面が表示されたら、ここでは何も操作せずに次のステップに進みます。

2.2 リポジトリのClone

作成したリポジトリはGitHub上に存在するだけで、ローカル環境ではまだ編集できません。このあとサンプルコードを配置したり、ワークフローファイルを追加したりするために、まずローカル環境にclone（コピー）します。

ローカル環境で、Windowsであればコマンドプロンプト、Macであればターミナルを開き、下記のgit cloneコマンドを実行します。＜your-github-account-name＞の部分はご自身のGitHubアカウント名に置き換えてください。

git clone https://github.com/＜your-github-account-name＞/devopscamp-ci-handson.git

空のリポジトリなので、cloneするとYou appear to have cloned an empty repository.という警告が表示されますが、問題ありません。これは「リポジトリの中身がまだ空である」という意味です。

cloneしたフォルダ（devopscamp-ci-handson）がローカル環境に作成されていれば、ここまでの操作は完了です。

2.3 サンプルコードの作成

ローカル環境に作業用フォルダが用意できたので、次はそこに配置するソースコードを作成します。CIの仕組みを確かめるために、テスト対象となるPythonコードを用意します。

Visual Studio Codeでdevopscamp-ci-handsonフォルダを開きます。「ファイル」→「フォルダーを開く」から、先ほどcloneしたdevopscamp-ci-handsonのフォルダを選択してください。

フォルダを開いたら、リポジトリ直下にcalculator.pyというファイルを作成します。

devopscamp-ci-handson/
└── calculator.py  ← このファイルを作成

作成したファイルに以下の内容を記述して保存します。

import os

def add(a: int, b: int) -> int:
    return a + b


def subtract(a: int, b: int) -> int:
    return a - b

このファイルには、2つの整数を足し算・引き算する簡単な関数を定義しています。先頭のimport osは意図的に入れています。このインポートはコード内で一度も使われていないため、静的解析で検出される「問題のあるコード」の例として使います。CIが実際にエラーを検知する様子を後ほど確認します。

Visual Studio Codeのエクスプローラにcalculator.pyが表示されていれば、ここまでの操作は完了です。

2.4 初回コミットとPush

ローカルリポジトリにコードを作成しただけでは、GitHub上のリモートリポジトリにはまだ何も反映されていません。CI/CDパイプラインはGitHub上のコードに対して動作するため、ここで初回のコミットとPushを行い、リモートリポジトリにコードを反映させます。

Visual Studio Codeのターミナルを開き、以下のコマンドを1つずつ実行します。

まず、作成したファイルをステージングします。

git add .

続いて、コミットします。

git commit -m "initial commit"

最後に、リモートリポジトリにPushします。

git push origin main

GitHubのリポジトリページを更新すると、calculator.pyが表示されます。これが表示されていれば、ここまでの操作は完了です。

3. 静的解析の実施

リポジトリの準備が整ったので、いよいよGitHub Actionsのワークフローを作成していきます。CIの最初のステップは静的解析です。静的解析を最初に行う理由は、コードを実行せずに構文上の問題やコードスタイルの崩れを検出できるため、テストといった後工程に進む前に早い段階で問題を発見できるからです。「実行して初めて気づくエラー」を減らせるため、開発者へのフィードバックが速くなります。

ここでは、Python用の静的解析ツールであるflake8を使用します。

3.1 静的解析の概要

今回は、Pythonの静的解析をGitHub Actionsのワークフローに組み込みます。トリガーとしては、mainブランチへのPull Requestが作成された際にワークフローが実行されるように設定します。Pull Requestの作成時にチェックすることで、「レビュー前の段階で基本的な品質問題を自動検知する」という流れを作れます。

処理の流れは以下のとおりです。

• GitHubリポジトリからコードをチェックアウトする
• Pythonのランタイムをセットアップする
• 静的解析ツール（flake8）をインストールする
• flake8でコードスタイルや文法上の問題を検出する

これらの流れを、GitHub Actionsのワークフローとして構築します。

3.2 作業用ブランチの作成

ワークフローファイルを追加する前に、作業用のブランチを作成します。ブランチを分けずにmainブランチに直接コミットしてしまうと、今回作成するワークフロー（mainへのPull Request作成時に動作）のトリガーを試せなくなってしまいます。「Pull Requestを作って → CIが動いて → マージする」という実務的な流れを体験するためにも、作業用ブランチを作っておきましょう。

Visual Studio Codeのターミナルで、以下のgit switchコマンドを実行してfeature/add-ci-workflowというブランチを作ります。-cオプションは新しいブランチを作成して切り替えるという意味です。

git switch -c feature/add-ci-workflow

Switched to a new branch 'feature/add-ci-workflow'と表示されていれば、ここまでの操作は完了です。

3.3 ワークフローファイルの作成

ブランチの準備ができたので、GitHub Actionsのワークフローファイルを作成していきます。GitHub Actionsのワークフローは、リポジトリ内の.github/workflowsフォルダに配置したYAMLファイルで定義します。GitHubがこのフォルダ内のYAMLファイルを自動的に検出してワークフローとして認識する仕組みになっているため、このルールに沿ってファイルを作成します。

今回はcode-check.ymlというファイル名でワークフローを作成します。

devopscamp-ci-handson/
└── .github/
    └── workflows/
        └── code-check.yml  ← このファイルを作成

作成したファイルに以下の内容を記述して保存します。

name: Python Code Check

on:
  pull_request:
    branches:
      - main

jobs:
  python-lint:
    name: Run python-lint
    runs-on: ubuntu-latest

    steps:
      # ソースコードのチェックアウト
      - name: Checkout code
        uses: actions/checkout@v5

      # Python環境をセットアップ
      - name: Set up Python
        uses: actions/setup-python@v6
        with:
          python-version: '3.11'

      # 静的解析ツールをインストール
      - name: Install flake8
        run: pip install flake8

      # flake8で静的解析を実行
      - name: Run flake8
        run: flake8 .

3.4 ワークフローの説明

作成したワークフローの中身を解説します。

名称

name: Python Code Check

ワークフローの名称として、Python Code Checkという名前をつけています。GitHub Actionsの画面ではこの名前でワークフローが一覧表示されます。

トリガー

on:
  pull_request:
    branches:
      - main

トリガーとして、mainブランチに対してPull Requestが作成された時に起動するように設定しています。Pull Requestの作成時だけでなく、Pull Requestに対して追加のコミットがPushされたときにも再実行されます。

ジョブ

jobs:
  python-lint:
    name: Run python-lint
    runs-on: ubuntu-latest

ジョブとして、python-lintというジョブを定義しています。名前にRun python-lint、ランナーとしてubuntu-latestを指定しているため、Ubuntuの最新のランナー環境で動作します。

ステップ1：コードのチェックアウト

- name: Checkout code
  uses: actions/checkout@v5

Pull Requestをトリガーに実行された場合、GitHubは自動的にマージ先（例: main）とPull Request元（例: featureブランチ）を一時的にマージした「仮のマージコミット」を作成し、それをチェックアウトします。そのため、このステップでは、mainブランチやfeatureブランチそのものではなく、両者を統合した一時的なマージ結果が実行環境に展開されます。実際のmainブランチへのマージはこの時点ではまだ行われていません。

actions/checkout@v5に対する詳細は、こちらのGitHubリポジトリに記載されています。

actions/checkout

ステップ2：Pythonのセットアップ

- name: Set up Python
  uses: actions/setup-python@v6
  with:
    python-version: '3.11'

Pythonのランタイムをセットアップします。flake8はPythonで動作するツールのため、これを実行するにはCI環境にPythonランタイムがインストールされている必要があります。actions/setup-pythonアクションを使用することで、指定したバージョンのPythonランタイムを簡単にインストールできます。ここでは3.11を指定しています。

actions/setup-python@v6に対する詳細は、こちらのGitHubリポジトリに記載されています。

actions/setup-python

ステップ3：静的解析ツールのインストール

- name: Install flake8
  run: pip install flake8

pip install flake8で、静的解析ツールのflake8をインストールします。

ステップ4：flake8の実行

- name: Run flake8
  run: flake8 .

flake8 .コマンドで、カレントディレクトリ配下のすべてのPythonコードに対してコードスタイルや文法上の問題を検出します。未使用のインポートや不適切なインデント、長すぎる行などを警告してくれます。

解析結果は、GitHub Actionsの実行結果として表示されます。

3.5 動作確認

ワークフローファイルの作成が完了しました。ただし、ローカルにファイルを作成しただけではGitHub Actionsは動作しません。GitHub ActionsはGitHub上のリポジトリに対して動作する仕組みのため、作成したワークフローファイルをGitHubにPushしてはじめて認識されます。ここでは、ファイルをPushしてPull Requestを作成し、実際にワークフローが動くかを確認します。

サンプルコードのcalculator.pyには意図的にimport os（未使用のインポート）を入れています。また、コードブロックをコピーして貼り付けた場合、ファイルの末尾に改行が入らないことがあります。これらの問題がflake8で検出されることを確認した上で、修正して正常終了させるまでの一連の流れを体験します。

GitHubへのPush

まず、今回作成した内容をGitHubにPushしていきます。Visual Studio Codeのターミナルで、以下のコマンドを1つずつ実行します。

ファイルをステージングします。

git add .

コミットします。

git commit -m "add lint workflow"

Pushします。

git push origin feature/add-ci-workflow

Pull Requestの作成

コードのPushが完了しましたが、今回作成したワークフローは「mainブランチへのPull Requestが作成された時」に起動するように設定しているため、ワークフローを動かすにはPull Requestを作成する必要があります。続いて、Pull Requestの作成を行います。

GitHubのリポジトリページを開き、Pull requestsタブをクリックします。

New pull requestのボタンをクリックします。

ブランチとして、左側のbaseにmain、右側のcompareにfeature/add-ci-workflowを選択した上で、Create pull requestをクリックします。

タイトルと説明欄はそのままで問題ありません。さらにCreate pull requestをクリックします。

警告の確認

Pull Requestの画面が開いたら、中央部分にPython Code Check / Run python-lintのワークフローが実行されていることが読み取れます。ワークフロー名をクリックすると、実行状況の詳細画面が開きます。

しばらくすると、実行結果がエラーになり、赤いバツマークが表示されます。

エラーとなっているRun flake8のステップを開くと、以下のような警告が表示されています。

./calculator.py:1:1: F401 'os' imported but unused
./calculator.py:3:1: E302 expected 2 blank lines, found 1
./calculator.py:8:17: W292 no newline at end of file

それぞれの警告の意味は以下のとおりです。

F401 'os' imported but unused

import osでインポートしていますが、コード内でosが一度も使われていません。未使用のインポートはコードの可読性を下げるため、削除すべきです。

E302 expected 2 blank lines, found 1

PEP 8では、トップレベルの関数定義の前には2行の空行を入れるルールがあります。import osとdef addの間の空行が1行しかないため、この警告が出ています。import osを削除すれば、この警告も一緒に解消されます。

W292 no newline at end of file

ファイルの末尾に改行がありません。PEP 8やPOSIXの標準では、テキストファイルの末尾には改行を入れるルールがあります。

Pull Requestの画面を見ても赤いバツが付いています。このように、CIによって「問題のあるコードが混入しそうになったら、自動で気付ける」というフィードバックを得られます。これがCIの最も大きなメリットです。

警告の修正

警告の原因がわかったので、コードを修正していきます。Visual Studio Codeでcalculator.pyを開き、以下の2点を修正します。

• 先頭のimport osの行と、その下の空行を削除する（F401とE302が解消される）
• ファイルの末尾（return a - bの行末）でEnterキーを1回押して改行を入れる（W292が解消される）

修正したら、GitHubにPushします。

git add .

git commit -m "fix lint errors"

git push origin feature/add-ci-workflow

正常終了の確認

Pull Requestの画面で、Python Code Checkのワークフローが再実行されます。しばらく待つと、ワークフローが正常終了します。Run flake8のステップ部分を展開すると、警告が出ずに静的解析が正常終了していることが確認できます。

Pull Requestの画面に戻ると、緑のチェックマークが付いています。これが「静的解析をパスした」状態です。

「問題のあるコードをPush → CIがエラーを検知 → 修正してPush → CIが正常終了」というサイクルを体験できました。実務でもこの流れの繰り返しで、コードの品質を保っていきます。ここまでの操作が完了です。

4. 自動テストの組み込み

静的解析の次は、CIに自動テストを組み込みます。静的解析ではコードのスタイルや構文上の問題を検出できますが、アプリケーションが期待どおりに動作するかどうかは確認できません。自動テストを組み込むことで、コードの振る舞いが正しいことを自動的に検証できるようになります。

4.1 自動テストの流れ

今回は、pytestを使ったテストをGitHub Actionsのワークフローに組み込みます。先ほどと同じく、mainブランチへのPull Requestが作成された際にワークフローが実行されるように設定します。

処理の流れは以下のとおりです。

• GitHubリポジトリからコードをチェックアウトする
• Pythonのランタイムをセットアップする
• テストツール（pytest）をインストールする
• pytestでテストを実行する

これらの流れを、先ほど作成したcode-check.ymlにジョブとして追加します。別のワークフローファイルを新しく作るのではなく、同じファイル内にジョブを追加する形にする理由は、「Pull Request作成時に静的解析と自動テストの両方を同時に走らせる」という要件を最もシンプルに実現できるためです。

1つのワークフローファイルに複数のジョブを定義すると、指定がない限りそれらのジョブは並列実行されます。並列で動かすことで、直列で順番に動かすよりもフィードバックを早く得られます。

pytestの基本的な書き方や使い方については、Pythonで自動テストをしよう で詳しく解説しています。

4.2 テストコードの作成

自動テストをCIで実行するためには、テスト対象のコードに加えて、テストコードがリポジトリに存在している必要があります。ここでは、calculator.pyの関数をテストするコードを作成します。

リポジトリ直下にtest_calculator.pyというファイルを作成します。

devopscamp-ci-handson/
├── .github/
│   └── workflows/
│       └── code-check.yml
├── calculator.py
└── test_calculator.py  ← このファイルを作成

作成したファイルに以下の内容を記述して保存します。

from calculator import add, subtract


def test_add():
    assert add(1, 2) == 3
    assert add(-1, 1) == 0


def test_subtract():
    assert subtract(5, 3) == 2
    assert subtract(0, 0) == 0

このファイルには、calculator.pyで定義したaddとsubtractの2つの関数をpytestで検証するテストコードを記述しています。それぞれの関数に対して、正の数・負の数・ゼロなどのパターンで期待どおりの結果が返ることを確認しています。

pytestの基本的な書き方については、Pythonで自動テストをしよう で詳しく解説しています。

4.3 ジョブの追加

それでは、code-check.ymlにテスト用のジョブを追加します。Visual Studio Codeでcode-check.ymlを開き、既存のpython-lintジョブの下に以下のpython-testジョブを追記してください。

name: Python Code Check

on:
  pull_request:
    branches:
      - main

jobs:
  python-lint:
    name: Run python-lint
    runs-on: ubuntu-latest

    steps:
      # ソースコードのチェックアウト
      - name: Checkout code
        uses: actions/checkout@v5

      # Python環境をセットアップ
      - name: Set up Python
        uses: actions/setup-python@v6
        with:
          python-version: '3.11'

      # 静的解析ツールをインストール
      - name: Install flake8
        run: pip install flake8

      # flake8で静的解析を実行
      - name: Run flake8
        run: flake8 .

  python-test:
    name: Run python-test
    runs-on: ubuntu-latest

    steps:
      # ソースコードのチェックアウト
      - name: Checkout code
        uses: actions/checkout@v5

      # Python環境をセットアップ
      - name: Set up Python
        uses: actions/setup-python@v6
        with:
          python-version: '3.11'

      # テストツールをインストール
      - name: Install pytest
        run: pip install pytest

      # pytestでテストを実行
      - name: Run pytest
        run: pytest -v

4.4 ジョブの説明

追加したジョブを解説します。

python-test:
  name: Run python-test
  runs-on: ubuntu-latest

ジョブとして、python-testというジョブを定義しています。名前にRun python-test、ランナーとしてubuntu-latestを指定しているため、Ubuntuの最新のランナー環境で動作します。

また、python-lintジョブとpython-testジョブの間には前後関係を指定していないため、これらのジョブは並列で実行されます。

ステップ1：コードのチェックアウト

- name: Checkout code
  uses: actions/checkout@v5

静的解析のジョブと同様に、Pull Requestの仮のマージコミットをチェックアウトします。

ステップ2：Pythonのセットアップ

- name: Set up Python
  uses: actions/setup-python@v6
  with:
    python-version: '3.11'

pytestコマンドを実行するにはCI環境にPythonランタイムがインストールされている必要があります。actions/setup-pythonアクションで、バージョン3.11のPythonランタイムをインストールしています。

ステップ3：テストツールのインストール

- name: Install pytest
  run: pip install pytest

pip install pytestで、テストフレームワークのpytestをインストールします。

ステップ4：テストの実行

- name: Run pytest
  run: pytest -v

pytest -vコマンドで、カレントディレクトリ配下のすべてのテストファイルを実行します。pytestはtest_で始まるファイル名とtest_で始まる関数名を自動で探し出して実行してくれるため、特にファイル指定は不要です。-vオプションを付けることで、詳細なテスト結果が出力されます。

4.5 動作確認（正常ケース）

ジョブの追加ができたので、再びGitHubにPushして動作を確認します。すでにPull Requestを作成済みなので、Pushするだけで先ほどのワークフローが再実行され、追加した自動テストのジョブも一緒に動きます。

GitHubへのPush

Visual Studio Codeのターミナルで、以下のコマンドを1つずつ実行します。

git add .

git commit -m "add pytest job"

git push origin feature/add-ci-workflow

ワークフローの実行確認

既にPull Requestが作成されているため、Pushするとワークフローが再実行されます。

Pull Requestの画面を開くと、Python Code Check / Run python-lintとPython Code Check / Run python-testの2つのジョブが並列に実行されていることが確認できます。

しばらく待つと、両方のジョブが正常終了します。

python-testの実行結果を開き、Run pytestのステップ部分を展開すると、test_addとtest_subtractの2つのテストがパスしていることが読み取れます。

Pull Requestの画面に戻ると、両方のジョブに緑のチェックマークが付いています。これが「静的解析と自動テストの両方をパスした」状態です。ここまでの操作が完了です。

4.6 動作確認（エラー発生時）

静的解析のときと同様、「テストが失敗したときにワークフローがちゃんと失敗扱いになる」ことも確認しておきます。テストが失敗してもワークフローが通ってしまうと、バグ入りのコードがマージされてしまうため、このチェックは重要です。

コードの修正

Visual Studio Codeでtest_calculator.pyを開き、test_add関数のアサーションを以下のように変更します。

def test_add():
    assert add(1, 2) == 4  # ← 期待値をわざと間違える
    assert add(-1, 1) == 0

add(1, 2)は本来3を返しますが、期待値を4に変更することで、実際の値と一致しなくなり、テストが失敗します。

GitHubへのPush

ファイルを保存したら、再びGitHubにPushします。

git add .

git commit -m "break test for error check"

git push origin feature/add-ci-workflow

ワークフローの実行確認

Pull Requestの画面を開くと、ワークフローが再実行されています。しばらくすると、python-testのジョブがエラーになり、赤いバツマークが表示されます。

エラーとなっているRun pytestのステップを開くと、アサーションエラーのメッセージが表示されています。実際の値は3ですが、期待値として4を指定したため、テストが失敗しています。pytestの実行が失敗するとGitHub Actionsのワークフローも失敗するため、これは正常な動作です。

一方で、python-lintのジョブは引き続き緑のチェックのままです。これは「静的解析ではテスト期待値のミスを検知できない（テストの期待値は文法的には正しいため）」ことを示しており、静的解析と自動テストはそれぞれ異なる役割を持つ相補的な仕組みであることが実感できます。

テストの失敗を確認できたので、ここまでの操作は完了です。

5. 不要リソースの削除

この章ではAWSリソースを使用していないため、費用は発生していません。ただし、作成したGitHubリポジトリが不要になった場合は、以下の手順で削除しておきましょう。リポジトリを残しておきたい場合、この手順は省略して問題ありません。

GitHubのdevopscamp-ci-handsonリポジトリのページを開きます。

Settingsタブをクリックし、画面を一番下までスクロールします。

Danger ZoneのセクションにあるDelete this repositoryボタンをクリックします。

確認画面が表示されるので、案内に沿ってリポジトリ名を入力し、削除を実行します。

リポジトリ一覧からdevopscamp-ci-handsonが消えていれば、削除完了です。

6. まとめ

この章では、GitHub Actionsを使った静的解析と自動テストの自動実行を体験しました。

• 空のGitHubリポジトリを起点に、シンプルなPythonコードを配置してCIの土台を用意できる
• Pull Requestをトリガーに、ワークフローを起動する構成にできる
• flake8 を使った静的解析を、ワークフローの1ジョブとして自動実行できる
• pytest を使った自動テストを、ワークフローの1ジョブとして自動実行できる
• 1つのワークフローファイル内に複数ジョブを定義し、並列実行できる構成にできる
• わざとコードを壊してCI失敗を再現し、静的解析・テストのフィードバックループが機能していることを確認できる

次の章では、GitHub ActionsからコンテナのビルドとECS/Fargateへのデプロイを自動化する流れをハンズオン形式で体験します。