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

このハンズオンでは、GitHub Actionsを使ってPull Request時に静的解析（flake8）と自動テスト（pytest）を自動実行する仕組みについて、実際にハンズオン形式で手を動かしながら体験します。

  • サンプルリポジトリの準備
  • Pull Requestをトリガーに静的解析を自動実行するワークフロー作成
  • 同じワークフローに自動テストを追加するジョブ追加
  • わざとコードを壊してワークフローが失敗する様子を確認

1. 事前準備

Gitの基礎知識を習得していることを前提とします。自信のない方は先に以下の講座を実施してください。

このハンズオンでは、以下のツールやアカウントが必要です。まだ準備できていない場合は、リンク先の手順に沿って準備をお願いします。

また、このハンズオンで扱うflake8とpytestの基本的な使い方は、以下の講座で詳しく解説しています。ローカル環境での使い方を先に理解しておくと、CIに組み込んだときの動きがスムーズに理解できます。

2. ハンズオンの概要

これまでの章では、GitHub Actionsのワークフローの基本構文を学びました。ここからは、CI/CDパイプラインの実践編として「品質チェックを自動化する仕組み」を構築していきます。

CI/CDパイプラインでは、コードが変更されたタイミングで自動的に品質チェックを走らせ、「問題のあるコードがmainブランチにマージされない」ようにするのが基本的な考え方です。その中でも特に重要なのが、静的解析（コードを実行せずにスタイルや構文上の問題を検出する仕組み）と自動テスト（テストコードを実行してアプリケーションの振る舞いを検証する仕組み）の2つです。

このハンズオンでは、PythonのシンプルなサンプルコードをGitHubリポジトリに配置し、Pull Requestを作成するたびに自動でflake8（静的解析）とpytest（自動テスト）が実行されるCI（継続的インテグレーション）の仕組みを構築します。

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

  • 開発者がローカルでコードを修正し、feature用のブランチにコミットする
  • GitHubにPushしてmainブランチ宛てのPull Requestを作成する
  • Pull Requestの作成をトリガーにGitHub Actionsのワークフローが起動する
  • ワークフロー内でflake8ジョブとpytestジョブが並列に実行される
  • 両方のジョブが成功すればPull Requestに緑のチェックが付き、いずれかが失敗すれば赤いバツが付く

このハンズオンを通して、「コードが変更されたら自動的に品質チェックが走る」という、CIの最も基本的な流れを体験できます。

📝 CIとCDとは
CI（Continuous Integration: 継続的インテグレーション）は、コードの変更を頻繁にリポジトリに統合し、その都度自動でビルドやテストを行う開発手法です。CD（Continuous Delivery / Continuous Deployment: 継続的デリバリー / 継続的デプロイメント）は、CIを経た変更を自動的にリリース可能な状態にする、もしくは本番環境まで自動的にデプロイする手法です。このハンズオンで扱うのはCI（静的解析と自動テストの自動化）の部分です。CD（自動ビルド・自動デプロイ）については次の講座で扱います。

3. リポジトリの準備

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

3.1 GitHubで空のリポジトリを作成

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

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

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

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

設定項目 値 設定の基準
Owner ご自身のGitHubアカウント 自分のアカウントで管理するため
Repository name devopscamp-ci-handson ハンズオン用のリポジトリ名
Visibility Public GitHub Actionsの無料実行時間を気にせず使えるため
Initialize this repository with 何もチェックしない 後から自分でファイルをPushするため
💡 ポイント
リポジトリ名は任意ですが、後のハンズオンで参照するため、覚えておきやすい名前にしておきましょう。本ハンズオンではdevopscamp-ci-handsonという名前で進めます。

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

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

3.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）がローカル環境に作成されていれば、ここまでの操作は完了です。

3.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が表示されていれば、ここまでの操作は完了です。

3.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が表示されます。これが表示されていれば、ここまでの操作は完了です。

4. 静的解析の実施

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

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

4.1 静的解析の概要

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

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

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

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

4.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'と表示されていれば、ここまでの操作は完了です。

4.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 .

4.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の実行結果として表示されます。

4.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が正常終了」というサイクルを体験できました。実務でもこの流れの繰り返しで、コードの品質を保っていきます。ここまでの操作が完了です。

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

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

5.1 自動テストの流れ

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

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

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

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

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

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

5.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で検証するテストコードを記述しています。それぞれの関数に対して、正の数・負の数・ゼロなどのパターンで期待どおりの結果が返ることを確認しています。

⚠️ ファイルの末尾に改行が入らない場合
コードをコピーして貼り付けた場合、ファイルの末尾に改行が入らないことがあります。その場合は、test_calculator.pyの最終行（assert subtract(0, 0) == 0）の行末でEnterキーを1回押して改行を入れてから保存してください。

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

5.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

5.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オプションを付けることで、詳細なテスト結果が出力されます。

💡 ポイント
python-lintジョブとpython-testジョブは、それぞれ独立したランナー（実行環境）で動作します。そのため、python-lintでインストールしたflake8はpython-testでは利用できません。ジョブをまたいで環境を共有したい場合は、別の仕組み（アーティファクトなど）が必要ですが、今回のようにそれぞれが独立してツールをインストールする構成が最もシンプルです。

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

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

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

💡 ポイント
実務では、テストのエラーを修正してCIが正常終了した後にPull Requestをマージするのが一般的な流れです。このハンズオンではマージの手順は省略しています。また、現状ではCIが失敗していてもPull Requestをマージできてしまいますが、GitHubのブランチ保護ルールを設定することで、CIが通らない限りマージを禁止することもできます。ブランチ保護ルールについては別の講座で解説します。

6. リソースの削除

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

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

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

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

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

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

7. まとめ

このハンズオンでは、GitHub Actionsを使って静的解析と自動テストを自動実行する仕組みを体験しました。

  • 空のGitHubリポジトリを作成してシンプルなPythonコードを配置できる
  • Pull Requestをトリガーにワークフローを起動できる
  • flake8を使った静的解析をワークフローで自動実行できる
  • pytestを使った自動テストをワークフローで自動実行できる
  • 1つのワークフローファイル内に複数のジョブを定義して並列実行できる
  • わざとコードを壊すことで、ワークフローが失敗することを確認できる
💡 ポイント
このハンズオンでは静的解析ツールとしてFlake8のみを使用しましたが、Pythonで静的解析をしようの講座で学んだBlack（フォーマットチェック）やmypy（型チェック）も、同じ要領でワークフローにジョブとして追加できます。CIでBlackを使う場合はblack --check .（チェックのみ、自動修正しない）、mypyを使う場合はmypy .をジョブとして定義します。実務では、これらを組み合わせて複数の観点からコードの品質をチェックするのが一般的です。