Upgrade to Pro — share decks privately, control downloads, hide ads and more …

バージョンアップとサーバ移行、一緒にやって大丈夫?

120

 バージョンアップとサーバ移行、一緒にやって大丈夫?

Redmineのバージョンアップとサーバ移行、
一緒にやってしまいたくなりませんか?

一度で済ませたい、効率的に感じますよね。
でも本来この2つは別々に考えるべき作業です。

それでも同時に進めたい場合の注意点と、サポートを通じて見えてきたことを お話しします。

Avatar for naopontan@gmail.com

[email protected]

May 16, 2026

Transcript

  1. Redmineバージョンアップのおさらい 同一サーバ上でのバージョンアップは意外とシンプル 1. 要件確認 2. バックアップ 3. アップグレード 1. 新フォルダに新しいRedmineをダウンロード

    2. 必要なファイルを新しいRedmine上にコピー 3. bundle install 4. DBの更新(マイグレーション) 5. 後処理(キャッシュクリア、httpdの参照先フォルダ変更など) 要件確認大事。ここには OS や Ruby、その他ミドルウェアのバージョンアップは含まれてい ないのがポイント
  2. 要件確認  バージョン情報  OS / RDBMS / Ruby 

    プラグイン対応状況  /admin/info の出力をテキスト保存  ローカル変更  configuration.yml やテーマの配置先確認など  attachments_storage_path の実体パス / 別マウントの有無など  外部連携  メール / SCM連携 / 認証連携 / cron / API連携など
  3. プラグイン互換性チェック 旧 plugins/ をそのまま新サーバへコピーするのは絶対に避ける 棚卸し → 各プラグインの新 Redmine 対応版を調査して判定 ①

    対応版あり 新 Redmine 対応のタグ/ブランチを git clone または git checkout → 最も楽なケース ② 自社カスタム 新 Redmine の API に合わせてソースを修正(要工数見積) → 開発リソース確保が必須 ③ 廃止/非対応 機能削除をステークホルダと合意し、Redmine 標準機能での代替を検討 → ファイルを削除しただけでは DB テーブルが残る点に注意 プラグイン 旧バージョン 新対応版 判定 redmine_xxx 1.2.3 1.5.0 ①入れ替え redmine_yyy 0.9.0 なし ②コード調整 redmine_zzz 2.0.1 廃止 ③除外
  4. 新サーバ構築  OS / DB / Webサーバ / Appサーバ /

    Ruby  空DBで疎通確認(db:create → db:migrate → 起動 → db:drop) ここまでのゴール: 新サーバで「新 Redmine」が空 DB のまま動く 旧データはまだ載せない。プラグインも入れない。
  5. 移行(カットオーバー) 旧サーバ 新サーバ ▸ DB ダンプを取得 ▸ 添付ファイルを取得 (tar /

    rsync) ▸ リストア(DB / 添付ファイル) ▸ マイグレーション bundle exec rake db:migrate RAILS_ENV=production bundle exec rake redmine:plugins RAILS_ENV=production ▸ 動作確認 cron / チケット作成 / 添付ファイルアップロード / メール配信 など