【自己紹介】RUNTEQでRailsエンジニアを目指して勉強中です／第1弾:マイグレーションについて
はじめに
はじめまして。私はエンジニア転職を目指してRuby on Railsを勉強絵推しております。
これまでインプット中心の学習をしてきましたが、これからはQiitaを「学んだことをアウトプットする場」として活用していこうと思います。
記念すべき1本目の投稿は、「マイグレーション」について、自分なりに理解したことをまとめます。同じように最近エンジニアの勉強を始めた方の参考になれば嬉しいです。
マイグレーションとは
マイグレーションとは、「データベースの変更履歴をチーム全員で共有するための仕組み」です。
Railsでは、テーブルの作成やカラムの追加・変更といったデータベースへの変更を、直接SQLを書くのではなく「マイグレーションファイル」というコードとして記述します。
もしマイグレーションがなかったら?
データベースの構造を変えたいとき、マイグレーションという仕組みがなければ直接SQLを打ち込んで変更することになります。しかし、それでは以下のような問題が起こります。
- 誰が、いつ、なぜその変更をしたのかが記録に残らない
- 開発者Aのパソコン、開発者Bのパソコン、テスト環境、本番環境で、データベースの構造がバラバラになってしまう
- 「あれ、本番環境にはこのカラムあったっけ?」と環境ごとの差分がわからなくなり、事故につながる
- チームに新しく入ったメンバーが、今のデータベースがどういう経緯でこの形になったのかを追えない
つまり、直接SQLで変更する方法は、一人で開発している間は問題になりにくいですが、チームで開発する実務では大きなリスクになるのです。
マイグレーションがあると何が解決するのか
マイグレーションファイルという「変更の指示書」をコードとして残すことで、以下が実現できます。
- ファイルとしてGit管理されるので、誰が・いつ・何を変更したかが一目でわかる
-
rails db:migrateを実行するだけで、誰の環境でも同じ手順でデータベースを同じ状態にできる - 過去のファイルが変更履歴として残るため、「今のテーブル構造がどんな経緯でできたのか」を後から追える
- 変更を元に戻したいときも、SQLを手作業で書き直す必要がなく、コマンド一つ(
rollbackなど)で対応できる
まとめ
マイグレーションは、単に「テーブルを作る機能」ではなく、「チーム開発においてデータベースの変更履歴を安全に共有・管理するための仕組み」だと理解しました。
一人で書いたSQLの積み重ねでは属人化してしまう部分を、コードとして残し、Gitで管理できるようにすることで、チームの誰が見ても同じ状態を再現できるようにしている、というのが今回の一番の学びです。
最後まで読んでいただきありがとうございました。誤りなどありましたらぜひご指摘いただけると嬉しいです。