push を自動化に繋げる

テクノロジ系／ cicd — CI/CD 基礎 (Git 視点)

push を自動化に繋げる

— CI/CD と GitHub Actions —

このトピックが終わると

CI/CD が「何を自動化するか」説明できる
GitHub Actions の YAML の基本構造を読める
GitHub Pages に自動デプロイできる
push → 公開までの流れを自分で作れる

章 1 — 手動デプロイの何が問題か

手動デプロイのリスク

コードを書く → テスト → ビルド → サーバーに送る → 確認

         ↑           ↑          ↑
      忘れがち    手順ミス    「あれ、本番に反映された？」

問題	内容
手順のミス	コマンドの打ち間違い
属人化	担当者しか手順を知らない
デプロイ漏れ	「押し忘れた」

CI/CD で解決する

push
  └─ 自動でテスト・ビルド・デプロイが走る
       ├─ テスト:  バグを早期発見
       ├─ ビルド:  成果物を生成
       └─ デプロイ: 本番環境に自動反映

「push したら本番に届く」状態を作る。

人間がやることは「コードを書いて push する」だけ。

章 2 — GitHub Actions の仕組み

Actions の構造

.github/
└── workflows/
    └── deploy.yml   ← ここに書く

ここに YAML ファイルを置くだけで動く。

サーバーの設定は不要。

YAML の基本構造

on:               # ← いつ動くか
  push:
    branches: [main]

jobs:             # ← 何をするか
  deploy:
    runs-on: ubuntu-latest   # 実行環境
    steps:
      - uses: actions/checkout@v5  # コードを取得
      - run: npm run build         # ビルド
      - run: ./deploy.sh           # デプロイ

キーワードの意味

キーワード	意味
`on`	トリガー（いつ動くか）
`jobs`	実行する処理のまとまり
`runs-on`	実行環境（OS）
`steps`	処理の手順（上から順に実行）
`uses`	既存の Action を再利用
`run`	シェルコマンドを実行

章 3 — GitHub Pages で試す

なぜ GitHub Pages から始めるか

GitHub Pages	AWS / Azure
アカウント	GitHub のみ	別途必要
シークレット設定	不要	必要
費用	無料	要確認
難易度	低い	高い

最小コストで CI/CD の流れを体験できる。

GitHub Pages デプロイの YAML — 権限

permissions:
  pages: write
  id-token: write

permissions で Pages への書き込み権限を明示する。

これを書かないと「権限不足」で 403 になる。

GitHub Pages デプロイの YAML — 処理

jobs:
  deploy:
    environment:
      name: github-pages
      url: ${{ steps.deployment.outputs.page_url }}
    steps:
      - uses: actions/checkout@v5
      - uses: actions/upload-pages-artifact@v3
        with:
          path: '.'          # デプロイするフォルダ
      - id: deployment
        uses: actions/deploy-pages@v4

upload-pages-artifact で公開対象を集め、 deploy-pages で実反映する。

有効化の手順

リポジトリの Settings → Pages を開く
Source を 「GitHub Actions」 に変更
.github/workflows/deploy.yml を push
Actions タブでジョブの実行を確認
表示された URL にアクセス

push から公開までの流れ

git push
  ↓
GitHub Actions が起動（自動）
  ↓
checkout → upload → deploy（数秒〜数分）
  ↓
https://username.github.io/repo-name/ で公開

Actions タブでログをリアルタイムで確認できる。

まとめ

概念	一言で
CI	push のたびにテスト・ビルドを自動実行
CD	ビルド成果物を自動でデプロイ
GitHub Actions	`.github/workflows/` に YAML を置くだけ
GitHub Pages	静的サイトを無料で自動デプロイ

「push したら届く」仕組みが整うと、デプロイが怖くなくなる。

章 4 — pytest を CI に組み込む

ここからは GitHub Pages を離れ、「テストを自動で動かす」形の CI を扱う。

例題: 緑になる CI を作る — 起動条件

.github/workflows/ci.yml の前半 (= いつ動くか):

name: CI
on:
  push:
    branches: [ main ]
  pull_request:
    branches: [ main ]

main への push と PR の更新で発火する。

例題: 緑になる CI を作る — 実行内容

後半 (= 何を実行するか):

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v5
      - uses: actions/setup-python@v6
        with:
          python-version: "3.11"
      - run: pip install -r requirements.txt
      - run: pytest -q

push して Actions タブで 緑 ✓ になれば例題は OK。

例題: 成功 run の実画面

!w:780

Status: Success / check が緑✓。

Actions タブの 3 状態

色	意味	次にすること
緑 ✓	全 step 成功	マージしてよい
赤 ✗	どこかの step が失敗	ログを読んで直す
黄 ●	実行中 / runner 待ち	待つ

赤を開く順番: run → 失敗 job → 失敗 step → エラーの最後の行。

Actions タブ実画面 (赤と緑が混在)

!w:780

失敗 run の job ビュー

!w:720

失敗した step だけが ✗。 step 名を絞り込んでから本文を開く。

演習 1: YAML を 3 つに分ける (読解)

下の YAML を見て、 1 行ずつ答える。

on:
  pull_request:
    branches: [ main ]
jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v5
      - run: pytest -q

演習 1: 答えること

いつ動くか
どの環境で動くか
何を実行するか

> push では動かないことに気づくのがポイント。

演習 2: 失敗ログを読む (読解)

FAILED test_main.py::test_health
E assert {'status': 'ok'} == {'status': 'down'}

失敗テストは?
実際の値 / 期待の値は?
コードと test、どちらを直す? (仕様による)

演習 3: わざと壊して直す (修正)

test_main.py の期待値を "ok" → "down" に書き換えて push
Actions が赤になることを確認
失敗 step → エラー本文を読む
"ok" に戻して再 push
緑に戻るまで確認

> 「直感で直す」 → 「また失敗」を避けるため、必ずログを 1 回は読んでから直す。

演習 4: schedule を書く (設計)

平日 17:00 JST に動かす設定を書く。

ヒント:

JST = UTC + 9
cron は 分時日月曜日
平日 = 1-5

on.schedule.- cron: の値を 1 行で答える。

CD の最小イメージ

jobs:
  test: { ... }       # CI: pytest

  deploy:
    needs: test        # ← test 緑のときだけ動く
    steps:
      - run: echo "deploy"

needs: を書くと、 CI が赤い間は deploy job は動かない。

「壊れたものを自動で配る」ことを防ぐ最小の安全装置。

演習 5: 統合 (PR → マージ)

新しいブランチで /version エンドポイントとテストを追加
ローカルで pytest -q が緑になることを確認
push → PR 作成
Checks が緑になるのを待つ
main にマージ
main の Actions が緑になることを確認

> 実務での「最低限の 1 サイクル」。ここまで通して「CI/CD が読める・直せる」状態になる。

演習 5: PR Checks の実画面

!w:780

Checks タブを開くと CI run が並ぶ。赤マークなら、緑に戻すまでマージしない。

演習の解答

演習 1

PR が main に向いて作成・更新された時
Ubuntu 最新版
pytest -q を実行
push では動かない

演習 2

test_health が失敗
実際 "ok" / 期待 "down"
仕様 (= main.py) が "ok" を返すなら、 test の期待値が誤り → test を直す

演習 3

失敗 step は Run pytest
期待値を "ok" に戻して push

演習 4

on:
  schedule:
    - cron: "0 8 * * 1-5"
  workflow_dispatch:

UTC 08:00 = JST 17:00。 workflow_dispatch を併記するとデバッグが楽。

演習 5

ローカル 2 passed → push → Checks 緑 → マージ → main 緑、のサイクル
どこかで赤になったら、そこで止めて直す

push を自動化に繋げる