GitHub ActionsでDockerビルド&デプロイする自動化フロー

はじめに

なぜCI/CDが必要なのか？

ソフトウェア開発の現場において、コードの変更を本番環境へ反映するプロセスは、その頻度と複雑さが増すにつれて、手作業によるミスや時間的なコストが課題となります。CI/CD（継続的インテグレーション/継続的デリバリーまたは継続的デプロイメント）は、これらの課題を解決し、より迅速かつ安全に価値をユーザーに届けるための不可欠なプラクティスです。

CI（継続的インテグレーション）は、開発者が頻繁にコードを共有リポジトリに統合するプラクティスであり、統合のたびに自動でビルド、テストを実行することで、早期に不具合を発見し、修正コストを低減します。

CD（継続的デリバリー/継続的デプロイメント）は、CIによって品質が保証されたコードを、自動的に本番環境へリリースするプロセスです。継続的デリバリーでは、リリース前の最終確認を手動で行いますが、継続的デプロイメントでは、完全に自動化されます。

CI/CDを導入することで、開発チームはより頻繁に、そして自信を持ってソフトウェアをリリースできるようになり、結果としてユーザーへの価値提供のサイクルを加速させることができます。

本記事で扱う技術スタックと自動化の範囲

本記事では、バックエンドにLaravel (API)、フロントエンドにVue.js (SPA) を採用したWebアプリケーションを例に、開発から本番環境へのデプロイまでをGitHub Actionsを用いて自動化するフローを解説します。

技術スタック:

バックエンド: Laravel (PHPフレームワーク)
フロントエンド: Vue.js (JavaScriptフレームワーク)
コンテナ化: Docker, Docker Compose
CI/CDプラットフォーム: GitHub Actions
コンテナレジストリ: Amazon Elastic Container Registry (ECR) (例)
インフラ: Amazon Elastic Container Service (ECS) (例)
静的ファイル配信: Amazon CloudFront, Amazon Simple Storage Service (S3) (例)

自動化の範囲:

ビルド: Laravelアプリケーションのバックエンドビルド、Vue.jsアプリケーションのフロントエンドビルド
テスト: PHPUnitによるLaravelの単体・結合テスト、静的解析、Jest/Vue Test UtilsによるVue.jsの単体テスト
Dockerイメージの作成とプッシュ: LaravelとVue.jsそれぞれのDockerイメージをビルドし、コンテナレジストリへプッシュ

本番環境へのデプロイ:

DockerイメージをECSなどの環境へデプロイ、Vue.jsのビルド済みファイルをS3へデプロイしCloudFront経由で配信

プロジェクト構成の概要

Laravel (API) と Vue.js (SPA) のモノレポ構成
本記事では、Laravel APIとVue.js SPAを一つのリポジトリで管理するモノレポ構成を前提とします。これは、フロントエンドとバックエンドの開発が密接に関連している場合に、変更の追跡や連携を容易にするメリットがあります。

以下は、基本的なディレクトリ構成の例です。

monorepo/
├── api/        # Laravelアプリケーション
│   ├── app/
│   ├── artisan
│   ├── composer.json
│   └── ...
├── frontend/   # Vue.jsアプリケーション
│   ├── public/
│   ├── src/
│   ├── package.json
│   └── ...
├── docker-compose.yml
├── docker/
│   ├── api/
│   │   └── Dockerfile
│   └── frontend/
│       └── Dockerfile
└── .github/
└── workflows/
└── deploy.yml
monorepo/
├── api/        # Laravelアプリケーション
│   ├── app/
│   ├── artisan
│   ├── composer.json
│   └── ...
├── frontend/   # Vue.jsアプリケーション
│   ├── public/
│   ├── src/
│   ├── package.json
│   └── ...
├── docker-compose.yml
├── docker/
│   ├── api/
│   │   └── Dockerfile
│   └── frontend/
│       └── Dockerfile
└── .github/
└── workflows/
└── deploy.yml

DockerとDocker Composeによる開発環境

開発環境の構築にはDockerとDocker Composeを利用します。Dockerを使用することで、開発者一人ひとりの環境差を吸収し、常に一貫した環境で開発を行うことができます。Docker Composeは、複数のDockerコンテナをまとめて管理するためのツールであり、Laravel APIとVue.js SPA、そしてデータベースなどの依存サービスを一つのコマンドで起動・停止することができます。

以下は、開発用の基本的なdocker-compose.ymlの例です。

version: '3.8'
services:
api:
build:
context: ./api
dockerfile: docker/api/Dockerfile
ports:
- "8000:80"
volumes:
- ./api:/var/www/html
environment:
- APP_DEBUG=true
- DB_CONNECTION=mysql
- DB_HOST=db
- DB_PORT=3306
- DB_DATABASE=laravel
- DB_USERNAME=root
- DB_PASSWORD=password
depends_on:
- db

frontend:
build:
context: ./frontend
dockerfile: docker/frontend/Dockerfile
ports:
- "3000:80"
volumes:
- ./frontend:/app
depends_on:
- api

db:
image: mysql:8.0
ports:
- "3306:3306"
environment:
- MYSQL_ROOT_PASSWORD=password
- MYSQL_DATABASE=laravel
- MYSQL_USER=root
- MYSQL_PASSWORD=password
version: '3.8'
services:
api:
build:
context: ./api
dockerfile: docker/api/Dockerfile
ports:
- "8000:80"
volumes:
- ./api:/var/www/html
environment:
- APP_DEBUG=true
- DB_CONNECTION=mysql
- DB_HOST=db
- DB_PORT=3306
- DB_DATABASE=laravel
- DB_USERNAME=root
- DB_PASSWORD=password
depends_on:
- db

frontend:
build:
context: ./frontend
dockerfile: docker/frontend/Dockerfile
ports:
- "3000:80"
volumes:
- ./frontend:/app
depends_on:
- api

db:
image: mysql:8.0
ports:
- "3306:3306"
environment:
- MYSQL_ROOT_PASSWORD=password
- MYSQL_DATABASE=laravel
- MYSQL_USER=root
- MYSQL_PASSWORD=password

本番環境の想定 (AWS ECS, Kubernetesなど)

本番環境としては、コンテナオーケストレーションサービスであるAWS Elastic Container Service (ECS) やKubernetesなどを想定します。これらのサービスを利用することで、スケーラビリティ、可用性、運用管理の効率化を実現できます。

また、Vue.jsのSPAは、ビルドされた静的ファイルをCDN (Content Delivery Network) 経由で配信することも一般的です。AWS CloudFrontやAmazon S3などを活用することで、高速かつ低コストな配信が可能になります。

Dockerfileとdocker-compose.ymlの準備
Laravel API用Dockerfileの最適化
Laravel APIのDockerイメージを効率的にビルドし、実行するために、Dockerfileを最適化します。

FROM php:8.2-fpm-alpine

WORKDIR /var/www/html

RUN apk add --no-cache zip libzip-dev oniguruma-dev
RUN docker-php-ext-install pdo pdo_mysql mbstring zip bcmath opcache

RUN curl -sS https://getcomposer.org/installer | php -- --install-dir=/usr/local/bin --filename=composer
ENV PATH=$PATH:/var/www/html/vendor/bin

COPY composer.json composer.lock ./
RUN composer install --optimize-autoloader --no-dev

COPY . .

RUN chown -R www-data:www-data storage bootstrap/cache
RUN php artisan config:cache
RUN php artisan route:cache
RUN php artisan event:cache
RUN php artisan view:cache

EXPOSE 80
CMD ["php-fpm"]
FROM php:8.2-fpm-alpine

WORKDIR /var/www/html

RUN apk add --no-cache zip libzip-dev oniguruma-dev
RUN docker-php-ext-install pdo pdo_mysql mbstring zip bcmath opcache

RUN curl -sS https://getcomposer.org/installer | php -- --install-dir=/usr/local/bin --filename=composer
ENV PATH=$PATH:/var/www/html/vendor/bin

COPY composer.json composer.lock ./
RUN composer install --optimize-autoloader --no-dev

COPY . .

RUN chown -R www-data:www-data storage bootstrap/cache
RUN php artisan config:cache
RUN php artisan route:cache
RUN php artisan event:cache
RUN php artisan view:cache

EXPOSE 80
CMD ["php-fpm"]

最適化のポイント:

ベースイメージには軽量なAlpine Linuxを使用
必要なPHP拡張のみをインストール
Composerのインストールと依存関係のインストールを分離し、キャッシュを活用
開発に必要なパッケージはインストールしない (--no-dev)
Laravelのキャッシュ設定を最適化
Vue.js SPA用Dockerfileの最適化
Vue.js SPAのDockerイメージは、ビルドされた静的ファイルを提供するために作成します。マルチステージビルドを利用して、最終的なイメージサイズを削減します。


Builder Stage
FROM node:lts-alpine as builder
WORKDIR /app
COPY frontend/package.json frontend/package-lock.json ./
RUN npm install
COPY frontend/. .
RUN npm run build

Production Stage
FROM nginx:stable-alpine
COPY --from=builder /app/dist /usr/share/nginx/html
EXPOSE 80
CMD ["nginx", "-g", "daemon off;"]

Builder Stage
FROM node:lts-alpine as builder
WORKDIR /app
COPY frontend/package.json frontend/package-lock.json ./
RUN npm install
COPY frontend/. .
RUN npm run build

Production Stage
FROM nginx:stable-alpine
COPY --from=builder /app/dist /usr/share/nginx/html
EXPOSE 80
CMD ["nginx", "-g", "daemon off;"]

最適化のポイントその2:

Node.jsのビルド環境とNginxの配信環境を分離 (マルチステージビルド)
ビルドに必要なファイルのみをコピーし、キャッシュを活用
最終的なイメージにはビルド済みの静的ファイルとNginxのみを含める
開発用docker-compose.ymlの設定
前述の通り。開発時には、コードの変更を即座に反映させるために、ボリュームマウントなどを設定します。

本番用docker-compose.yml (または類似のデプロイ設定ファイル) の考慮点

本番環境では、セキュリティや安定性を考慮した設定が必要です。
環境変数の管理: ハードコードせずに、外部から安全に設定を注入する仕組み (例: ECS Task Definitionの環境変数)

ログ出力: 標準出力へのログ出力と、外部のログ管理サービスへの連携
ヘルスチェック: コンテナの生存確認とアプリケーションの状態確認のエンドポイント設定
リソース制限: メモリやCPUの使用量を適切に設定

本番環境では、docker-composeではなく、ECSのタスク定義やKubernetesのマニフェストファイルなど、各プラットフォームに合わせた設定ファイルを使用するのが一般的です。

GitHub Actionsの基本

GitHub Actionsのワークフローとは

GitHub Actionsは、GitHub上で直接利用できるCI/CDプラットフォームです。ワークフローは、リポジトリ内の/.github/workflows/ディレクトリにYAMLファイルとして定義され、一つまたは複数のジョブで構成されます。各ジョブは、一つまたは複数のステップで構成され、各ステップはシェルスクリプトの実行や、定義済みのActionの実行を行います。

イベントトリガーの設定 (push, pull_requestなど)
ワークフローは、GitHubの様々なイベントをトリガーとして実行できます。

push: 特定のブランチへのプッシュ
pull_request: 特定のブランチへのプルリクエストの作成または更新
schedule: 定期的なスケジュール実行
workflow_dispatch: 手動実行

例えば、mainブランチへのプッシュと、developブランチへのプルリクエストをトリガーとするワークフローは以下のように定義します。

on:
push:
branches: [ main ]
pull_request:
branches: [ develop ]
on:
push:
branches: [ main ]
pull_request:
branches: [ develop ]

ジョブとステップの定義

ワークフローは一つ以上のジョブを含み、各ジョブは独立して実行されます。ジョブ内では、複数のステップを定義し、順に実行します。

jobs:
build:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v3
- name: Set up PHP
uses: shivammathur/setup-php@v2
with:
php-version: '8.2'
- name: Install Composer dependencies
run: composer install --no-interaction --no-dev --prefer-dist
jobs:
build:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v3
- name: Set up PHP
uses: shivammathur/setup-php@v2
with:
php-version: '8.2'
- name: Install Composer dependencies
run: composer install --no-interaction --no-dev --prefer-dist

この例では、buildというジョブがubuntu-latestというGitHub Actionsが提供する仮想環境で実行されます。ステップとしては、まずactions/checkout@v3 Actionを使ってリポジトリのコードをチェックアウトし、次にshivammathur/setup-php@v2 Actionを使ってPHP 8.2の環境をセットアップし、最後にComposerの依存関係をインストールしています。

シークレットの安全な管理

本番環境へのデプロイに必要な認証情報 (APIトークン、SSH秘密鍵など) は、GitHub Secretsとして安全に管理します。SecretsはワークフローのYAMLファイルに直接記述するのではなく、GitHubリポジトリの設定画面から登録し、ワークフロー内では${{ secrets.YOUR_SECRET_NAME }}のような形式で参照します。

Laravel (API) のCI/CDフロー

テストの自動化
PHPUnitによる単体・結合テスト
Laravelアプリケーションの品質を保証するために、PHPUnitを用いた単体テストと結合テストを自動化します。

- name: Run PHPUnit tests
run: |
cd api
./vendor/bin/phpunit
- name: Run PHPUnit tests
run: |
cd api
./vendor/bin/phpunit

静的解析 (PHPStan, Psalmなど)

コードの潜在的な問題やコーディング規約違反を早期に発見するために、PHPStanやPsalmなどの静的解析ツールを導入し、CIパイプラインに組み込みます。

- name: Run PHPStan
run: |
cd api
./vendor/bin/phpstan analyse --ansi
- name: Run PHPStan
run: |
cd api
./vendor/bin/phpstan analyse --ansi

Dockerイメージのビルドとプッシュ

ECRなどのコンテナレジストリへのプッシュ
テストと静的解析に合格したコードのDockerイメージをビルドし、Amazon ECRなどのコンテナレジストリへプッシュします。GitHub Actionsの公式ActionやAWS CLIを利用できます。

- name: Login to AWS ECR
uses: aws-actions/configure-aws-credentials@v1
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: Build and push Docker image (API)
    run: |
      cd api
      IMAGE_TAG=$(git rev-parse --short HEAD)
      docker build -t ${{ env.ECR_REPOSITORY_API }}:${IMAGE_TAG} -f docker/api/Dockerfile .
      aws ecr get-login-password --region ${{ env.AWS_REGION }} | docker login --username AWS --password-stdin ${{ env.AWS_ACCOUNT_ID }}.dkr.ecr.${{ env.AWS_REGION }}.amazonaws.com
      docker push ${{ env.ECR_REPOSITORY_API }}:${IMAGE_TAG}
- name: Login to AWS ECR
uses: aws-actions/configure-aws-credentials@v1
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: Build and push Docker image (API)
    run: |
      cd api
      IMAGE_TAG=$(git rev-parse --short HEAD)
      docker build -t ${{ env.ECR_REPOSITORY_API }}:${IMAGE_TAG} -f docker/api/Dockerfile .
      aws ecr get-login-password --region ${{ env.AWS_REGION }} | docker login --username AWS --password-stdin ${{ env.AWS_ACCOUNT_ID }}.dkr.ecr.${{ env.AWS_REGION }}.amazonaws.com
      docker push ${{ env.ECR_REPOSITORY_API }}:${IMAGE_TAG}

イメージタグの戦略 (コミットハッシュ, セマンティックバージョニングなど)

Dockerイメージには、コミットハッシュやセマンティックバージョニングなどの戦略に基づいてタグを付与します。これにより、デプロイ時のバージョン管理やロールバックが容易になります。上記の例では、コミットハッシュをタグとして使用しています。

本番環境へのデプロイ

デプロイスクリプトの実行 (SSH経由, AWS CLIなど)ECRにプッシュしたDockerイメージを本番環境へデプロイします。デプロイ方法としては、SSHでサーバーに接続してDocker Composeを再起動したり、AWS CLIを使ってECSのタスク定義を更新したりする方法があります。

- name: Deploy to AWS ECS (API)
run: |
aws ecs update-service --cluster ${{ env.ECS_CLUSTER_NAME }} --service ${{ env.ECS_SERVICE_NAME_API }} --force-new-deployment --region ${{ env.AWS_REGION }}
- name: Deploy to AWS ECS (API)
run: |
aws ecs update-service --cluster ${{ env.ECS_CLUSTER_NAME }} --service ${{ env.ECS_SERVICE_NAME_API }} --force-new-deployment --region ${{ env.AWS_REGION }}

環境変数とシークレットの渡し方

本番環境に必要な環境変数やAPIキーなどのシークレットは、GitHub Secretsから取得し、デプロイ時に安全に渡します。ECSの場合はタスク定義、Kubernetesの場合はSecretオブジェクトなどを利用します。

デプロイ後のヘルスチェック

デプロイが完了したら、アプリケーションのヘルスチェックエンドポイントにアクセスし、正常に起動していることを確認します。

Vue.js (SPA) のCI/CDフロー

テストの自動化
Jest/Vue Test Utilsによる単体テスト
Vue.jsコンポーネントの単体テストをJestやVue Test Utilsを使って自動化します。

- name: Run Vue.js tests
run: |
cd frontend
npm run test:unit
- name: Run Vue.js tests
run: |
cd frontend
npm run test:unit

E2Eテスト (Cypress, Playwrightなど) の組み込み

ユーザーシナリオに基づいたE2E (End-to-End) テストをCypressやPlaywrightなどのツールを使って組み込みます。

- name: Run Vue.js E2E tests
run: |
cd frontend
npm run test:e2e
- name: Run Vue.js E2E tests
run: |
cd frontend
npm run test:e2e

Dockerイメージのビルドとプッシュ

ビルド成果物の最適化 (Tree Shaking, コード分割)
Vue.jsアプリケーションをビルドする際には、Tree Shakingやコード分割などの最適化を行い、生成される静的ファイルのサイズを削減します。

- name: Build Vue.js application
run: |
cd frontend
npm run build
- name: Build Vue.js application
run: |
cd frontend
npm run build

NginxなどのWebサーバーを同梱したイメージ作成

ビルドされた静的ファイルを提供するNginxなどのWebサーバーを同梱したDockerイメージを作成し、コンテナレジストリへプッシュします。前述のDockerfileの例を参照してください。

- name: Build and push Docker image (Frontend)
run: |
cd frontend
IMAGE_TAG=$(git rev-parse --short HEAD)
docker build -t env.ECR_REPOSITORY_FRONTEND:{IMAGE_TAG} -f docker/frontend/Dockerfile .
aws ecr get-login-password --region ${{ env.AWS_REGION }} | docker login --username AWS --password-stdin env.AWS_ACCOUNT_ID.dkr.ecr.{{ env.AWS_REGION }}https://www.google.com/url?sa=E&source=gmail&q=.amazonaws.com
docker push env.ECR_REPOSITORY_FRONTEND:{IMAGE_TAG}
- name: Build and push Docker image (Frontend)
run: |
cd frontend
IMAGE_TAG=$(git rev-parse --short HEAD)
docker build -t env.ECR_REPOSITORY_FRONTEND:{IMAGE_TAG} -f docker/frontend/Dockerfile .
aws ecr get-login-password --region ${{ env.AWS_REGION }} | docker login --username AWS --password-stdin env.AWS_ACCOUNT_ID.dkr.ecr.{{ env.AWS_REGION }}https://www.google.com/url?sa=E&source=gmail&q=.amazonaws.com
docker push env.ECR_REPOSITORY_FRONTEND:{IMAGE_TAG}

本番環境へのデプロイ

CDN (CloudFrontなど) を利用したデプロイ
Vue.jsのビルド済み静的ファイルは、CDNを利用して配信することが一般的です。AWS CloudFrontなどを設定し、S3に配置されたファイルを高速に配信します。

S3などへの静的ファイル配置とキャッシュ戦略

ビルドされた静的ファイルをAmazon S3などのオブジェクトストレージサービスへアップロードします。適切なキャッシュ戦略 (Cache-Controlヘッダーの設定など) を設定することで、パフォーマンスを向上させることができます。AWS CLIなどを利用してアップロードを自動化します。

- name: Deploy Vue.js to S3
run: |
cd frontend/dist
aws s3 sync . s3://${{ env.S3_BUCKET_NAME }} --delete --cache-control "public, max-age=31536000, immutable" --region ${{ env.AWS_REGION }}
- name: Deploy Vue.js to S3
run: |
cd frontend/dist
aws s3 sync . s3://${{ env.S3_BUCKET_NAME }} --delete --cache-control "public, max-age=31536000, immutable" --region ${{ env.AWS_REGION }}

デプロイ後の動作確認

CDN経由でアプリケーションにアクセスし、正常に動作することを確認します。

共通のCI/CDプラクティス

ブランチ戦略
Git Flow / GitHub Flow に基づくワークフロー
開発プロセスに合わせて、Git FlowやGitHub Flowなどのブランチ戦略を採用します。本記事では、シンプルなGitHub Flow (mainブランチとフィーチャーブランチ) を基本とします。

feature, develop, main ブランチの役割

##mainブランチ: 常に本番環境にデプロイ可能な安定したコードを保持

フィーチャーブランチ: 新機能開発やバグ修正を行うための短期ブランチ

ロールバック戦略

デプロイ失敗時の自動ロールバック
デプロイが失敗した場合に、自動的に前の安定したバージョンへロールバックする仕組みを検討します。ECSの場合は、以前のタスク定義へのロールバック、S3の場合はバージョン管理機能を利用するなどが考えられます。

手動でのバージョン切り戻し

問題発生時には、手動で特定のバージョンへ切り戻せるように、Dockerイメージのタグ管理やデプロイ履歴の管理を適切に行います。

通知と監視

Slack, Teamsなどへの通知設定
CI/CDパイプラインの実行結果 (成功、失敗) をSlackやMicrosoft Teamsなどのコミュニケーションツールへ通知するように設定します。GitHub Actionsには、通知用のActionが用意されています。

- name: Send Slack notification on success
if: success()
uses: rtCamp/action-slack-notify@v2
env:
SLACK_CHANNEL: ${{ env.SLACK_CHANNEL }}
SLACK_COLOR: '#2eb886'
SLACK_TITLE: "Deployment Success"
SLACK_MESSAGE: "Successfully deployed commit ${{ github.sha }} to ${{ env.ENVIRONMENT }}"
SLACK_WEBHOOK: ${{ secrets.SLACK_WEBHOOK_URL }}

  - name: Send Slack notification on failure
    if: failure()
    uses: rtCamp/action-slack-notify@v2
    env:
      SLACK_CHANNEL: ${{ env.SLACK_CHANNEL }}
      SLACK_COLOR: '#e01b5a'
      SLACK_TITLE: "Deployment Failed"
      SLACK_MESSAGE: "Failed to deploy commit ${{ github.sha }} to ${{ env.ENVIRONMENT }}"
      SLACK_WEBHOOK: ${{ secrets.SLACK_WEBHOOK_URL }}
- name: Send Slack notification on success
if: success()
uses: rtCamp/action-slack-notify@v2
env:
SLACK_CHANNEL: ${{ env.SLACK_CHANNEL }}
SLACK_COLOR: '#2eb886'
SLACK_TITLE: "Deployment Success"
SLACK_MESSAGE: "Successfully deployed commit ${{ github.sha }} to ${{ env.ENVIRONMENT }}"
SLACK_WEBHOOK: ${{ secrets.SLACK_WEBHOOK_URL }}

  - name: Send Slack notification on failure
    if: failure()
    uses: rtCamp/action-slack-notify@v2
    env:
      SLACK_CHANNEL: ${{ env.SLACK_CHANNEL }}
      SLACK_COLOR: '#e01b5a'
      SLACK_TITLE: "Deployment Failed"
      SLACK_MESSAGE: "Failed to deploy commit ${{ github.sha }} to ${{ env.ENVIRONMENT }}"
      SLACK_WEBHOOK: ${{ secrets.SLACK_WEBHOOK_URL }}

デプロイ状況のモニタリング

デプロイの状況や本番環境のアプリケーションの状態を監視するために、AWS CloudWatchやDatadogなどのモニタリングツールを導入します。

まとめ

自動化のメリットと課題

GitHub Actionsを活用したCI/CDパイプラインの構築は、開発効率の向上、リリースサイクルの短縮、人的ミスの削減など、多くのメリットをもたらします。一方で、パイプラインの設計や保守には一定の学習コストと時間が必要です。

今後の改善点と展望

今回解説した内容は基本的なフローであり、より高度なCI/CDパイプラインを目指すためには、以下のような改善点が考えられます。

カナリアリリースやブルー/グリーンデプロイメントの導入
データベースのマイグレーション自動化
セキュリティスキャンの自動化
パフォーマンス監視の強化

安心安全のホワイト高還元SESに転職を考えている方へ

新しい挑戦に踏み出すことは、人生において重要な一歩です。転職活動は自分自身を知り、成長する貴重な機会でもあり、夢や成長を追求するためには必要な要素の一つになるかと思います。どんな選択をされるにせよ、その決断があなたに取って素晴らしい未来を切り開くことを願っています！グラディートと一緒に誇れるエンジニアを目指しましょう！

■『株式会社グラディート』では受託開発・SES・ブランディングデザイン・事業コンサルティングなどを事業として行う都内のIT企業です。現在、不遇な待遇で困っているエンジニアさんは、ぜひ一度グラディートに相談してみてね！（年収査定・SESへの転職相談も承っております！）

株式会社グラディート採用情報はこちら▼
https://en-gage.net/gradito/

株式会社グラディート公式サイトはこちら▼
https://www.gradito.co.jp/

株式会社グラディートでは一緒に働く仲間を募集しています

GitHub ActionsでDockerビルド&デプロイする自動化フロー

gradito広報ににみ

株式会社グラディート / マーケティング

2 いいね！

株式会社グラディート

GitHub ActionsでDockerビルド&デプロイする自動化フロー

はじめに

なぜCI/CDが必要なのか？

本記事で扱う技術スタックと自動化の範囲

技術スタック:

自動化の範囲:

本番環境へのデプロイ:

プロジェクト構成の概要

DockerとDocker Composeによる開発環境

本番環境の想定 (AWS ECS, Kubernetesなど)

最適化のポイント:

最適化のポイント その2:

本番用docker-compose.yml (または類似のデプロイ設定ファイル) の考慮点

GitHub Actionsの基本

GitHub Actionsのワークフローとは

ジョブとステップの定義

シークレットの安全な管理

Laravel (API) のCI/CDフロー

静的解析 (PHPStan, Psalmなど)

Dockerイメージのビルドとプッシュ

イメージタグの戦略 (コミットハッシュ, セマンティックバージョニングなど)

本番環境へのデプロイ

環境変数とシークレットの渡し方

デプロイ後のヘルスチェック

Vue.js (SPA) のCI/CDフロー

E2Eテスト (Cypress, Playwrightなど) の組み込み

Dockerイメージのビルドとプッシュ

NginxなどのWebサーバーを同梱したイメージ作成

本番環境へのデプロイ

S3などへの静的ファイル配置とキャッシュ戦略

デプロイ後の動作確認

共通のCI/CDプラクティス

feature, develop, main ブランチの役割

ロールバック戦略

手動でのバージョン切り戻し

通知と監視

デプロイ状況のモニタリング

まとめ

自動化のメリットと課題

今後の改善点と展望

安心安全のホワイト高還元SESに転職を考えている方へ

株式会社グラディート

同じタグの記事

今週のランキング

最適化のポイントその2: