デプロイまで（build → deploy）

導入

テストが通ったら、次は公開（デプロイ）です。ここでは「ビルドしてから、その成果物をデプロイする」2ジョブ構成と、パスワード類を安全に扱う secrets を読み解きます。

説明

build の後に deploy を走らせるワークフローです。

name: Deploy

on:
  push:
    branches: [main]          # main に入ったときだけ本番へ

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: '22'
      - run: npm ci             # 依存をきっちり入れる
      - run: npm run build      # dist/ を生成

  deploy:
    needs: build                # build が成功してから動く
    runs-on: ubuntu-latest
    environment: production     # 本番環境（承認や保護ルールを付けられる）
    steps:
      - uses: actions/checkout@v4
      - run: npm ci
      - run: npm run build
      - run: npx some-deploy-cli deploy
        env:
          API_TOKEN: ${{ secrets.DEPLOY_TOKEN }}   # 秘密情報を注入

新しく出てきた4つの読みどころ：

• needs: build：ジョブの 依存関係。既定でジョブは並行に走りますが、needs を書くと「build が成功してから deploy」と順番を作れます。ビルドが失敗すればデプロイはそもそも動きません。
• environment: production：デプロイ先を「環境」として扱う指定。GitHub 側で「本番へのデプロイは承認が必要」といった保護ルールを付けられます。
• secrets.DEPLOY_TOKEN：API トークンやパスワードは YAML に直接書きません。GitHub のリポジトリ設定に Secrets として登録し、${{ secrets.名前 }} で参照します。ログにも値は表示されません。
• ${{ ... }}：GitHub Actions の 式。secrets や変数を埋め込むための記法です。

flowchart LR
    A["push to main"] --> B["job: build"]
    B -->|needs| C["job: deploy"]
    C --> D["本番へ公開"]
    S["Secrets<br/>(DEPLOY_TOKEN)"] -.注入.-> C

鉄則：パスワード・APIキー・トークンを YAML やコードに直書きしない。必ず Secrets を使う。第1章の .gitignore と同じく、「秘密を履歴に残さない」ための基本作法です。

まとめ

• needs: でジョブの実行順（依存）を作る。
• environment: でデプロイ先に保護ルールを付けられる。
• 秘密情報は secrets に登録し ${{ secrets.名前 }} で参照。直書き厳禁。