🔧 GitHub Actionsとは
GitHub が提供する 自動化サービス です。
リポジトリに変更があったときに、あらかじめ決めた手順（ワークフロー）を自動で実行してくれます。
💡 具体的にできること
テストの自動実行
→ プルリクエストが出たら自動でユニットテストを回す
ビルド & デプロイ
→ main ブランチにマージしたら自動でサーバーやクラウドにデプロイ
CI/CD（継続的インテグレーション／継続的デリバリー） の基盤になる
定期実行（cron的なジョブ）
→ 毎日夜0時にスクリプトを回す
外部サービスとの連携
→ Slack に通知を送る、Dockerイメージをビルドして公開する など
サンプルコード
-
.github/workflows/ ディレクトリに YAMLファイル を置く
-
その中に「いつ」「何を」するかを書く
-
例: mainブランチに push されたらテストを回す
# .github/workflows/python-ci.yml
# このファイルは GitHub Actions のワークフロー定義です。
# 目的:
# - Pythonプロジェクトのテストを push/pr のたびに自動実行する
# - 開発者がローカルで動かさなくても、GitHubが代わりにチェックしてくれる
# - CI/CD の "CI" 部分にあたる
name: Python CI # ワークフローの名前（GitHubのActions画面に表示される）
# ---- トリガー設定 ----
on:
push: # コードが push されたときに実行
branches: [ "main" ] # mainブランチ限定（任意で調整可能）
pull_request: # プルリクエストが作られたときにも実行
branches: [ "main" ] # mainブランチ向けのPRが対象
# ---- 実行するジョブ定義 ----
jobs:
build-and-test: # ジョブのID（任意の名前）
runs-on: ubuntu-latest # GitHubが用意したUbuntu仮想マシンで実行
# 他に macos-latest / windows-latest も選べる
steps: # ジョブの中で順番に実行する「ステップ」のリスト
# -------------------
- name: Checkout repository
uses: actions/checkout@v3 # (公式Action)
# リポジトリのソースコードを仮想マシンに取得する
# → これがないとテスト対象のコードが存在しない状態になる
# -------------------
- name: Setup Python
uses: actions/setup-python@v4 # (公式Action)
with:
python-version: '3.11' # 使用するPythonバージョンを指定
# runnerには複数Pythonが入っているため、明示するのがベストプラクティス
# -------------------
- name: Install dependencies
run: |
python -m pip install --upgrade pip # pipを最新化
pip install -r requirements.txt # プロジェクトの依存ライブラリをインストール
# （requirements.txtがある前提）
# -------------------
- name: Run tests
run: |
pytest # pytestで単体テストを実行
# エラーが出ればジョブ全体が失敗扱いになる
✅ まとめ
GitHub Actions = GitHub内で動く自動実行システム
「pushしたらテスト」「マージしたらデプロイ」みたいなルールを設定できる
無料アカウントでも利用可能（公開リポジトリなら無制限無料）
AWSでこういうテストをしていたとおもうが、後でこういう機能がでてきたのか？
🔙 AWSでの従来のやり方
GitHub Actions が登場する前、AWS では例えばこんな構成でテスト・デプロイをしていました：
AWS CodePipeline
→ パイプライン（ビルド → テスト → デプロイの流れ）を定義
AWS CodeBuild
→ 実際にテストやビルドを実行するマシン
AWS CodeDeploy
→ EC2やECSにデプロイするサービス
つまり「AWSにソースを置いて、AWSのCI/CDサービスを組み合わせて使う」スタイルでした。
これだとリポジトリは GitHub にあっても、テストやデプロイは AWS 側で管理する必要がありました。
🆕 GitHub Actionsの登場（2019頃）
GitHub が「リポジトリ管理とCI/CDを一体化」して出してきたのが GitHub Actions
これによって
GitHubにpushする
GitHub内でそのままビルド・テスト
必要ならAWS/GCP/Azureにデプロイ
が GitHubだけで完結できるようになりました。
📈 違い・進化のポイント
AWS CodePipeline/CodeBuild
AWSサービスとの統合が強み（S3, Lambda, ECS, EKS などに直結）
ただし設定がやや重い、YAMLも独自仕様
GitHub Actions
GitHubに統合 → Pull Request / Issue と自然に連携
Marketplaceに大量の公式・非公式Actionがあり、部品を組み合わせやすい
「GitHubがCI/CDも持つ」ことで開発者の体験が一気に楽になった
✅ まとめ
昔（AWSでやってた時代）
GitHubにpush → CodePipelineがトリガー → CodeBuildでテスト → CodeDeployで反映
今（GitHub Actions登場後）
GitHubにpush → GitHub Actionsがトリガー → GitHub内でテスト/ビルド → 必要ならAWSへデプロイ
👉 要するに、AWSが先に持ってたCI/CDの考え方を、GitHubが自分のプラットフォームに後から取り込んだ という流れです。