【自動化の魔法】GitHub Actions で「壊れたコードをマージさせない」最強の CI/CD パイプラインを構築する
82日目は「MSW」を使って、API通信という不確実な要素をテストで制御する方法を学びました。
本日83日目は、これまで学んだ「ビルド」「テスト」「デプロイ」というバラバラの作業を一本の線でつなぐ、「GitHub Actions による CI/CD の自動化」を学習します。
「プルリクエストを作ると自動でテストが走り、通ったら自動でデプロイされる」――そんなプロの開発現場の当たり前を自分のものにしましょう!
はじめに:テストを書くだけで終わっていませんか?
テストを書いても、実行し忘れてバグをマージしてしまったら意味がありません。
「人間は忘れる。だから機械にやらせる」
これがモダンな開発の鉄則です。GitHub Actions を使えば、GitHubにコードをプッシュした瞬間、裏側で勝手にテストやビルドを実行してくれます。
💡 1. CI/CD とは何か?
CI (Continuous Integration): 継続的インテグレーション。コードを合体させるたびに、自動でビルドとテストを実行して「壊れていないか」を確認します。
CD (Continuous Deployment): 継続的デプロイ。テストが通った安全なコードだけを、自動で本番環境(Vercelなど)へ公開します。
💡 2. ワークフロー(Workflow)を定義する
GitHubリポジトリの .github/workflows/ フォルダに YAML 形式のファイルを作成します。これが「GitHub Actions への指示書」になります。
💻 実装例:ci.yml (テストを自動実行する設定)
name: Test and Build Check
on:
push:
branches: [ "main" ]
pull_request:
branches: [ "main" ]
jobs:
build:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4 # 💡 コードを取得
- name: Install dependencies
run: npm ci # 💡 ライブラリをインストール
- name: Run Tests
run: npm test # 💡 テストを実行!
- name: Build Check
run: npm run build # 💡 ビルドが通るか確認!
💡 3. GitHub Actions の凄み
プルリクエストが「守護」される: テストに失敗したプルリクエストには「❌」が付き、マージを禁止する設定ができます。
実行環境を汚さない: 毎回クリーンな Linux サーバー(仮想マシン)上で実行されるため、「自分のPCでは動いたのに」という事故が防げます。
Vercelとの親和性: 実は Vercel へのデプロイも、裏側でこの仕組みに近いことが行われています。
📝 83日目のまとめと課題
✅ 本日の習得ポイント
自動化の恩恵: 面倒なチェック作業を自動化し、本質的な開発に集中できる。
YAMLファイル: GitHub Actions を動かすための共通言語。
品質の担保: 「テストを通らないコードは世に出さない」という仕組み作り。
📝 83日目の課題
自分の GitHub リポジトリに .github/workflows/ci.yml を作成してみましょう。
わざとテストを失敗させるコードを書いてプッシュし、GitHub 上で「❌(Failed)」が出るか確認してみてください。
テストが成功した時の「緑のチェックマーク」を見て、達成感を味わいましょう!
もっとGitHubAction学びたい人はここから!
#エンジニアと繋がりたい #プログラミング学習 #React #100DaysOfCode #今日の積み上げ #GitHubActions #CICD
