背景
背景として、社内の業務では主にRedmineを使って案件管理をしています。 今までは MyRedmineというSaaSサービスを使って管理していましたが、 業務チームでは結構Redmineをがっつり使い込んでいて、 効率化のためにいくつかプラグインを入れたり、業務効率をもっと計測したいという要望がありました。
MyRedmineでは入れられるプラグインが制限されており、自前で作ったプラグインを入れることができないので、 Redmineをオンプレで動かすように変更することにしました。
Redmineをわざわざ自前の環境に移行するなんて例はそんなにないかと思いますが、 対応した内容と所感を書いておこうと思います。
ざっくりの流れ
移行の流れ以下の図にざっくりと書きました。この図に沿って説明します。
初回データ移行
まず、既存環境のデータをそのまま新環境に移し替えます。MyRedmineを使用していた場合、MySQLのダンプと添付ファイルのバックアップを取得してもらえるので、 そちらを使用します。今回、移行前と新環境のバージョンは同じものを使用したので、MySQLのダンプをそのまま取り込めば一旦動かすことができました（機密の本番データがある場合は、取り込む前に削除します）
スキーマが同じなので、DBのダンプを移し替えるだけでほとんど移行できるのはとても簡単ですね。
既存の業務の継続
移行のための開発、データ整理作業を行っているあいだ、業務チームは継続して現行の環境を使用しました。移行開発中、以下の制約を付与しました
- カスタムフィールドの修正、更新禁止
- トラッカーの修正禁止
今回、プラグイン開発と同時にトラッカーやカスタムフィールドの見直しを同時に行ったため、修正内容が競合しないように、移行開発中は上記の制約を設けました。 ちなみに、ユーザ情報の追加、修正はOKとしました。
プラグインの開発、各種フィールドの整理
初回移行した構成をベースにプラグイン開発を行います。また、合わせてカスタムフィールドやトラッカーの見直しを行います。 移行した構成がベースになっているので、開発途中の状況を業務チームに確認してもらうこともできます。
データ移行(本番)
ここが移行のキモなのですが、新環境で開発したプラグインと整理したカスタムフィールド、トラッカーの内容を維持しつつ、業務データとユーザ情報のみ アップデートします。今回移行の対象としたテーブルを以下に示します。
| attachments | | custom_values | | email_addresses | | issue_relations | | issues | | journal_details | | journals | | member_roles | | members | | user_preferences | | users |
Redmineはデータの整合性はアプリケーションレベルでとっているので、DB自体に外部キー制約はありません。なのでテーブル移行の順序は気にせずデータを入れても大丈夫です。 （その分、動かすまでエラーかどうか分かりませんが・・・）
最後に、移行時間中に現行環境で更新があったものを差分適応して、業務チームに引き渡しました。
結果として、移行途中はいくつか混乱はありましたが、それほど大きな混乱なく切り替えができました。 こうやって触ってみると、Redmine本体がDBをまるっと移行するだけでそのまま使えて、テーブル設計もわかりやすく名前をみただけで大体の動きが予想でき、 必要なものだけ差し替えれっばうまく動くので、本当によく出来ていることが実感できます。
