こんにちは！エイチーム引越し侍の加藤です！
みなさんマイグレートしてますか？
僕もこの会社に入って1年がたちますが既に20回くらいマイグレートしてる気がします。
複数開発環境があるとマイグレーション番号管理ってのが必要になってくると思いますが、
そんな僕くらいマイグレートしてると結構他の人の開発とマイグレーション番号が競合することが多いんですよね。
とってもジェントルマンな僕は「どうぞお先に行ってください、僕のほうが合わせますよ」なんて余裕を見せたりしています。
また、先にスキーマファイルとマイグレーションファイルをリリースしてマイグレートだけ先やるって方も多いかもですが、そうなると仕様変更でスキーマまた変えなきゃってこともありますよね。
そんな2つの状況も簡単に対応できる、
一応我流で編み出した誰かと被っても全然怖くない方法があるので皆さんにご紹介します。
簡単基本３ステップ
①スキーマファイルとマイグレーションファイルだけ作成したブランチAを作る
②モデルファイルを作成してブランチBにcheckoutしてコミット
③ブランチBで開発を行う
なのでAにはスキーマファイルとマイグレーションファイルのみがコミットされている状態で
Bにはモデルファイルと開発したものがコミットされる状態ですね。
※マイグレーションファイルとスキーマはコミットしません
この状態がとっても柔軟に対応できるのを今から説明しますね
CASE 1 誰かがマイグレーションした場合
さーリリースするぞー！って時にいつの間にかしれっとマイグレーション番号上がっていることってありますよね。
この場合はいったんブランチAに戻りマイグレートを戻します。
そしてマイグレーションファイルを削除して
masterをrebaseして他の人のマイグレーションファイルをブランチAに取り込みます
そこからマイグレーションファイルを作成すればもう番号が新しく付番されますね！
あとはマイグレートしてリリースに入りましょう。
CASE 2 仕様が変更になってスキーマをさらにいじりたくなった場合
ほぼCASE 1の手順と同じですが、
いったんブランチAに戻ってマイグレートを戻します。
そしてマイグレーションファイルを削除して
スキーマファイルをいじります
再度マイグレーションファイルを作成して
マイグレートします。
ここでモデルファイルを作成するのですが、git stashしてブランチBでgit stash popするとコンフリクトしてしまうかもですが、いい感じにマージできると思います。
CASE 3 なにもする必要がなくリリースする場合
ブランチAでmerge(pull) requestだして、無事マージされたらリリースしてマイグレート
ブランチBでもmerge(pull) request出して、無事マージされたらリリース
ここでソースチェックが重複しないのがまたいいですよね
以上です。
いかがでしたか？
意外と自分で編み出した方法がみんな知らないなーと思ったので記事にしてみました。
これでマイグレート全然怖くないわー！って人が増えてくれると幸いです。
追伸
株式会社エイチーム引越し侍では、一緒にサイト改善をしてくれるWebエンジニアを募集しています。エイチームグループのエンジニアとして働きたい！という方は是非、以下のリンクから応募してください。
皆様からのご応募、お待ちしております！！