RailsWebエンジニアの森脇です。LCLでは、DB設計変更で、DBマイグレーションをする際にシステム障害を回避するためのいくつか工夫をしています。今回は、その内容を簡単にご紹介いたします。原則、migrationのブランチは独立させるようにしています。既存コードに影響を与えないmigration実行後も既存コードで正常稼働するように、migrationを作成します。以下にケース別の手順を紹介します。テーブルの新規作成テーブルの新規作成は特に意識することはありません。既存テーブルへ外部キーを貼る場合は、後述の手順に従い注意が必要です。以下の手順でリリースすることをルールとしています。lockが掛かるため、defalut制約はつけないようにしています。table等してしまうと非常に時間がかかるためです。成功例:サイト影響なしcolumnの削除column削除は最も障害が発生しやすいです。オプションを利用して削除前に事前に該当カラムを参照しないようにします。アプリでオンラインでカラムの削除やリネームを行うにはcolumnのrenamecolumnのrenameを行うと既存コードに影響を与えてしまうため、column追加と削除の手順を組み合わせて対応します。外部キーはロックがかかりやすいため、他のマイグレとは分けるようにしています。一度に複数の外部キーを追加しないようにも注意しています。migrationの実行手順まず以下のコマンドを実行し、未実行のmigrationを把握します。RAILS_ENV=production安全のため、該当のバージョンのみ実行します。RAILS_ENV=production一応downのmigrationをすぐに実行できるようにコマンドも準備しておくと良いです。RAILS_ENV=productionさいごにマイグレーションはひとつのミスが大きな障害に繋がる機能ですが、プロダクトが成長する上では割けては通れないものなので、手順をしっかり固めて、心理的安全性をできるだけ担保できるようにすることが大切です。