7/14 : [2.対応手順と事実経過] - 修正しました

はじめに

現役のトラックドライバーとして物流の現場を走りながら、Pythonを独学しているtosane932です。

前回の記事（第1便）では、google-genaiのバージョン不一致を解消し、pytestで堅牢にテストを通すまでの環境整備について書きました。

今回は、その強固になった土台の上で、いよいよ本題である「データベースの管理体制の近代化」に挑んだ記録です。これまで当たり前のように使っていた便利コマンド db.create_all() をあえて「断捨離」し、実務標準の Flask-Migrate（Alembic）へと運用の舵を切った理由と、実際の移行手順について事実ベースで残します。

概要

Flaskアプリケーションにおけるデータベース（以下、DB）の運用において、従来の db.create_all() による手動テーブル作成を廃止し、Flask-Migrate（Alembic）を用いたスキーマの変更履歴管理（マイグレーション）へ移行しました。本稿はその運用の切り替えと、初期マイグレーション実行までの対応記録です。

1. 導入の背景と目的

これまで本アプリケーションでは、起動時に db.create_all() を実行することで、定義されたモデル（Product, DailySales）に基づいて自動的にテーブルを作成していました。
しかし、この手法には以下の課題があります。

すでに存在するテーブルの変更（カラムの追加やデータ型の変更など）を追跡・反映できない。
手動でのDB管理と、ソースコード上のモデル定義が二重管理になり、環境差分（ローカルと本番環境のズレ）の原因となる。

実務における運用の健全性を高め、本番インフラへの安全なデプロイを実現するため、DBの変更履歴をソースコード（Git）で管理できる Flask-Migrate への移行を実施しました。

2. 対応手順と事実経過

① 拡張ライブラリの導入と定義

Flask-Migrate をインストールし、requirements.txt へ追加するとともに、アプリケーションコード（app.py）へ以下の通り組み込みを行いました。

from flask_migrate import Migrate
from models import db, Product, DailySales

app = Flask(__name__)
app.config["SQLALCHEMY_DATABASE_URI"] = config.SQLALCHEMY_DATABASE_URI
app.config["SQLALCHEMY_TRACK_MODIFICATIONS"] = config.SQLALCHEMY_TRACK_MODIFICATIONS
db.init_app(app)

migrate = Migrate(app, db)

② マイグレーション環境の初期化（flask db init）

ローカル開発環境のプロジェクトルートにて以下のコマンドを実行し、変更履歴を記録するためのディレクトリ（migrations フォルダ）および設定ファイルを自動生成しました。

flask db init

実行結果のログ:

  Creating directory /home/tosane/sales_data_app/migrations ...  done
  Creating directory /home/tosane/sales_data_app/migrations/versions ...  done
  Generating /home/tosane/sales_data_app/migrations/env.py ...  done
  Generating /home/tosane/sales_data_app/migrations/README ...  done
  Generating /home/tosane/sales_data_app/migrations/alembic.ini ...  done
  Generating /home/tosane/sales_data_app/migrations/script.py.mako ...  done

ログより、DBの整備記録簿にあたる資材一式が正常に配置されたことを確認しました。

③ 初期マイグレーションの生成（flask db migrate）

続いて、現在のモデル定義（models.py）と、すでにローカルに存在しているSQLite内の既存テーブルとの間で差分を検出し、初期状態を記録するコマンドを実行しました。

flask db migrate -m "initial migration"

実行結果のログ:

INFO  [alembic.runtime.migration] Context impl SQLiteImpl.
INFO  [alembic.runtime.plugins] setting up autogenerate plugin...
INFO  [alembic.env] No changes in schema detected.

検証:
ログに No changes in schema detected.（スキーマの変更は検出されませんでした）と出力されました。これは、ソースコード上のモデル定義と、既存のローカルDBの状態が完全に一致していることを示しており、想定通りの正常な挙動です。これにより、空の（差分なしの）初期マイグレーションファイルが正しく生成されました。

④ 古いロジック（db.create_all()）の断捨離

マイグレーションによる管理体制が整ったため、app.py 内に存在していた以下の古いテーブル自動作成ロジックを安全に削除（断捨離）しました。

# 削除したコード
with app.app_context():
    try:
        db.create_all()
        logger.info("Database tables initialized successfully.")
    except Exception as e:
        logger.error(f"Failed to initialize database tables: {e}")

3. まとめ

本作業により、手動によるDB作成を完全に卒業し、モデルの変更を自動検知してGitで管理する「実務標準のDB運用体制」のベースが整いました。

これにより、ローカルの既存データに影響を与えることなくコードをクリーンに保つことが可能となり、次のステップである「本番環境（Render PostgreSQL）へのデプロイおよび自動マイグレーションの適用」への安全な道筋が確定しました。

sales_data_app 整備記録シリーズ

「本番出走前・車検三部作」

🚚「出走後メンテナンスシリーズ」

🍞