環境設定Djangoはデータベースマイグレーションの機能を持っています。いう疑問が多いかと思います。前提としてWebアプリ、データベースは本番環境に1系統づつあるとします。絶対に安全という方法ではないので、動作確認などをして慎重に反映する必要があります。(マイグレーションをするということは、アプリケーションの変更も必要になります)。マイグレーションを先に実行して、アプリケーションを後で変更するアプリケーションを先に変更して、マイグレーションを後で実行する上記ではない場合、アプリケーションを停止する時間が必要になります(アプリケーションを停止、マイグレーションを実行、アプリケーションを変更して実行する)。マイグレーションの3種類アプリケーションを無停止のままマイグレーションを反映するには、まずマイグレーションの種類を判断する必要があります。ここでは大きく分けて3つのマイグレーションと考えられます。テーブルやカラムを追加するマイグレーションカラムを変更するマイグレーションテーブルやカラムを削除するマイグレーション追加、変更、削除それぞれのマイグレーションをどう反映するのかが重要です。無停止でマイグレーションを実行するのは、Webアプリが誤動作を起こすリスクを持っています。方法は後述しますが、アプリケーションの作り方によって問題が発生し得ます。動作が保証される状態でもありません。本番環境へリリースする前に、マイグレーションを実行しても問題ないか開発環境で必ず動作確認しましょう。マイグレーションを実行するタイミングアプリケーションを無停止でマイグレーションを実行するには種類と実行するタイミングが重要です。それぞれマイグレーションの種類ごとに、稼働中のWebアプリにマイグレーションを実行する方法を説明します。テーブル、カラムを追加するマイグレーションの場合テーブル、カラムの追加をするマイグレーションは、アプリのリリースより前に実行できます。テーブル、カラムが増えたところで、Django製のアプリケーションには基本的に影響がありません。Webアプリケーションのリリース前にマイグレーションを実行します。マイグレーションを実行するWebアプリケーションをリリースする追加するマイグレーションを無停止で反映テーブルやカラムが増えても、既存のDjango製のWebアプリケーションの動作や、通信量には影響がありません。DjangoはSQLを実行するときに、取得するフィールド(カラム)を全て指定するからです。DjangoのQuerySetでextraやrawを使う場合や、生SQLを実行する場合はこの限りではありません。アプリケーション内に影響するプログラムは無いかは事前にちゃんと確認しましょう。カラムの削除をするマイグレーションカラムの削除をする場合は、先にWebアプリケーションをリリースします。アプリケーションが先にリリースされることで削除対象のフィールド(カラム)は使われなくなります。削除対象のカラムが完全に使われなくなったことを確認してからマイグレーションを実行できます。「カラムが絶対にWebアプリ内で使われていない」ことを確認するのは大変です。慎重に確認した後、マイグレーションを実行しましょう。カラムを変更するマイグレーションカラムを変更するマイグレーションの場合は注意が必要です。マイグレーションを無停止で実行できるかどうかはマイグレーションの内容によります。カラム名を変更するマイグレーションは無停止ではリリースできません。どちらを先に実行しても、稼働中のWebアプリケーションに影響を与えます。無停止でリリースできる(可能性がある)カラムの最大長などを変更インデックスの追加、削除マイグレーションの内容を理解して、無停止で安全に反映できるかを確認しましょう。カラムの最大長変更なども、稼働中のアプリケーションに影響を与えますので注意しましょう。マイグレーションが複数ある場合カラムの追加するマイグレーション、削除するマイグレーションが複数ある場合、Webアプリが無停止のままでは同時に反映できません。その場合はひとつひとつマイグレーションの実行と、アプリケーションのリリースをする必要があります。Djangoでマイグレーションを1つづつ実行する方法は別のブログ記事で説明します。まとめWebアプリを無停止のままマイグレーションを反映するには、マイグレーションの内容を理解してリリースする必要があります。変更内容によって無停止で反映できる改めてになりますが、本番環境にリリースする前には開発環境で動作確認しましょう。開発環境で、無停止でリリースできることを確認してから本番環境でリリースしましょう。Djangoマイグレーションの内容を確認する方法や、1つづつ反映する方法は別のブログ記事で説明します。値を作りたい場合など、フォームの...2012-10-01WSGIからDjangoの流れを理解するWSGIからの流れを大まかに掴めたのでまとめたい。10年以上のノウハウを詰め込んだ「自走プログラマー」を執筆しましたPythonPythonのリストはイテレーターでない。アーカイブPyQという製品を作っていますスターをつけました引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。