🔖 第3章:devcontainerを使わない開発の流れ(before)

3.3 修正の確認に時間がかかる構造のボトルネック


✅ 要点まとめ


🧭 ボトルネックの構造(典型パターン)

あなたの現在の構成(authはHarborイメージとしてappから起動)では、以下のようなステップになります:

修正(auth側)
↓
Docker build
↓
Harbor push
↓
app側でpull
↓
appを再起動(auth含む)
↓
動作確認(失敗すればまた修正からやり直し)

このプロセスに含まれる待ち時間の要素

ボトルネック 時間のかかる理由
Dockerイメージのビルド Railsのgemインストールやnode_modules再構築で数分
Harborへのpush ネットワーク経由でのアップロード。帯域が狭いと遅い
appのpullと再起動 イメージ差し替えとサービス再起動の時間
トラブル調査 変更が反映されていない or 起動失敗で再検証が必要

🧪 シナリオ別のタイムライン例

❌ ボトルネックありの1修正作業(devcontainerなし)

ステップ 所要時間(目安)
コード修正 1分
イメージビルド 3分
Harborにpush 2分
app側でpull・再起動 2分
動作確認・ログチェック 1分
合計 9分〜10分

しかも動かなかった場合は、これを再度繰り返すことになる。