質問: 前提 -- * Djangoを勉強しています * Viewの更新時に`python3 manage.py makemigrations`を実行し、DBのスキーマ変更用のファイルを作成しています お伺いしたいこと -------- 1. viewでカラムを追加し、あとでそれを削除すると無駄に`000X_auto_yyyymmdd_hhmm.py`が作成されます。例えばXXカラムを追加、それを削除、またXXカラムを追加、再び削除とすると4ファイルも生成されますが、結局最後まで適用するとXXカラムがないだけの状態に戻ります。**declarative(宣言的)**ではなく**procedural(手続的)**的な動きをしているため非常に使いづらさを感じるのですが、現場では**000X_auto_yyyymmdd_hhmm.pyが大量にできることに対して**何か工夫やアプローチをされることはありますか? 2. チームで開発する場合`python3 manage.py makemigrations`はどのタイミングで実施してGitにCommitしていますか?(Modelを修正した人がローカルで実行してcommitに含める?それともCIの中で行う?など)
回答: 1例でしかない事を最初に記載しておきます。 > > 1. 現場では000X_auto_yyyymmdd_hhmm.pyが大量にできることに対して何か工夫やアプローチをされることはありますか? > > > 機能単位やリリース単位でmigrationファイルを作り直しております。 具体的には、releaseブランチが既に本番環境で動いているブランチだとすると、そのブランチとリリース対象のブランチを比較し、rm -> makemigrations という感じです。 ただ、実際には自動生成のコードだけで間に合わない事(データの置換など)もあるため、手動マージも行います。 ここは通常のプルリクエストで行っておりますので、レビューやCIなどが動くことになります。 > > 2. どのタイミングで実施してGitにCommitしていますか? > > > 機能開発時のコード追加と同じタイミングになります。 全体的に1と絡む回答になりますが、PRを使用している場合、任意の単位で開発者はコミットされますが、最終的にマージされる際にはまとまっています。(質問1の例だと、追加削除追加削除なので結局何も行われずmigrationファイル自体がコミットされない) > > (Modelを修正した人がローカルで実行してcommitに含める?それともCIの中で行う?など) > > > 「Modelを修正した人がローカルで実行してcommitに含める」こちらになります。 より正確に言えば、migrationファイルの作成はmodel作成者の責務であり、それをmakemigrationを使うかはどうかは場合によります。