PhinxによるDBマイグレー ションとサービス運用 ヒエイカザト 2023/10/08 PHPConference2023

ヒエイカザト 株式会社ウエディングパーク Photorait サーバーサイドエンジニア チーフエンジニア 　 @zosokh　#野球観戦 #ちなヤク🐧 #二児の父

Photorait フォトレイト フォトウエディング、前撮りなど結婚 写真の撮影スタジオやロケ地を検 索できる情報サイト www.photorait.net

今日の話 稼働中サービスへのマイグレーション導入や、マイグレーション設計に悩んで いる方へ マイグレーション立ち上げから運用フロー構築をした話をします マイグレーション設計 Phinxを利用した開発運用の話 マイグレーションの拡張

今日話さない事 Phinx Migrationsの記法などドキュメント周り 以下をお読みください https://phinx.org/

マイグレーション設計 マイグレーションアプリの立ち上げ マイグレーション設計 Phinxを利用した開発運用の話 マイグレーションの拡張

マイグレーション設計｜ マイグレーションシステム構成 例

一般的なマイグレーション運用図

一般的なマイグレーション運用 サービスのアプリケーションコードとマイグレーションを同一プロジェクトで管理 ● Laravelのマイグレーションなど、フレームワークのマイグレーションを利 用 ● 1アプリケーション・1DB・1マイグレーションの形。 上記に対して・・

DBが複数サービスで利用

マイグレーションをどこに持たせたら良いか

そもそもマイグレーション運用していない😭

マイグレーション運用を始めるにあたっての壁 ● API・管理画面サービス・hogehogeサービスなど、複数サービスが同一 のDBに接続している ● そもそもマイグレーション運用していない マイグレーション運用を始めようにも、どこでマイグレーションシステムを持たせ ようか悩む

マイグレーション設計｜ マイグレーションを独立したア プリケーションにする

独立したマイグレーション例 新規立ち上げ！

独立したマイグレーション ● 単一Gitリポジトリを持つ ● 軽量なアプリケーションでいたい ● 他サービスに依存しない ● オレオレシステムは構築しない 良きライブラリを探します

No content

https://phinx.org/ ● Cake PHPが公式で採用しているマイグレーションシステム ● フレームワークに依存せず、インストールが簡単 ● 公式ドキュメントが整備されている Phinx Migration（以後Phinx）

マイグレーション設計｜ Phinxセットアップ

composerでインストールし、initコマンドを実行する Phinxをインスール composer require robmorgan/phinx vendor/bin/phinx init . ├── composer.json ├── composer.lock ├── phinx.php └── vendor

composerでインストールし、initコマンドを実行する Phinxをインスール composer require robmorgan/phinx vendor/bin/phinx init . ├── composer.json ├── composer.lock ├── phinx.php └── vendor yamlやjsonファイルでも可能

さらに構築していく ├── Dockerfile ├── README.md ├── composer.json ├── composer.lock ├── db 　　├── migrations 　　├── seeds 　　└── sql ├── docker ├── docker-compose.yml ├── phinx.php └── vendor

さらに構築していく ├── Dockerfile ├── README.md ├── composer.json ├── composer.lock ├── db 　　├── migrations 　　├── seeds 　　└── sql ├── docker ├── docker-compose.yml ├── phinx.php └── vendor migrationやseedingファイル

さらに構築していく ├── Dockerfile ├── README.md ├── composer.json ├── composer.lock ├── db 　　├── migrations 　　├── seeds 　　└── sql ├── docker ├── docker-compose.yml ├── phinx.php └── vendor ローカル開発環境ファイル

さらにさらに構築していく ├── .git ├── .github ├── .gitignore ├── .php-cs-fixer.php ├── Dockerfile ├── README.md ├── composer.json ├── composer.lock ├── db ├── deploy ├── docker ├── docker-compose.build.yml ├── docker-compose.yml ├── phinx.php └── vendor

さらにさらに構築していく ├── .git ├── .github ├── .gitignore ├── .php-cs-fixer.php ├── Dockerfile ├── README.md ├── composer.json ├── composer.lock ├── db ├── deploy ├── docker ├── docker-compose.build.yml ├── docker-compose.yml ├── phinx.php └── vendor fixerによる静的解析

さらにさらに構築していく ├── .git ├── .github ├── .gitignore ├── .php-cs-fixer.php ├── Dockerfile ├── README.md ├── composer.json ├── composer.lock ├── db ├── deploy ├── docker ├── docker-compose.build.yml ├── docker-compose.yml ├── phinx.php └── vendor マイグレーションデプロイファイ ル

以上マイグレーション運用ファイルを用意できました 次に運用面を紹介しながら各ファイル用途を深堀していきます セットアップ完了

Phinxを利用した開発運用 の話 マイグレーションアプリを運用させます マイグレーション設計 Phinxを利用した開発運用の話 マイグレーションの拡張

Phinxを利用した開発運用の話｜ ローカル環境の作成

前提 ● 本番や検証・開発用DBはAmazon RDS（以後RDS）上に立っているものとす る ○ dev ○ stg ○ prd マイグレーションとDB環境について

● マイグレーション実行用のPHPコンテナサービスとローカルMySQLを立ち 上げる ● マイグレーション拡張や実行確認はローカル環境で開発 ローカル環境を作成

Phinxのローカル設定 [ 'default_migration_table' => 'phinxlog', 'default_environment' => local, 'local' => [ 'adapter' => 'mysql', 'host' => 'mysql', 'name' => 'local_mysql', 'user' => 'mysql_user', 'pass' => 'mysql_pw', 'port' => '3306', 'charset' => 'utf8', ], ], … ] ローカル用env設定を追加 hostはdockerサービス名を指 定 DB名・user・passはローカル MySQLを設定 phinx.php

Phinxのローカル設定 [ 'default_migration_table' => 'phinxlog', 'default_environment' => local, 'local' => [ 'adapter' => 'mysql', 'host' => 'mysql', 'name' => 'local_mysql', 'user' => 'mysql_user', 'pass' => 'mysql_pw', 'port' => '3306', 'charset' => 'utf8', ], ], … ] default_environmentをローカ ル用envにする phinx.php

Phinxを利用した開発運用の話｜ 稼働中サービスへマイグレー ション導入

サービスローンチして8年の稼働中サービス用DBに、マイグレーションの立ち 上げを実施 ● 既存テーブルのマイグレーション管理をする ● 既存マスターレコード達もマイグレーション管理をする 稼働中サービスへマイグレーション導入

サービスローンチして8年の稼働中サービス用DBに、マイグレーションの立ち 上げを実施 ● 既存テーブルのマイグレーション管理をする ● 既存マスターレコード達もマイグレーション管理をする しかし全てマイグレーションファイル化するのはしんどい・・・ 対象テーブルは250以上 稼働中サービスへマイグレーション導入

1. 稼働中RDSからmysqldumpでdump sqlを作成する 2. Phinxのマイグレーション経由でdump sqlを実行できるようにする mysqldumpを利用する dump.sql RDS dump.sql マイグレーション mysqldump

以下のようなコマンドでdump sqlを作成する テーブルのdump mysqldump --no-tablespaces -hdumpしたいDB host -uユーザー名 -pパス --single-transaction DB名 --no-data --set-gtid-purged=OFF | sed 's/ AUTO_INCREMENT=[0-9]*\b//' > init.sql 例としてInitialTablesという名前でPhinxのマイグレーションファイルを新 規作成 phinx create InitialTables

dumpしたSQLをPhinxでマイグレーション利用 execute(file_get_contents($file)); } } db/migrations/20231008000000_initial_tables.php こちらに配置

ただし稼働中RDSにマイグレーションを実行する訳ではない （利用中テーブルやデータを吹っ飛ばしたらやばい） マイグレーション管理化という目的は果たせる ※RDS側のマイグレーションログテーブル（ phinxlog）に実行済みとしてレコードを追加しておく dump.sqlを利用した既存DB構成をマイグレーショ ン管理

以降、マイグレーション管理化させるもの ● テーブル作成・削除 ● Alter等の構成変更 ● マスターレコード増減など ほぼほぼPhinxドキュメントに沿った使い方で、 続々とマイグレーション管理を増やしている db/migrations/

Phinxを利用した開発運用の話｜ 静的解析やテストの作成

静的解析 ● PHP-CS-Fixerを導入したコード整形 ○ GitHub Actions上でもFixerを実行し、整形物あればブランチに自動 コミット テスト ● PHPUnitは設けていない ● GItHub Acitionsでマイグレーションとロールバックを実行テスト⏬ 静的解析とテスト

マイグレーションテスト name: exec-test on: push: jobs: exec-test: runs-on: ubuntu-latest services: mysql: image: mysql:8.0 ports: - 3306:3306 env: MYSQL_ROOT_PASSWORD: **** MYSQL_DATABASE: **** MYSQL_USER: **** MYSQL_PASSWORD: **** MYSQL_ALLOW_EMPTY_PASSWORD: "yes" steps: - uses: actions/checkout@v3 - name: composer install run: | 〜〜cpmoser install処理~~ - name: execute test shell: bash run: | vendor/bin/phinx migrate vendor/bin/phinx rollback -e local -t 20231008000000 dumpファイルを利用したマイ グレーションはロールバックが できないため、 ブレイクポイントを設定して ロールバック時のエラーを回 避 マイグレーションとロールバックを両方実 行をして、マイグレーションファイルの内 容が問題ないかテスト .github/workflows/test.yml

Phinxを利用した開発運用の話｜ マイグレーションデプロイ

前述の通り、prd・stg・devのDBはRDS環境 GitHub Actions経由でマイグレーションを実行できるようにする マイグレーションデプロイ

GitHub Actions Amazon ECS RDS

デプロイ設計 ● devDBにはworkflow_dispatchを使って手動デプロイ可能 ● stg・prdDBにはメイン・リリースブランチへのマージをフックにデプロイ ● Amazon ECS（以後ECS）ワンショットタスクでマイグレーションを実行 ● CloudWatchに吐き出されたマイグレーションログをGitHub Actions側 の実行ログで参照できるようにする

デプロイフック name: deploy on: push: branches: - main - release workflow_dispatch: jobs: deploy_job: … main・releaseブランチへのマージと手 動実行時にアクションを発火させる 次にマイグレーション先の設 定を書いていく .github/workflows/deploy.yml

マイグレーション先 AWSのアクセスキーやシークレット、 AssumeRoleのARN値をGitHubの secretsに登録しておく マージまたは実行ブランチによって環境 変数を書き換えるようにしておく steps: ... # 環境による env設定 - name: prd setting if: github.ref_name == 'main' run: | echo PHINX_ENV=production >> $GITHUB_ENV echo DEPLOY_ENV=production >> $GITHUB_ENV echo AWS_ACCESS_KEY_ID=${{ secrets.AWS_ACCESS_KEY_ID_PRD }} >> $GITHUB_ENV echo AWS_SECRET_ACCESS_KEY=${{ secrets.AWS_SECRET_ACCESS_KEY_PRD }} >> $GITHUB_ENV echo AWS_ASSUME_ROLE_ARN=${{ secrets.AWS_ASSUME_ROLE_ARN_PRD }} >> $GITHUB_ENV ... - name: stage setting if: github.ref_name == 'release' run: | echo PHINX_ENV=stage >> $GITHUB_ENV echo DEPLOY_ENV=stage >> $GITHUB_ENV echo AWS_ACCESS_KEY_ID=${{ secrets.AWS_ACCESS_KEY_ID_STG }} >> $GITHUB_ENV echo AWS_SECRET_ACCESS_KEY=${{ secrets.AWS_SECRET_ACCESS_KEY_STG }} >> $GITHUB_ENV echo AWS_ASSUME_ROLE_ARN=${{ secrets.AWS_ASSUME_ROLE_ARN_STG }} >> $GITHUB_ENV ... - name: dev setting if: github.ref_name != 'main' && github.ref_name != 'release' run: | echo PHINX_ENV=dev >> $GITHUB_ENV echo DEPLOY_ENV=dev >> $GITHUB_ENV echo AWS_ACCESS_KEY_ID=${{ secrets.AWS_ACCESS_KEY_ID_DEV }} >> $GITHUB_ENV echo AWS_SECRET_ACCESS_KEY=${{ secrets.AWS_SECRET_ACCESS_KEY_DEV }} >> $GITHUB_ENV echo AWS_ASSUME_ROLE_ARN=${{ secrets.AWS_ASSUME_ROLE_ARN_DEV }} >> $GITHUB_ENV ... subnetやsecurity group の情報等も設定 .github/workflows/deploy.yml マージ先によって扱う設定ま わりを切り替え

ECRプッシュ AWSの認証させECRにマイグレーション アプリケーションをプッシュする # AWS認証 uses: aws-actions/configure-aws-credentials@v2 with: aws-access-key-id: ${{ env.AWS_ACCESS_KEY_ID }} aws-secret-access-key: ${{ env.AWS_SECRET_ACCESS_KEY }} aws-region: ${{ env.AWS_REGION }} role-to-assume: ${{ env.AWS_ASSUME_ROLE_ARN }} role-duration-seconds: 1200 # ECRログイン id: login-ecr uses: aws-actions/amazon-ecr-login@v1 # イメージビルドとECRプッシュ id: build-image env: ECR_REGISTRY: ${{ steps.login-ecr.outputs.registry }} IMAGE_TAG: ${{ github.sha }} run: | docker compose -f docker-compose.build.yml build docker compose -f docker-compose.build.yml push echo "image=$ECR_REGISTRY/ECRのリポジトリ:$IMAGE_TAG" >> $GITHUB_OUTPUT .github/workflows/deploy.yml

ECRプッシュ # AWS認証 uses: aws-actions/configure-aws-credentials@v2 with: aws-access-key-id: ${{ env.AWS_ACCESS_KEY_ID }} aws-secret-access-key: ${{ env.AWS_SECRET_ACCESS_KEY }} aws-region: ${{ env.AWS_REGION }} role-to-assume: ${{ env.AWS_ASSUME_ROLE_ARN }} role-duration-seconds: 1200 # ECRログイン id: login-ecr uses: aws-actions/amazon-ecr-login@v1 # イメージビルドとECRプッシュ id: build-image env: ECR_REGISTRY: ${{ steps.login-ecr.outputs.registry }} IMAGE_TAG: ${{ github.sha }} run: | docker compose -f docker-compose.build.yml build docker compose -f docker-compose.build.yml push echo "image=$ECR_REGISTRY/ECRのリポジトリ:$IMAGE_TAG" >> $GITHUB_OUTPUT デプロイ用のdocker-composeを用意 version: '3.8' services: php: image: ${ECR_REGISTRY}/ECRリポジトリ名:${IMAGE_TAG} build: context: . dockerfile: Dockerfile docker-compose.build.yml

タスク定義反映 マイグレーション実行 # タスク定義設定 id: task-def uses: aws-actions/amazon-ecs-render-task-definition@v1 with: task-definition: deploy/task-definition-${{ env.DEPLOY_ENV }}.json container-name: ECSコンテナ名 image: ${{ steps.build-image.outputs.image }} # タスクデプロイ id: deploy-task uses: aws-actions/amazon-ecs-deploy-task-definition@v1 with: task-definition: ${{ steps.task-def.outputs.task-definition }} cluster: ${{ env.ECS_CLUSTER }} # マイグレーション実行 uses: noelzubin/[email protected] id: migration with: cluster: ECSクラスター名 task-definition: タスク定義名 subnets: ${{ env.SUBNETS }} security-groups: ${{ env.SECURITY_GROUPS }} assign-public-ip: ENABLED override-container: ECSコンテナ名 override-container-command: | sh -c . ./deploy/read-envs.sh && vendor/bin/phinx migrate -e ${{ env.PHINX_ENV }} .github/workflows/deploy.yml

タスク定義反映 # タスク定義設定 id: task-def uses: aws-actions/amazon-ecs-render-task-definition@v1 with: task-definition: deploy/task-definition-${{ env.DEPLOY_ENV }}.json container-name: ECSコンテナ名 image: ${{ steps.build-image.outputs.image }} # タスクデプロイ id: deploy-task uses: aws-actions/amazon-ecs-deploy-task-definition@v1 with: task-definition: ${{ steps.task-def.outputs.task-definition }} cluster: ${{ env.ECS_CLUSTER }} # マイグレーション実行 uses: noelzubin/[email protected] id: migration with: cluster: ECSクラスター名 task-definition: タスク定義名 subnets: ${{ env.SUBNETS }} security-groups: ${{ env.SECURITY_GROUPS }} assign-public-ip: ENABLED override-container: ECSコンテナ名 override-container-command: | sh -c . ./deploy/read-envs.sh && vendor/bin/phinx migrate -e ${{ env.PHINX_ENV }} タスク定義jsonファイルを用意 { "executionRoleArn": "AmazonECSTaskExecutionRolePolicyがあるIAM Role", "containerDefinitions": [ { "logConfiguration": { "logDriver": "awslogs", "secretOptions": null, "options": { "awslogs-group": "CloudWatch ロググループ", "awslogs-region": "ap-northeast-1", "awslogs-stream-prefix": "ecs" } }, "image": "ECRリポジトリURI", "name": "名前" } ], "placementConstraints": [], "family": "ファミリー名", "requiresCompatibilities": [ "FARGATE" ], "networkMode": "awsvpc", "cpu": "256", "memory": "512", "volumes": [] } deploy/task-definition-dev.json

タスク定義反映 マイグレーション実行 # タスク定義設定 id: task-def uses: aws-actions/amazon-ecs-render-task-definition@v1 with: task-definition: deploy/task-definition-${{ env.DEPLOY_ENV }}.json container-name: ECSコンテナ名 image: ${{ steps.build-image.outputs.image }} # タスクデプロイ id: deploy-task uses: aws-actions/amazon-ecs-deploy-task-definition@v1 with: task-definition: ${{ steps.task-def.outputs.task-definition }} cluster: ${{ env.ECS_CLUSTER }} # マイグレーション実行 uses: noelzubin/[email protected] id: migration with: cluster: ECSクラスター名 task-definition: タスク定義名 subnets: ${{ env.SUBNETS }} security-groups: ${{ env.SECURITY_GROUPS }} assign-public-ip: ENABLED override-container: ECSコンテナ名 override-container-command: | sh -c . ./deploy/read-envs.sh && vendor/bin/phinx migrate -e ${{ env.PHINX_ENV }} envを指定してマイグレーションを実行させる

タスク定義反映 マイグレーション実行 # タスク定義設定 id: task-def uses: aws-actions/amazon-ecs-render-task-definition@v1 with: task-definition: deploy/task-definition-${{ env.DEPLOY_ENV }}.json container-name: ECSコンテナ名 image: ${{ steps.build-image.outputs.image }} # タスクデプロイ id: deploy-task uses: aws-actions/amazon-ecs-deploy-task-definition@v1 with: task-definition: ${{ steps.task-def.outputs.task-definition }} cluster: ${{ env.ECS_CLUSTER }} # マイグレーション実行 uses: noelzubin/[email protected] id: migration with: cluster: ECSクラスター名 task-definition: タスク定義名 subnets: ${{ env.SUBNETS }} security-groups: ${{ env.SECURITY_GROUPS }} assign-public-ip: ENABLED override-container: ECSコンテナ名 override-container-command: | sh -c . ./deploy/read-envs.sh && vendor/bin/phinx migrate -e ${{ env.PHINX_ENV }} DB情報の環境変数を反映させるシェルを用意し実行

DB情報と環境変数 ● Phinx は PHINX_ というプレフィックスが付 いた環境変数を自動的に取得できるため、 Phinx設定ファイルにはDB情報を記載せず、 環境変数から取得するように設定させる ● 環境変数のDB情報はAWS System Managerから取得し設定させる 'production' => [ 'adapter' => 'mysql', 'host' => '%%PHINX_DBHOST%%', 'name' => '%%PHINX_DBNAME%%', 'user' => '%%PHINX_DBUSER%%', 'pass' => '%%PHINX_DBPW%%', 'port' => '3306', 'charset' => 'utf8', ] phinx.php

マイグレーションログ表示 # ecs-cliインストール shell: bash run: | sudo curl -Lo /usr/local/bin/ecs-cli https://amazon-ecs-cli.s3.amazonaws.com/ecs-cli-linux-amd64-v1.21.0 sudo chmod +x /usr/local/bin/ecs-cli # コンテナタスクのログを取得 - name: Migration logs here!!! shell: bash run: | task_arn=${{ steps.migration.outputs.task-arn }} task_id=${task_arn//*\//''} ecs-cli logs --timestamps --cluster ${{ env.ECS_CLUSTER }} --task-id ${task_id} GitHub Actions側にマイグレーションログが表示される .github/workflows/deploy.yml

● マイグレーションの開発はローカル環境で ● 既存テーブルはmysqldumpを利用してマイグレーション管理。以降は一 般的なマイグレーション方法による拡張 ● 静的監視やマイグレーション実行テストをGitHub Actionsでチェック ● RDSへのマイグレーション実行はGitHub Actions経由のみ ● RDS環境のDB情報はAWS Systems ManagerとPhinxの環境変数で 管理と反映を行わせる 運用フローまとめ

マイグレーションの拡張 他アプリケーションからマイグレーションを利用する マイグレーション設計 Phinxを利用した開発運用の話 マイグレーションの拡張

マイグレーションの拡張｜ ユニットテスト用のDB整備

サービスアプリケーション側でユニットテスト環境作成時にローカルDB構築を RDSからdumpをして行っていた ユニットテスト用DBの構築これまで

マイグレーションアプリケーションを利用してテーブルを作成する DB構築にマイグレーションを利用

サービスアプリケーション側 マイグレーションをGit Submoduleで管理 ├── migration-application ├── README.md ├── app ├── artisan ├── bootstrap ├── composer.json ├── composer.lock ├── config ├── database ├── package.json ├── phpunit.xml ├── public ├── resources ├── routes … git submodule add https://github.com/sample/migration-application.git

1. submoduleのマイグレーションアプリでマイグレーション実行 2. マイグレーション側ローカルDBからdumpファイル作成 3. dumpファイルをテストアプリケーション側DBにimport dumpファイルを作成してDB構築

1. submoduleのマイグレーションアプリでマイグレーション実行 2. マイグレーション側ローカルDBからdumpファイル作成 3. dumpファイルをテストアプリケーション側DBにimport dumpファイルを作成してDB構築 migration-local: docker-compose -f migration-application/docker-compose.yml run --rm php bash -c "\ composer install;\ phinx migrate;\ mysqldump --no-tablespaces -uユーザー -pパス -hmysqlサービス --single-transaction db名 --no-data > dump.sql;\ " && \ docker-compose run --rm php bash -c "\ mysql -uユーザー -pパス -hmysqlサービス db名 < migration-application/dump.sql;\ rm -rf migration-application/dump.sql;\ "; makefile例

1. submoduleのマイグレーションアプリでマイグレーション実行 2. マイグレーション側ローカルDBからdumpファイル作成 3. dumpファイルをテストアプリケーション側DBにimport dumpファイルを作成してDB構築 migration-local: docker-compose -f migration-application/docker-compose.yml run --rm php bash -c "\ composer install;\ phinx migrate;\ mysqldump --no-tablespaces -uユーザー -pパス -hmysqlサービス --single-transaction db名 --no-data > dump.sql;\ " && \ docker-compose run --rm php bash -c "\ mysql -uユーザー -pパス -hmysqlサービス db名 < migration-application/dump.sql;\ rm -rf migration-application/dump.sql;\ "; makefile例 migration-application service-application

● submodule化すれば簡単にマイグレーションを通してユニットテスト用 DBが構築できる。ローカルDB作成にも ● 少ないコマンドでどのユニットテストアプリケーションにも設置できる ● ユニットテストアプリ側・マイグレーションアプリ側の依存がない ● 同じような仕組みでGitHub Actions側でもDB構築をマイグレーション稼 働させることができる サービスアプリケーションでマイグレーションアプリ利 用の利点

GitHub Actions上で のマイグレーションとユ ニットテスト jobs: migration: uses: ./.github/workflows/migration.yml phpunit: runs-on: ubuntu-latest needs: - migration container: image: cimg/php:8.2 services: mysql: image: mysql:8.0 ports: - 3306:3306 env: MYSQL_ROOT_PASSWORD: **** MYSQL_DATABASE: **** MYSQL_USER: **** MYSQL_PASSWORD: **** MYSQL_ALLOW_EMPTY_PASSWORD: "yes" steps: - name: Checkout uses: actions/checkout@v3 - name: composer install run: | 〜〜cpmoser install処理~~ - name: load migration uses: actions/download-artifact@v3 with: name: migration - name: setup run: | mysql -uユーザー名 -pパス -hmysql DB名 < dump.sql - name: exec phpunit run: | ./vendor/bin/phpunit マイグレーションアプリ側でのdumpファ イル作成は別ファイルで行い、 artifactでdumpファイルを渡す形の例 です

GitHub Actions上で のマイグレーションとユ ニットテスト マイグレーションアプリ側でのdumpファ イル作成は別ファイルで行い、 artifactでdumpファイルを渡す形の例 です jobs: migration: uses: ./.github/workflows/migration.yml phpunit: runs-on: ubuntu-latest needs: - migration container: image: cimg/php:8.2 services: mysql: image: mysql:8.0 ports: - 3306:3306 env: MYSQL_ROOT_PASSWORD: **** MYSQL_DATABASE: **** MYSQL_USER: **** MYSQL_PASSWORD: **** MYSQL_ALLOW_EMPTY_PASSWORD: "yes" steps: - name: Checkout uses: actions/checkout@v3 - name: composer install run: | 〜〜cpmoser install処理~~ - name: load migration uses: actions/download-artifact@v3 with: name: migration - name: setup run: | mysql -uユーザー名 -pパス -hmysql DB名 < dump.sql - name: exec phpunit run: | ./vendor/bin/phpunit

GitHub Actions上で のマイグレーションとユ ニットテスト マイグレーションアプリ側でのdumpファ イル作成は別ファイルで行い、 artifactでdumpファイルを渡す形の例 です jobs: migration: uses: ./.github/workflows/migration.yml phpunit: runs-on: ubuntu-latest needs: - migration container: image: cimg/php:8.2 services: mysql: image: mysql:8.0 ports: - 3306:3306 env: MYSQL_ROOT_PASSWORD: **** MYSQL_DATABASE: **** MYSQL_USER: **** MYSQL_PASSWORD: **** MYSQL_ALLOW_EMPTY_PASSWORD: "yes" steps: - name: Checkout uses: actions/checkout@v3 - name: composer install run: | 〜〜cpmoser install処理~~ - name: load migration uses: actions/download-artifact@v3 with: name: migration - name: setup run: | mysql -uユーザー名 -pパス -hmysql DB名 < dump.sql - name: exec phpunit run: | ./vendor/bin/phpunit

まとめ 最後までありがとうございました

● 独立したマイグレーションアプリケーションを立てられた ● 稼働中DBへ、途中からマイグレーション管理できた ● 他アプリケーションに、マイグレーション活用ができた まとめ マイグレーション設計 Phinxを利用した開発運用の話 マイグレーションの拡張

ご静聴ありがとうございました