Tips - デプロイメントを深堀り

Posted at 2025-12-23

Tips - デプロイメントを深堀り

GitHub Actionsを使ったデプロイメントは、もはや「便利な機能」ではなく、モダンな開発チームにとって必須のインフラストラクチャです。本記事では、GitHub Actionsの公式ドキュメントをもとに、実践的なデプロイメント戦略を体系的に解説します。

1. デプロイメントの基本構造

GitHub Actionsでのデプロイメントは、主に以下の3つの要素で構成されます。

1.1 トリガーの設定

デプロイメントワークフローは、複数のイベントで起動できます。実務では以下の組み合わせが一般的です。

on:
  push:
    branches:
      - main
  pull_request:
    branches:
      - main
  workflow_dispatch:

この設定により、mainブランチへのプッシュ、プルリクエストの操作、手動トリガーに対応できます。

2. Environment（環境）による保護メカニズム

Environmentは単なる環境変数の集合ではなく、デプロイメントを制御する強力な保護層です。

2.1 設定可能な保護ルール

2.1.1 Required Reviewers（必須承認者）

最大6人の承認者を設定でき、そのうち1人が承認すればデプロイが進行します。自己承認を防止する設定も可能です。

deploy:
  runs-on: ubuntu-latest
  environment:
    name: 'production'
    url: ${{ steps.deploy-to-webapp.outputs.webapp-url }}

2.1.2 Wait Timer（待機タイマー）

デプロイ前に指定した分数だけ待機させることで、緊急時のキャンセル猶予を設けられます。

2.1.3 Deployment Branches（デプロイ可能ブランチ）

特定のブランチやタグからのみデプロイを許可することで、意図しないコードのデプロイを防ぎます。

2.2 カスタム保護ルールの実装

GitHub Appsを使って、サードパーティサービスと連携した独自の保護ルールを作成できます。

対応サービス例：

Datadog：モニタリング指標に基づく自動承認
ServiceNow：ITSMチケットの承認状況確認
Honeycomb：オブザーバビリティデータの検証
Sentry：エラー率のチェック

応答までの制限時間は30日間です。タイムアウトするとジョブは自動的に失敗します。

3. Concurrency（並行性制御）

複数のデプロイメントが同時に実行されないよう制御します。

concurrency:
  group: production
  cancel-in-progress: true

この設定により、production環境では最大1つの実行中デプロイと1つの待機中デプロイのみが存在します。cancel-in-progress: trueを指定すると、新しいデプロイが開始された際に待機中のデプロイをキャンセルします。

重要： concurrencyとenvironmentは独立した設定です。同じ環境名を使う必要はありませんが、混乱を避けるため統一することを推奨します。

4. 主要クラウドプラットフォームへのデプロイ実装

4.1 Azure App Serviceへのデプロイ

Azure App Serviceは、Node.js、Python、Java、.NET、PHP、Dockerに対応しています。

4.1.1 共通の前提準備

App Service プランの作成

az appservice plan create \
   --resource-group 自分のリソースグループ \
   --name 自分のプラン名 \
   --is-linux

Webアプリの作成（Node.jsの例）

az webapp create \
    --name 自分のアプリ名 \
    --plan 自分のプラン名 \
    --resource-group 自分のリソースグループ \
    --runtime "NODE|14-lts"

Publish Profileの設定

Azure ポータルからPublish Profileをダウンロードし、AZURE_WEBAPP_PUBLISH_PROFILEという名前でGitHub Secretsに登録します。

4.1.2 ワークフローの標準構造

name: "Azure Web Appへデプロイ"

env:
  AZURE_WEBAPP_NAME: 自分のアプリ名
  NODE_VERSION: '14.x'

on:
  push:
    branches:
      - main

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
    - uses: actions/checkout@v5

    - name: Node.jsのセットアップ
      uses: actions/setup-node@v4
      with:
        node-version: ${{ env.NODE_VERSION }}
        cache: 'npm'

    - name: "インストール、ビルド、テスト"
      run: |
        npm install
        npm run build --if-present
        npm run test --if-present
        
    - name: デプロイ用アーティファクトのアップロード
      uses: actions/upload-artifact@v4
      with:
        name: node-app
        path: .

  deploy:
    runs-on: ubuntu-latest
    needs: build
    environment:
      name: 'production'
      url: ${{ steps.deploy-to-webapp.outputs.webapp-url }}

    steps:
    - name: ビルドジョブからアーティファクトをダウンロード
      uses: actions/download-artifact@v5
      with:
        name: node-app

    - name: 'Azure WebAppへデプロイ'
      id: deploy-to-webapp
      uses: azure/webapps-deploy@85270a1854658d167ab239bce43949edb336fa7c
      with:
        app-name: ${{ env.AZURE_WEBAPP_NAME }}
        publish-profile: ${{ secrets.AZURE_WEBAPP_PUBLISH_PROFILE }}
        package: .

ポイント：

buildジョブとdeployジョブを分離することで、ビルド成果物を明確に管理
アーティファクトの受け渡しにより、ビルド環境とデプロイ環境を分離
environment設定により、デプロイ先URLを自動的にGitHub UI上に表示

4.1.3 言語別の考慮事項

言語/技術	主な考慮事項	追加設定
Python	仮想環境を作成してから依存関係をインストールアーティファクトから`venv/`を除外	`SCM_DO_BUILD_DURING_DEPLOYMENT=1`のアプリ設定が必要
Java	Mavenでビルド（`mvn clean install`） JARファイルのみをアーティファクトとしてアップロード	特になし
.NET	`dotnet publish`でリリースビルドを作成 NuGetパッケージのキャッシュで高速化	特になし
PHP	Composer存在チェックを実装 Composerキャッシュディレクトリを動的に取得	特になし

4.2 Azure Static Web Appへのデプロイ

静的サイト向けの特化型サービスです。

name: "Azure Static Web Appへデプロイ"

env:
  APP_LOCATION: "/"
  API_LOCATION: "api"
  OUTPUT_LOCATION: "build"

on:
  push:
    branches:
      - main
  pull_request:
    types: [opened, synchronize, reopened, closed]
    branches:
      - main

jobs:
  build_and_deploy:
    if: github.event_name == 'push' || (github.event_name == 'pull_request' && github.event.action != 'closed')
    runs-on: ubuntu-latest
    name: "ビルドとデプロイ"
    steps:
      - uses: actions/checkout@v5
        with:
          submodules: true
          
      - name: "ビルドとデプロイ"
        uses: Azure/static-web-apps-deploy@1a947af9992250f3bc2e68ad0754c0b0c11566c9
        with:
          azure_static_web_apps_api_token: ${{ secrets.AZURE_STATIC_WEB_APPS_API_TOKEN }}
          repo_token: ${{ secrets.GITHUB_TOKEN }}
          action: "upload"
          app_location: ${{ env.APP_LOCATION }}
          api_location: ${{ env.API_LOCATION }}
          output_location: ${{ env.OUTPUT_LOCATION }}

  close_pull_request:
    if: github.event_name == 'pull_request' && github.event.action == 'closed'
    runs-on: ubuntu-latest
    name: "プルリクエストのクローズ"
    steps:
      - name: "プルリクエストをクローズ"
        uses: Azure/static-web-apps-deploy@1a947af9992250f3bc2e68ad0754c0b0c11566c9
        with:
          azure_static_web_apps_api_token: ${{ secrets.AZURE_STATIC_WEB_APPS_API_TOKEN }}
          action: "close"

特徴：

プルリクエストごとにプレビュー環境を自動作成
PRクローズ時に自動的に環境を削除
APIバックエンドの統合サポート

4.3 Amazon ECSへのデプロイ

コンテナベースのデプロイメントです。

4.3.1 前提準備

# ECRリポジトリの作成
aws ecr create-repository \
    --repository-name 自分のリポジトリ名 \
    --region ap-northeast-1

# タスク定義のテンプレート生成
aws ecs register-task-definition --generate-cli-skeleton

生成されたタスク定義をリポジトリに.aws/task-definition.jsonとして保存します。

4.3.2 ワークフロー実装

name: "Amazon ECSへデプロイ"

on:
  push:
    branches:
      - main

env:
  AWS_REGION: ap-northeast-1
  ECR_REPOSITORY: 自分のリポジトリ名
  ECS_SERVICE: 自分のサービス名
  ECS_CLUSTER: 自分のクラスター名
  ECS_TASK_DEFINITION: .aws/task-definition.json
  CONTAINER_NAME: 自分のコンテナ名

jobs:
  deploy:
    name: "デプロイ"
    runs-on: ubuntu-latest
    environment: production

    steps:
      - name: "チェックアウト"
        uses: actions/checkout@v5

      - name: "AWS認証情報の設定"
        uses: aws-actions/configure-aws-credentials@0e613a0980cbf65ed5b322eb7a1e075d28913a83
        with:
          aws-access-key-id: ${{ secrets.AWS_ACCESS_KEY_ID }}
          aws-secret-access-key: ${{ secrets.AWS_SECRET_ACCESS_KEY }}
          aws-region: ${{ env.AWS_REGION }}

      - name: "Amazon ECRへログイン"
        id: login-ecr
        uses: aws-actions/amazon-ecr-login@62f4f872db3836360b72999f4b87f1ff13310f3a

      - name: "イメージのビルド、タグ付け、ECRへプッシュ"
        id: build-image
        env:
          ECR_REGISTRY: ${{ steps.login-ecr.outputs.registry }}
          IMAGE_TAG: ${{ github.sha }}
        run: |
          docker build -t $ECR_REGISTRY/$ECR_REPOSITORY:$IMAGE_TAG .
          docker push $ECR_REGISTRY/$ECR_REPOSITORY:$IMAGE_TAG
          echo "image=$ECR_REGISTRY/$ECR_REPOSITORY:$IMAGE_TAG" >> $GITHUB_OUTPUT

      - name: "タスク定義に新しいイメージIDを設定"
        id: task-def
        uses: aws-actions/amazon-ecs-render-task-definition@c804dfbdd57f713b6c079302a4c01db7017a36fc
        with:
          task-definition: ${{ env.ECS_TASK_DEFINITION }}
          container-name: ${{ env.CONTAINER_NAME }}
          image: ${{ steps.build-image.outputs.image }}

      - name: "ECSタスク定義をデプロイ"
        uses: aws-actions/amazon-ecs-deploy-task-definition@df9643053eda01f169e64a0e60233aacca83799a
        with:
          task-definition: ${{ steps.task-def.outputs.task-definition }}
          service: ${{ env.ECS_SERVICE }}
          cluster: ${{ env.ECS_CLUSTER }}
          wait-for-service-stability: true

ポイント：

コミットSHAをイメージタグとして使用することで、デプロイ内容を追跡可能
wait-for-service-stabilityでデプロイ完了を確実に待機
IAMポリシーの最小権限設定を推奨

4.4 Kubernetes環境へのデプロイ

4.4.1 Azure Kubernetes Service (AKS)

name: "AKSへビルド・デプロイ"

env:
  AZURE_CONTAINER_REGISTRY: 自分のレジストリ名
  PROJECT_NAME: 自分のプロジェクト名
  RESOURCE_GROUP: 自分のリソースグループ
  CLUSTER_NAME: 自分のクラスター名
  REGISTRY_URL: 自分のレジストリURL
  CHART_PATH: 自分のHelmファイルパス
  CHART_OVERRIDE_PATH: 自分の上書きファイルパス

on: [push]

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
    - uses: actions/checkout@v5

    - name: "Azureログイン"
      uses: azure/login@14a755a4e2fd6dff25794233def4f2cf3f866955
      with:
        creds: ${{ secrets.AZURE_CREDENTIALS }}

    - name: "ACRでイメージをビルド"
      uses: azure/CLI@61bb69d64d613b52663984bf12d6bac8fd7b3cc8
      with:
        azcliversion: 2.29.1
        inlineScript: |
          az configure --defaults acr=${{ env.AZURE_CONTAINER_REGISTRY }}
          az acr build -t ${{ env.REGISTRY_URL }}/${{ env.PROJECT_NAME }}:${{ github.sha }} .

    - name: "K8sコンテキストの取得"
      uses: azure/aks-set-context@94ccc775c1997a3fcfbfbce3c459fec87e0ab188
      with:
          creds: ${{ secrets.AZURE_CREDENTIALS }}
          resource-group: ${{ env.RESOURCE_GROUP }}
          cluster-name: ${{ env.CLUSTER_NAME }}
      id: login

    - name: "デプロイ設定"
      uses: azure/k8s-bake@61041e8c2f75c1f01186c8f05fb8b24e1fc507d8
      with:
        renderEngine: 'helm'
        helmChart: ${{ env.CHART_PATH }}
        overrideFiles: ${{ env.CHART_OVERRIDE_PATH }}
        overrides: |
          replicas:2
        helm-version: 'latest'
      id: bake

    - name: "アプリケーションのデプロイ"
      uses: Azure/k8s-deploy@dd4bbd13a5abd2fc9ca8bdcb8aee152bb718fa78
      with:
        manifests: ${{ steps.bake.outputs.manifestsBundle }}
        images: |
          ${{ env.AZURE_CONTAINER_REGISTRY }}.azurecr.io/${{ env.PROJECT_NAME }}:${{ github.sha }}
        imagepullsecrets: |
          ${{ env.PROJECT_NAME }}

Helmの活用：

k8s-bakeアクションでHelmチャートからマニフェストを生成
overridesでデプロイ時にパラメータを動的に上書き
複数の上書きファイルに対応

4.4.2 Google Kubernetes Engine (GKE)

前提準備の詳細手順

# サービスアカウントの作成
gcloud iam service-accounts create サービスアカウント名

# サービスアカウントのメールアドレス取得
gcloud iam service-accounts list

# IAMロールの付与
gcloud projects add-iam-policy-binding プロジェクトID \
  --member=serviceAccount:サービスアカウント@プロジェクトID.iam.gserviceaccount.com \
  --role=roles/container.admin

gcloud projects add-iam-policy-binding プロジェクトID \
  --member=serviceAccount:サービスアカウント@プロジェクトID.iam.gserviceaccount.com \
  --role=roles/storage.admin

# 認証キーのダウンロード
gcloud iam service-accounts keys create key.json \
  --iam-account=サービスアカウント@プロジェクトID.iam.gserviceaccount.com

# Base64エンコード（macOS/Linux）
export GKE_SA_KEY=$(cat key.json | base64)

5.2 ワークフロー実装

name: "GKEへビルド・デプロイ"

on:
  push:
    branches:
      - main

env:
  PROJECT_ID: ${{ secrets.GKE_PROJECT }}
  GKE_CLUSTER: cluster-1
  GKE_ZONE: us-central1-c
  DEPLOYMENT_NAME: gke-test
  IMAGE: static-site

jobs:
  setup-build-publish-deploy:
    name: "セットアップ、ビルド、公開、デプロイ"
    runs-on: ubuntu-latest
    environment: production

    steps:
    - name: "チェックアウト"
      uses: actions/checkout@v5

    - name: "gcloud CLIのセットアップ"
      uses: google-github-actions/setup-gcloud@1bee7de035d65ec5da40a31f8589e240eba8fde5
      with:
        service_account_key: ${{ secrets.GKE_SA_KEY }}
        project_id: ${{ secrets.GKE_PROJECT }}

    - name: "Dockerの認証設定"
      run: |-
        gcloud --quiet auth configure-docker

    - name: "GKE認証情報の取得"
      uses: google-github-actions/get-gke-credentials@db150f2cc60d1716e61922b832eae71d2a45938f
      with:
        cluster_name: ${{ env.GKE_CLUSTER }}
        location: ${{ env.GKE_ZONE }}
        credentials: ${{ secrets.GKE_SA_KEY }}

    - name: "ビルド"
      run: |-
        docker build \
          --tag "gcr.io/$PROJECT_ID/$IMAGE:$GITHUB_SHA" \
          --build-arg GITHUB_SHA="$GITHUB_SHA" \
          --build-arg GITHUB_REF="$GITHUB_REF" \
          .

    - name: "公開"
      run: |-
        docker push "gcr.io/$PROJECT_ID/$IMAGE:$GITHUB_SHA"

    - name: "Kustomizeのセットアップ"
      run: |-
        curl -sfLo kustomize https://github.com/kubernetes-sigs/kustomize/releases/download/v3.1.0/kustomize_3.1.0_linux_amd64
        chmod u+x ./kustomize

    - name: "デプロイ"
      run: |-
        ./kustomize edit set image gcr.io/PROJECT_ID/IMAGE:TAG=gcr.io/$PROJECT_ID/$IMAGE:$GITHUB_SHA
        ./kustomize build . | kubectl apply -f -
        kubectl rollout status deployment/$DEPLOYMENT_NAME
        kubectl get services -o wide

Kustomizeの役割：

YAMLマニフェストのイメージタグを動的に書き換え
環境ごとの差分管理が容易
kustomization.yamlファイルで設定を管理

4.5 Dockerコンテナのデプロイ（Azure App Service）

コンテナレジストリを使った高度なデプロイです。

name: "コンテナをAzure Web Appへビルド・デプロイ"

env:
  AZURE_WEBAPP_NAME: 自分のアプリ名

on:
  push:
    branches:
      - main

permissions:
  contents: 'read'
  packages: 'write'

jobs:
  build:
    runs-on: ubuntu-latest

    steps:
      - uses: actions/checkout@v5

      - name: "Docker Buildxのセットアップ"
        uses: docker/setup-buildx-action@7a8b9c0d1e2f3a4b5c6d7e8f9a0b1c2d3e4f5a6b

      - name: "GitHubコンテナレジストリへログイン"
        uses: docker/login-action@8c9d0e1f2a3b4c5d6e7f8a9b0c1d2e3f4a5b6c7d
        with:
          registry: ghcr.io
          username: ${{ github.actor }}
          password: ${{ secrets.GITHUB_TOKEN }}

      - name: "リポジトリ名を小文字化"
        run: echo "REPO=${GITHUB_REPOSITORY,,}" >>${GITHUB_ENV}

      - name: "コンテナイメージをビルドしてレジストリへプッシュ"
        uses: docker/build-push-action@9e0f1a2b3c4d5e6f7a8b9c0d1e2f3a4b5c6d7e8f
        with:
          push: true
          tags: ghcr.io/${{ env.REPO }}:${{ github.sha }}
          file: ./Dockerfile

  deploy:
    runs-on: ubuntu-latest
    needs: build
    environment:
      name: 'production'
      url: ${{ steps.deploy-to-webapp.outputs.webapp-url }}

    steps:
      - name: "リポジトリ名を小文字化"
        run: echo "REPO=${GITHUB_REPOSITORY,,}" >>${GITHUB_ENV}

      - name: "Azure Web Appへデプロイ"
        id: deploy-to-webapp
        uses: azure/webapps-deploy@85270a1854658d167ab239bce43949edb336fa7c
        with:
          app-name: ${{ env.AZURE_WEBAPP_NAME }}
          publish-profile: ${{ secrets.AZURE_WEBAPP_PUBLISH_PROFILE }}
          images: 'ghcr.io/${{ env.REPO }}:${{ github.sha }}'

レジストリ認証の設定：

Azure側でGitHub Container Registryからイメージをpullできるよう設定が必要です。

az webapp config appsettings set \
    --name 自分のアプリ名 \
    --resource-group 自分のリソースグループ \
    --settings \
      DOCKER_REGISTRY_SERVER_URL=https://ghcr.io \
      DOCKER_REGISTRY_SERVER_USERNAME=GitHubユーザー名 \
      DOCKER_REGISTRY_SERVER_PASSWORD=個人アクセストークン

ポイント：

GitHub Container Registry（ghcr.io）を使用
リポジトリ名を小文字化する処理が必要
permissionsでpackagesへの書き込み権限を付与

5. モバイルアプリ開発：Apple証明書の管理

iOS/macOSアプリの署名には特殊な処理が必要です。

5.1 証明書の準備

# 証明書をBase64エンコード
base64 -i BUILD_CERTIFICATE.p12 | pbcopy

# プロビジョニングプロファイルをBase64エンコード
base64 -i PROVISIONING_PROFILE.mobileprovision | pbcopy

ワークフロー実装

name: "アプリビルド"
on: push

jobs:
  build_with_signing:
    runs-on: macos-latest

    steps:
      - name: "リポジトリのチェックアウト"
        uses: actions/checkout@v5
        
      - name: "Apple証明書とプロビジョニングプロファイルのインストール"
        env:
          BUILD_CERTIFICATE_BASE64: ${{ secrets.BUILD_CERTIFICATE_BASE64 }}
          P12_PASSWORD: ${{ secrets.P12_PASSWORD }}
          BUILD_PROVISION_PROFILE_BASE64: ${{ secrets.BUILD_PROVISION_PROFILE_BASE64 }}
          KEYCHAIN_PASSWORD: ${{ secrets.KEYCHAIN_PASSWORD }}
        run: |
          # 変数の作成
          CERTIFICATE_PATH=$RUNNER_TEMP/build_certificate.p12
          PP_PATH=$RUNNER_TEMP/build_pp.mobileprovision
          KEYCHAIN_PATH=$RUNNER_TEMP/app-signing.keychain-db

          # シークレットから証明書とプロビジョニングプロファイルをインポート
          echo -n "$BUILD_CERTIFICATE_BASE64" | base64 --decode -o $CERTIFICATE_PATH
          echo -n "$BUILD_PROVISION_PROFILE_BASE64" | base64 --decode -o $PP_PATH

          # 一時keychainの作成
          security create-keychain -p "$KEYCHAIN_PASSWORD" $KEYCHAIN_PATH
          security set-keychain-settings -lut 21600 $KEYCHAIN_PATH
          security unlock-keychain -p "$KEYCHAIN_PASSWORD" $KEYCHAIN_PATH

          # 証明書をkeychainへインポート
          security import $CERTIFICATE_PATH -P "$P12_PASSWORD" -A -t cert -f pkcs12 -k $KEYCHAIN_PATH
          security set-key-partition-list -S apple-tool:,apple: -k "$KEYCHAIN_PASSWORD" $KEYCHAIN_PATH
          security list-keychain -d user -s $KEYCHAIN_PATH

          # プロビジョニングプロファイルの適用
          mkdir -p ~/Library/MobileDevice/Provisioning\ Profiles
          cp $PP_PATH ~/Library/MobileDevice/Provisioning\ Profiles
          
      - name: "アプリのビルド"
        run: |
          # ビルドコマンド

      - name: "keychainとプロビジョニングプロファイルのクリーンアップ"
        if: ${{ always() }}
        run: |
          security delete-keychain $RUNNER_TEMP/app-signing.keychain-db
          rm ~/Library/MobileDevice/Provisioning\ Profiles/build_pp.mobileprovision

セルフホストランナーでの注意点：

GitHub-hostedランナーはジョブ終了時に自動的に破棄されますが、セルフホストランナーでは機密情報が残ります。if: ${{ always() }}により、ジョブの成否に関わらずクリーンアップを確実に実行します。

プラットフォーム別の拡張子：

iOS：.mobileprovision
macOS：.provisionprofile

6. デプロイメント履歴とレビュー

6.1 履歴の確認

リポジトリの「Deployments」ページで以下の情報を確認できます。

各環境のアクティブなデプロイメント
デプロイメントのタイムライン
トリガーしたコミット
ワークフローログへのリンク
デプロイURL
ソースとなったプルリクエストとブランチ

フィルタリング機能：

複雑なデプロイメント履歴も、カスタムフィルタで効率的に検索できます。

「Filter」ボタンをクリック
「Add a filter」で条件を追加
修飾子（環境名、ステータスなど）を選択
演算子と値を設定
複数のフィルタを組み合わせ可能

6.2 デプロイメントのレビュー

必須承認者が設定されている環境では、承認プロセスが発生します。

承認手順：

ワークフロー実行画面へ移動
レビューリクエストの通知を確認
「Review deployments」をクリック
対象環境を選択
コメントを記入（オプション）
「Approve and deploy」または「Reject」をクリック

自己承認の防止：

環境設定で自己承認を無効化すると、自分がトリガーしたワークフローを自分で承認できなくなります。これにより、必ず別の担当者のレビューを経ることが保証されます。

6.3 保護ルールのバイパス

管理者権限を持つユーザーは、緊急時に保護ルールをバイパスできます。

バイパスの条件：

環境設定で「Allow administrators to bypass configured protection rules」が有効
ジョブが「Pending」状態
ワークフロー実行中

バイパス手順：

ワークフロー実行画面へ移動
「Start all waiting jobs」をクリック
バイパスする環境を選択
理由を記入
「I understand the consequences, start deploying」をクリック

この機能は緊急時の対応用であり、通常運用では使用を避けるべきです。

7. 実装のベストプラクティス

7.1 アクションのバージョン管理

GitHub公式では、アクションをコミットSHAでピン留めすることを推奨しています。

# 推奨：コミットSHA
uses: actions/checkout@8f4b7f84864484a7bf31766abe9204da3cbe65b3

# 次善：メジャーバージョン
uses: actions/checkout@v5

# 非推奨：ブランチ名（予期しない変更のリスク）
uses: actions/checkout@main

コミットSHAを使用することで、アクションの動作が予期せず変更されるリスクを最小化できます。

7.2 シークレット管理の原則

最小権限の原則
- 必要最小限のスコープでトークンを発行
- IAMロールも必要な権限のみを付与
環境ごとの分離
- production、staging、developmentで異なるシークレットを使用
- Environment Secretsで環境ごとに管理
ローテーション
- 定期的にシークレットを更新
- 特にPersonal Access Tokenは有効期限を設定

7.3 ワークフローの構造化

# 環境変数は最上位で定義
env:
  GLOBAL_VAR: value

jobs:
  build:
    # ジョブレベルの環境変数
    env:
      JOB_VAR: value
    steps:
      - name: "ステップ名"
        # ステップレベルの環境変数
        env:
          STEP_VAR: value

スコープを適切に設定することで、変数の意図が明確になります。

7.4 エラーハンドリング

- name: "処理"
  id: process
  continue-on-error: true
  run: |
    # 何らかの処理

- name: "失敗時の処理"
  if: steps.process.outcome == 'failure'
  run: |
    # エラー通知など

7.5 キャッシュの活用

ビルド時間を大幅に短縮できます。

# Node.jsの例
- uses: actions/setup-node@v4
  with:
    node-version: '18'
    cache: 'npm'

# Pythonの例
- uses: actions/cache@v4
  with:
    path: ~/.cache/pip
    key: ${{ runner.os }}-pip-${{ hashFiles('**/requirements.txt') }}
    restore-keys: |
      ${{ runner.os }}-pip-

7.6 ステータスバッジの追加

README.mdにワークフローのステータスバッジを追加することで、デプロイ状態を可視化できます。

![デプロイステータス](https://github.com/ユーザー名/リポジトリ名/actions/workflows/deploy.yml/badge.svg)

特定のブランチのステータスを表示する場合：

![デプロイステータス](https://github.com/ユーザー名/リポジトリ名/actions/workflows/deploy.yml/badge.svg?branch=main)

8. プライベートリポジトリでの制限事項

一部の機能はプランによって利用制限があります。

機能	パブリック	プライベート（Free/Pro/Team）	プライベート（Enterprise）
Environment	○	×	○
Environment Secrets	○	×	○
Required Reviewers	○（全プラン）	△（パブリックのみ）	○
Wait Timer	○（全プラン）	△（パブリックのみ）	○
カスタム保護ルール	○（全プラン）	×	○

プライベートリポジトリで高度なデプロイメント機能を利用する場合は、GitHub EnterpriseまたはGitHub Teamの導入を検討してください。

9. まとめ

GitHub Actionsによるデプロイメントは、以下の要素を組み合わせることで、堅牢で追跡可能なCI/CDパイプラインを構築できます。

Environmentによる保護層の実装
Concurrencyによる安全な並行制御
カスタム保護ルールによる外部サービス連携
アーティファクト管理による明確なビルド成果物の管理
詳細な履歴管理とレビュープロセス

これらの機能を適切に組み合わせることで、小規模なプロジェクトから大規模なエンタープライズアプリケーションまで、信頼性の高いデプロイメントフローを実現できます。

各クラウドプロバイダーへのデプロイパターンは、細かな違いはあるものの、基本的な構造は共通しています。この記事で紹介したパターンをベースに、プロジェクトの要件に合わせてカスタマイズしていくことをお勧めします。

You get articles that match your needs
You can efficiently read back useful information
You can use dark theme

What you can do with signing up