インターン期間中に問題だと考えていたデータベースマイグレーションプロセスの改善案です。インターン期間中は
- スキーマの変更
- ローカルDBでテスト、アプリケーションの動作確認
- PR、レビュー、マージ
- 本番環境への適応（既存のテーブルを全て削除した後に、SQL文を打ち込んでテーブルを再構築）
- 本番環境での動作確認 というプロセスでマイグレーションを行っていました。もう一度最初からインターンに取り組むなら、そして実運用されることを考えるならこう改善するべきではないかという考えを具体化したリポジトリです
一つ目は本番環境データベースのマイグレーションの手法が毎度テーブルを削除し、新たに作り直すという手法であったことです。インターン期間中にこの手法でマイグレーションをしていたことは状況と優先順位を考えたとき間違った選択ではないと考えていますが、実運用されるサービスであればデータを一度全て削除するということは大問題です。
二つ目は本番環境が動作しなくなった時、動作していた状態に戻すことができない、困難であることです。バージョン管理されていなかったため、問題が起きたとき、動作していた状態まで即座に戻すということができませんでした。
三つ目はマイグレーションの工程の多くが手作業であり、インターン期間中でもヒューマンエラーによる問題が起こる可能性があったプロセスであることです。例えば、ローカルDBでマイグレーションテストをした後に誤ってスキーマを変更したことに気づかず本番環境で先ほどの手法でマイグレーションを行ってエラーが出た場合、本番環境が動かなくなるという大問題が起きた可能性があります。
・全てのテーブルを一度全削除するのではなく、現状の本番環境のDBとの差分を埋めるSQL文を実行することでマイグレーションを行う ・本番環境でマイグレーションを実行した際にエラーが起きる可能性を考慮し、問題があった場合は問題なく動作していた状態まで戻れるようにする ・マイグレーションプロセスを統一し、ヒューマンエラーをなるべく減らすこと