見出し画像

【自動化の魔法】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 の凄み

  1. プルリクエストが「守護」される: テストに失敗したプルリクエストには「❌」が付き、マージを禁止する設定ができます。

  2. 実行環境を汚さない: 毎回クリーンな Linux サーバー(仮想マシン)上で実行されるため、「自分のPCでは動いたのに」という事故が防げます。

  3. Vercelとの親和性: 実は Vercel へのデプロイも、裏側でこの仕組みに近いことが行われています。


📝 83日目のまとめと課題

✅ 本日の習得ポイント

  • 自動化の恩恵: 面倒なチェック作業を自動化し、本質的な開発に集中できる。

  • YAMLファイル: GitHub Actions を動かすための共通言語。

  • 品質の担保: 「テストを通らないコードは世に出さない」という仕組み作り。

📝 83日目の課題

  1. 自分の GitHub リポジトリに .github/workflows/ci.yml を作成してみましょう。

  2. わざとテストを失敗させるコードを書いてプッシュし、GitHub 上で「❌(Failed)」が出るか確認してみてください。

  3. テストが成功した時の「緑のチェックマーク」を見て、達成感を味わいましょう!

もっとGitHubAction学びたい人はここから!

#エンジニアと繋がりたい #プログラミング学習 #React #100DaysOfCode #今日の積み上げ #GitHubActions #CICD

いいなと思ったら応援しよう!