開発・技術選定

他社が作った Django サービスを引き継ぐときの調査手順

· by IT.Skill

経営者が交代したサービスや、開発者が離任したシステムを引き継ぐ依頼が定期的にあります。
ドキュメントは無い、作った人にも聞けない。この状態から始めるときの手順です。

0. コードより先に「止まらない状態」を確認する

いきなりコードを読み始めたくなりますが、順番が逆です。
まず今動いているものが止まらないかを確認します。

systemctl list-units --type=service --state=running   # 何が常駐しているか
systemctl is-enabled <service>                        # 再起動で自動復帰するか
crontab -l ; ls /etc/cron.d/                          # 定期処理の有無
df -h ; free -m                                       # ディスクとメモリの余裕

引き継ぎ案件では Restart= が設定されていない、
enable されていない（サーバー再起動で上がってこない）ケースが本当に多いです。
ここを先に直すだけで、引き継ぎ直後の事故がほぼ無くなります。

バックアップも同様です。「取れているつもり」で実は失敗し続けている、
あるいは復元したことが一度もないのが定番です。必ず復元まで試します。

1. 依存とバージョンを固定する

pip freeze > requirements.lock.txt
python -c "import django; print(django.VERSION)"

まず現状を凍結します。EOL を過ぎていても、この時点では上げません。
仕様が分からないまま上げると、壊れたときに原因の切り分けができなくなります。

2. モデルから読む

Django ならビューより先に models.py です。
テーブル構造とリレーションが分かれば、そのサービスが何を扱っているかは大体つかめます。

python manage.py graph_models -a -o schema.png   # django-extensions

図にして眺めると、中心にあるモデル（＝サービスの本体）がすぐ分かります。

3. URL から機能の全体像を出す

python manage.py show_urls   # django-extensions

画面数と機能の粒度が一覧で出ます。
このリストをそのまま引き継ぎドキュメントの目次にしています。

4. 危ない箇所を先に洗い出す

grep -rn "DEBUG = True" .
grep -rn "SECRET_KEY" .           # ソースに直書きされていないか
grep -rn "ALLOWED_HOSTS" .
python manage.py check --deploy

check --deploy は引き継ぎ初日に必ず流します。
HTTPS 関連やクッキー設定の抜けが一覧で出るので、優先度をつけやすくなります。

5. ここまでやってから見積もる

この4ステップ（半日〜2日程度）を終えてから、
「何ができて、何が危なくて、どこから直すべきか」をお伝えするようにしています。

先に見積もりを出してしまうと、後から必ず想定外が出てきます。
調査そのものを最初の小さな依頼として区切るのが、結局お互いにとって安全でした。

まとめ

  1. 止まらない構成か（自動復旧・自動起動・バックアップの復元）
  2. 依存を凍結（この時点では上げない）
  3. モデル → URL の順で全体像を把握
  4. check --deploy で危険箇所を洗う
  5. ここまで終えてから見積もる

関連記事