「手動でテストして、手動でデプロイして、ミスに怯えて夜も眠れない……」そんな時代はもう終わりです。
こんにちは。DevOpsの深淵を覗き続けてきたエンジニアとして、今日は君に「GitHub Actions」という魔法の杖を授けようと思います。これをマスターすれば、君がコードを書いてGitHubにプッシュするだけで、テストからリリースまでが自動で完結するようになります。
今回は、ただの「動くもの」を作るのではなく、「プロフェッショナルが現場で使っている設計思想」を交えて解説します。準備はいいかな？
—
1. GitHub Actionsとは何か？
一言で言えば、「GitHubという巨大な屋根の下で動く、君専用のフルタイム自動作業員」です。
これまで君が手元でやっていた「ターミナルを開く→`npm test`と打つ→Vercelにデプロイする」という一連の作業を、クラウド上の仮想マシンが勝手に代行してくれます。しかも、君が眠っている間も、土日も休まずに。
2. 最初の「HelloWorld」：パイプラインの心臓部
GitHub Actionsは、リポジトリの `.github/workflows/` というディレクトリにYAMLファイルを置くだけで動き出します。まずは、コードをプッシュするたびに「Hello World」とつぶやく、最もシンプルなパイプラインを作ってみましょう。
`.github/workflows/main.yml` を作成してください。
name: CI Pipeline # パイプラインの名前
on:
push:
branches: [ main ] # mainブランチにプッシュされた時だけ動く
jobs:
build:
runs-on: ubuntu-latest # 最新のUbuntu環境を借りる
steps:
- name: コードをチェックアウト
uses: actions/checkout@v4 # リポジトリのコードを仮想マシンにダウンロード
- name: Hello Worldを実行
run: echo “こんにちは！自動化の世界へようこそ。”
これをコミットしてプッシュしてみてください。GitHubの「Actions」タブを開くと、君の命令に従って仮想マシンが立ち上がり、ログが出力されているはずです。これが自動化の第一歩です。
—
3. 本番環境のための「テスト＆デプロイ」自動化
ここからが本題です。現場では、テストが通らないコードを絶対に本番に出してはいけません。以下の構成は、「テストが通ったときだけデプロイする」という鉄則をコード化したものです。
現場で愛用される構成例 (Node.js + Vercel)
name: Deploy to Production
on:
push:
branches: [ main ]
jobs:
test:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- name: Node.jsのセットアップ
uses: actions/setup-node@v4
with: { node-version: ’20’ }
- run: npm install
- run: npm test # ここでテスト！失敗すれば以降のデプロイは実行されません
deploy:
needs: test # testジョブが成功した時だけ実行される（これが重要！）
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- name: Vercelにデプロイ
uses: amondnet/vercel-action@v25
with:
vercel-token: ${{ secrets.VERCEL_TOKEN }} # 機密情報はGitHub Secretsで管理！
vercel-org-id: ${{ secrets.ORG_ID }}
vercel-project-id: ${{ secrets.PROJECT_ID }}
なぜこの書き方が「プロ」なのか？
1. `needs: test` の原則: テストに失敗したコードをデプロイするのは、火事の家の中に荷物を運び込むようなもの。この記述で、自動化の安全性を確保しています。
2. `secrets`の活用: Vercelのトークンなど、絶対に公開してはいけない値は直接YAMLに書かず、GitHubの「Settings > Secrets」に隠す。これがセキュリティの基本です。
—
4. 現場のシニアから君へのアドバイス
GitHub Actionsを使い始めると、最初は楽しくてあれもこれも自動化したくなるはずです。でも、これだけは覚えておいてください。
- 「失敗」を恐れないで: パイプラインが失敗するのは、君のコードにバグがあるか、パイプラインの設計が甘いからです。それは「悪いこと」ではなく、「バグが本番に行くのを防いでくれた」という成功体験です。
- 高速化を意識する: パイプラインは遅いとストレスになります。`npm install` の後に `actions/cache@v4` を使って依存関係をキャッシュするなど、最適化の余地は常にあります。
さあ、次は君の番だ
ここまで読んだ君なら、もう手動デプロイの苦しみからは解放されたも同然です。まずは今のプロジェクトに `.github/workflows/` を作り、`npm test` を走らせることから始めてみてください。
「毎日の作業が劇的に楽になる」その感覚を、ぜひ君自身の手で掴んでください。もし詰まったら、いつでも戻ってきてくださいね。君の自動化ライフを心から応援しています。