Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
PhinxによるDBマイグレーションとサービス運用
Search
zosokh
October 08, 2023
Technology
1.8k
0
Share
Embed
Copy iframe code
Copy JS code
Copy link
Start on current slide
PhinxによるDBマイグレーションとサービス運用
zosokh
October 08, 2023
More Decks by zosokh
See All by zosokh
Team operations that are not burdened by SRE
kazatohiei
1
840
テストコード文化を0から作り、変化し続けた組織
kazatohiei
2
2.5k
開発生産性を取り入れたばかりの組織が、スキルと生産性向上を紐づける
kazatohiei
1
390
アプリケーションをリプレイスしたら チームとサービス運用に向き合えた
kazatohiei
1
960
エラー監視とテスト体制への改善作戦 / PHPerKaigi2022
kazatohiei
7
5.3k
サービス運用エンジニアによるPHP8バージョンアップ奮闘記 / PHPカンファレンス2021
kazatohiei
0
1.2k
Other Decks in Technology
See All in Technology
Oracle AI Database@AWS:サービス概要のご紹介
oracle4engineer
PRO
4
2.9k
Kiroで書いた 設計書 が AI レビューの 採点基準 になる
ezaki
0
110
不要なレビューをAIにまかせて AIコーディングの環境改善を加速した
shoota
1
140
2026TECHFRESH畢業分享會 - 原生還是跨平台? App 開發踩坑實錄
line_developers_tw
PRO
0
1.1k
2026 TECHFRESH 畢業分享會 - AI-Native 重塑軟體工程與虛擬講師
line_developers_tw
PRO
0
1.1k
データサイエンスを価値につなげるプロジェクト設計 〜 DS一年目が現場で得た気づき 〜
ysd113
1
260
LLMにもCAP定理があるという話
harukasakihara
0
380
ルールやカスタム機能、どう活かす?ハンズオンで体感するIBM Bobの出力コントロール
muehara
1
170
入門!AWS Blocks
ysuzuki
1
130
手塩にかけりゃいいってもんじゃない
ming_ayami
0
590
AIエージェントが名古屋の猛暑からあなたを守る
happysamurai294
0
120
プロダクト開発から業務改善コンサルまで。事業全体へ「染み出す」ことで広がるエンジニアの可能性
ham0215
0
130
Featured
See All Featured
Self-Hosted WebAssembly Runtime for Runtime-Neutral Checkpoint/Restore in Edge–Cloud Continuum
chikuwait
0
590
GraphQLの誤解/rethinking-graphql
sonatard
75
12k
sira's awesome portfolio website redesign presentation
elsirapls
0
280
個人開発の失敗を避けるイケてる考え方 / tips for indie hackers
panda_program
123
22k
"I'm Feeling Lucky" - Building Great Search Experiences for Today's Users (#IAC19)
danielanewman
230
23k
A Soul's Torment
seathinner
6
2.9k
世界の人気アプリ100個を分析して見えたペイウォール設計の心得
akihiro_kokubo
PRO
71
40k
Balancing Empowerment & Direction
lara
6
1.2k
What’s in a name? Adding method to the madness
productmarketing
PRO
24
4.1k
Art, The Web, and Tiny UX
lynnandtonic
304
22k
Easily Structure & Communicate Ideas using Wireframe
afnizarnur
194
17k
Agile Actions for Facilitating Distributed Teams - ADO2019
mkilby
0
210
Transcript
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リポジトリを持つ • 軽量なアプリケーションでいたい • 他サービスに依存しない • オレオレシステムは構築しない 良きライブラリを探します
None
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のローカル設定 <?php return [ … 'environments' => [ '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のローカル設定 <?php return [ … 'environments' => [ '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でマイグレーション利用 <?php declare(strict_types=1); use Phinx\Migration\AbstractMigration; final class InitialTables extends AbstractMigration
{ public function up() { $file = dirname(dirname(__FILE__)) . '/sql/init.sql'; $this->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を利用した開発運用の話 マイグレーションの拡張
ご静聴ありがとうございました