Redmineサーバ統合事例

Redmineサーバ統合事例
(2014/11/30公開版、発表後一部補足訂正有)
2014/11/15
redmine.tokyo 第7回勉強会
@y503unavailable
2014/11/15 第7回redmine.tokyo 勉強会Redmineサーバ統合事例@y503unavailable 1

Agenda
• 自己紹介/謝辞/免責
• サーバ統合の背景
• Redmineサーバ統合作業手順
• Redmineの最適な運用規模？
• Notes→Redmine移行回顧録
2014/11/30公開版
・発表後一部内容訂正有､特にP41-43)
・最終頁に事後補足/関連情報追記

自己紹介
• 名前:y503unavailable
– http503 ,貧乏暇無し、首が回らんorz
– 503 Service Unavailable
– サービス利用不可。サービスが一時的に過負荷やメンテナンスで使用不可能である。
– 例として、アクセスが殺到して処理不能に陥った場合に返される。
• 製造業で製品開発部門のadminやってます。
– 部門サーバ、LAN、PC、全般の子守
– (全社単位の情報システムとは別、部門所属)

謝辞
• 謝辞
– 公開されている各種情報を参考にして、Redmineを自
力で部内基幹情報システムとして構築運用すること
ができました。
– Special Thans to
• Redmine.Tokyo
• R-labs
• Redmine.JP
• Redmine本家
• 各種サイト
• ということで、自分も少しは貢献させてください。

お断り
• 発表内容は、自分が管理する環境における実施事例です。
• あくまで参考程度にお願いします。
– 使用していない機能は検証していません。
– 各自環境への適合性は勿論保証できません。
– データ破損が後日発見されるかもしれません。
– 異常処理は何も行っていません.
– より効率的な方法もあるでしょう。
• 例
– チケット親子関係は利用せず
– カスタムフィールドはissuesのみ利用
– トラッカーは、ほぼ単一(統合元サーバ)
– MySQL依存
– Git未検証
• 説明対象：低レベルadminの作業参考(作業時の自分のレベル)

サーバ統合作業の背景
簡単で便利な物は流行る
•
– Redmineの立ち上げは極簡単
• Bitnami(Win/VM)簡単過ぎ
– 自PC上の野良Redmineも容易
– 低レベルadminでも立上げ可能(自分の事:-)
• 予算措置、購入申請不要
• Rubyインストール済ならアプリ監視不能
– 使い始めれば必須のツールになる。
• 誰でも自分の構築した環境は可愛いもの
• 結果的に長期間運用継続することになる。
– 利用を後押しする環境
• 有力なユーザコミュニテイ/サイト
• ベストセラー本、好意的な雑誌

サーバ統合作業の背景2
しかし
• 数年経てば業務を取り巻く環境も変わる。
– 組織統廃合/天の声/上司・担当者の異動・退職、、、
• Redmineサーバを統合できないのか？
• 一寸先は闇。その可能性は誰も否定できない。
• 備えあれば憂い無し

BEFORE

Redmineサーバ統合
• 作業経緯
• 作業方針/仕様
• 統合手法調査/準備
• 設計統合作業
• 利用者習熟、統合事前準備
• データ統合作業
– (統合-1)Versions,categories,変換して追加1
– (統合-2)Issues,members,cf,,,変換して追加2
– (統合-3)changesets, Journals,複雑なもの
– 添付ファイル、SVN
• 後始末/フォロー

試行PJ移行
結果良好
Go!
Lotus
Notes Redmine
(SV-A)
作業経緯
担当退職
管理項目
フロー独自調整
Redmine
(SV-B)
主な説明範囲
作業方針/仕様検討
統合手法調査,準備
設計統合データ統合
習熟
運用調整
統合運用
統合
事前準備
一元管理
計数管理
運用・設計
差異発生
計数管理問題
・VerUp
・機能追加
SV-AはRedmine移行試行、
SV-Bに全体集約する予定だった
・VerUp
・機能追加
統合完了し
実運用中
発表

対象環境
Redmine BitNami Windows利用(Redmine/SVN/Mysql)
統合作業前：Ver1.2/2.3
サーバ環境VMware ESX5.1上VM(Win2K3)
ID管理Redmine/SVNのIDは社内AD(LDAP)利用で統一
利用者開発部内社員+派遣/請負(構内作業) 100名超
主用途製品のS/W変更管理、関連情報の共有/WF
管理項目一般的な障害管理項目
(チケット駆動開発P39-表2.1 と同様)
SCM連携SVN連携
トラッカーほぼ単一(被統合サーバ側)
使用多SUBPJ,カスタムフィールド
使用少作業時間(社内別システム管理）、SUBTASK

(参考)S/W障害管理属性
管理項目は概ね下記と同様
(チケット駆動開発P39-表2.1 より引用)

作業方針
• 一品料理で構わない
– 過度の汎用化、ツール化はしない(工数削減、自分の能力:-)
– 使用していない機能は対応しない(同上)
– 例外処理は行わない.(同上、自慢することでは無い:-)
– 手法は適材適所で利用,シンプルに,全体として安全方向に
• 繰り返し作業は効率化
– 一回で作業が済む訳無い。(可能な範囲でBAT化)
– 編集手作業を減らす。(SQL dump/import直接利用)
– 手順書書くよりBAT化の方が楽(見通し効く範囲)
• 上手く行ったら発表しよう
– 前回の勉強会の時から目論んでましたｗ (モチベーション確保)

仕様/設計調整方針(1)
• 仕様調整
– 共通化推進（管理項目(CF)/ステータス/ワークフロー)
– 但し、PJの規模等で適切な管理項目/ステータスは異なる.
(現実的な対応-ユーザとの信頼関係維持は必要)
– 基本片寄せとするが、被統合サーバからの項目取込も有り
• 共通化困難な箇所の対応
– PJ単位選択のカスタムフィールド
– ステータス/ワークフロー複線化
（PJ内のメンバーRole指定で移行可否制御)
– ENUMは調整不能(優先度、作業分類)
– 類似業務のトラッカーは分割しない
(歯止めが効かなくなる事を危惧)

仕様/設計調整方針(2)
• チケット番号の重複対応
– 回避不能、統合前+20000とし、対比容易にした
– SVNとのリンク含め、番号以外は継続利用
• PJ識別子、SVNレポジトリパス変更
– 名前空間調整(製品名prefix-後はPJ内判断)
– 変更は統合作業時に実施
• 試行作業環境として手元のVM利用
• 試行環境コピー(VM)をユーザに公開しフィー
ドバック/確認実施

仕様打合せ結果
• SV-A(被統合サーバ)利用者との打ち合わせ結果(2014/3)
• 必須要件
– 従来同様に利用できること
– 既存チケット/入力内容が継続利用可能
– チケット/SVN間のリンク保持
• 変更合意事項
– 管理項目/WFは,SV-B(統合先サーバ)に原則統合(片寄せ)
– サーバIP/URL自体の変更
– チケットNoは、判り易く平行移動(1->20001,3000->23000)
– PJ/REPOSの識別子は、一意性確保のため変更
(製品名略称-種別-名前)
– その他、協議して調整（内容によってはSV-Aからの取込有)
– 作業は２フェーズ(設計統合/サーバ統合)、フェーズ１-GW連休

統合手法調査/準備
• 作業経緯

DB統合作業手法検討
• SQLとRESTのハイブリッドで実施した
issues一括追加,projets登録のみREST,他はSQLで処理
• RESTのみで実行できなかった理由
– カスタムフィールドが設定できない(2.4からGETのみ可能)
http://www.redmine.org/projects/redmine/wiki/Rest_CustomFields
– 標準外のカテゴリ-PJ階層構造共有パッチを利用。REST非対応
http://www.redmine.org/issues/11898 #5358
http://www.redmine.org/projects/redmine/wiki/Rest_IssueCategories
＃カテゴリはバージョンと同様にPJ間共有にして欲しい。なぜ年単位で非対応？
– 変更箇所多数
• issue,projects他、ID変更箇所が多岐にわたる。
• SQLでUpdateした方が見通しが良かったし、どう見ても早い。
• SQLのみで実行できなかった理由
– issuesのlft,rgtを処理する必要があり諦めた。

テーブル調査
• (参考)Redmine自体のDB設計関連考察
– http://forza.cocolog-nifty.com/blog/2012/09/redmineer-ff0a.html
• 被統合サーバの使用テーブル,使用ID,レコード数一覧表作成
– 作業必要なテーブルの確認と、依存関係を確認する為
– pluginを含めて確認必要。
• 調査方法(mysqlの場合)
– show tables; テーブル一覧
– desc 各table名; テーブル設計情報
– select count(*) from 各table名; レコード数
– show index from 各table名;インデックス情報
• issue_id, project_id, user_id は利用多い(→事前準備)
• それ以外のintのカラムも内容確認
• 移行作業対象外の判断基準
– レコード数=0のテーブル
– 現在使っていないプラグインのデータなど(更新日時)
– ０で無くとも少ないものは要否判断/手作業移行有

DB変換概要
• Users,Projects
– Redmineシステム単位定義であり、大半のテーブルで参照
– 統合前に移行先に追加登録、変換テーブルを事前作成し、各テーブル
を単純に変換
• Issue_Categories,Versions
– Issuesなどで参照
– 単一テーブル上、所属PJ含み定義
– 統合作業最初に登録し、変換テーブル作成
• Issues,,その他
変換実施
支障: Duplicate entry
• Changesets*,Journals*,Wiki*
多段のテーブル間参照関係、ちょっと複雑な作業になる。
• Settings 標準/プラグインの設定、YAML記録
• 詳細はRedmine自体のDB設計参照
• Pluginも要注意

ID変換表作成(設計統合)
• 設計統合に伴うID変換表を事前作成
• 設計統合作業の最後に、
変換テーブルまたはupdate文羅列で変換
– Status_id
SV-A
SV-B
(被統合)
(統合先)
– Tracker_id
– Role_id
– Custom_field_id
– CF内データ変換(管理用記号の置換など)
状態
3 4 受付待
4 6 分析中
5 9 処置完了

settingsテーブル
• 標準/プラグインの定義テーブル
• 定義内容はYAMLで記録
• 各種定義内容の調整、差異比較確認必要
– 今回は何も作業しなかったが、結果的に問題は起きてない。
– (顕在化/認識していないだけかもしれない)
– 移行作業時は気付かず、原稿作成中に発覚した。

Redmineサーバ統合
• 作業経緯

設計統合作業
一言で言うと
統合先サーバのコピーに、
被統合サーバのデータを入れて差し替える。
データは被統合サーバ、動作/内部設計は統合先サーバ
統合先サーバ由来:
OS/Redmine/Plugin/Redmine上設計情報(内部ID一致)
(CF,WF,Status,Tracker,Roles,Plugin)
被統合サーバ由来:
チケットデータ、ユーザ、プロジェクト、添付ファイル、SVN
そのための作業内容
環境準備
Redmine本体/PluginのVer一本化
WF/CF/ステータス/ロール調整

Redmine設計統合作業-1
(環境準備)
• SV-A(被統合),SV-B(統合先)のフルバックアップ(VM停止)
• SV-BのVMコピー(PC名+sysprep)作成
• DISK容量確認調整(DB,SVN,添付ファイル,ワーク領域)
(統合後の容量増(特にSVN+添付)、途中作業ワーク)
• SV-AのDBダンプ
mysqldump -u root -pDBパスワードbitnami_redmine
> redmine_sv_a.sql
• SV-Bの一部テーブルをdump (下記、繰り返し)
mysqldump -u root -pDBパスワードbitnami_redmine workflows
> workflows_sv_b.sql
( workflows,roles,custom_fields_(projects以外), trackers, issue_statuses)

Redmine設計統合作業ｰ２
(Redmine/PluginのVer一本化)
– (SV-BコピーVM)
SV-Aのsqlをインポート,migrate(標準/Plugin)
– mysql -u root -pDBパスワードbitnami_redmine < redmine_sv_a.sql
– rake db:migrate RAILS_ENV="production"
– rake db:migrate:upgrade_plugin_migrations RAILS_ENV=production
– Vup時に多少の調整は発生(対応略)
• Redmine起動確認
• 添付ファイル/SVNを元のSV-Aからコピー(入替)
• httpd.conf調整(svn,apacheのverup対応含)
– 全体起動確認(Redmine/Plugin/SVN)
(詳細な動作確認は、データ変換後に実施)

Redmine設計統合作業ｰ３
(WF/CF/ステータス/ロール調整)
– Redmine自体のサービスを一旦停止(mysqlは動作)
– 定義テーブル取込後、データ変換実施
– 内部ID変換表は事前設計
作業種別対象テーブル
sv-bの各定義
テーブル取込
workflows,roles, trackers,issue_statuses,
custom_fields_(projects以外)
status_id変換issues
role_id変換member_roles
tracker_id Issues,projects_trackers
cf_id変換custom_values,custom_fields_trackers,custom_fields_projects
cf内データ変換例、管理用記号の変換"A"→"C"
(ver,usersなどの変換は実施せず)
Pluginも注意(例:issue_extensionsなど)

設計統合時WF、CF、ステータス、
権限調整作業例
• WF、CF、ステータス、権限調整
– Workflows(roles,trackers,issue_statuses,,同様)
• mysql>drop table workflows;
• mysql -u root -pDBパスワードbitnami_redmine < workflows_sv_b.sql
– Issues
• 単純に変換してupdate(status_id,tracker_id)
– Cf_id変換
• （例:28→8,8→3に変換の場合,途中重複回避リスクのため未使用番号に一旦変換)
• mysql>update custom_values set custom_field_id=108 where custom_field_id=28;
• mysql>update custom_values set custom_field_id=103 where custom_field_id=8;
• mysql>update custom_values set custom_field_id=custom_field_id -100;
– CF内データ
• 変換項目のupdate

設計統合完了時のOUTPUT
• 統合先(SV-B)と一致
– DB設計と内部ID(CF,WF,Status,Tracker,Roles,Plugin)
– Redmine/Pluginのコード、OS
– 基本片寄せ統合、一部項目は取込共通化
• 被統合(SV-A)の状態を保持(変換済項目除く)
– Issues,Users,Projects,Repositories,Versions,
issueCategories,members,,,

利用者習熟、統合作業準備
• 作業経緯

利用者習熟、統合事前準備
一言で言うと
usersとprojectsは多くのテーブルが参照する。
統合先に事前追加し変換表を作成→統合作業の単純化
所要時間と作業リスク削減
段階的移行作業により、移行調整中の影響範囲を限定
(緊急対応時に影響受けるのは被統合サーバ利用者のみ)
統合作業準備/試行/デモの時間稼ぎ
そのための作業内容
設計統合状態で1ヶ月仮運用(被統合サーバ)
被統合サーバのusers/projectsを統合先に先行追加/変換表作成
統合作業試行/作業手順調整数回(VM)

設計統合～統合作業前の作業
(利用者習熟/運用調整)
• 最終的なサーバ統合前に、
設計統合状態で1か月仮運用した。
• 仮運用の目的
– サーバAユーザの移行先環境への習熟(項目､WF)
– 問題点洗い出し/対応
– 調整要/トラブル発生時の影響範囲限定(リスク低減)
• サーバA/B間の設計同一性は堅持
– 統合までの間、CF/WF/Status/Role/Pluginの
追加変更は、サーバA/B両方に実施した。
• 統合前準備作業(次頁)を並行実施

統合前事前準備作業(1)
• 統合前準備作業(users,projects事前登録)
– SV-Aのみ登録のユーザIDをSV-Bに事前登録
(Lockout,グループ定義含,REST)
– SV-A上のPJをSV-Bに事前登録(終了PJ含,REST)
– PJの階層構造を手動設定(REST不可)
– SV-A→SV-Bの変換テーブル作成(ユーザID,PJ)
– 出力:SV-Aのusers,projectsがBに登録済,
SV-BにID変換テーブル有

統合前事前準備作業(2)
• 統合前準備作業(統合作業準備)
– 各テーブルの依存関係/登録数を調査
– 統合後サーバのサイジング
• DISK:添付ファイル,SVN,DB,作業ワーク
• MEMORY:DB割当メモリの検討(追加record数,,)
• 対処不足→パフォーマンス問題、DISKFULL発生可能性
– 統合作業前にVM上で試行/リハーサル実施
– 統合作業直前に、users,projectsが最新取込済
か確認

データ統合作業(1)
• 作業経緯

データ統合作業
一言？で言うと
設計統合済、users/projects追加済(の前提で)
被統合サーバデータを変換し、統合先に追加する。
(issues,custom_values,versions,issue_categories,members,journals一族,changesets一族,,,)
,,,だけで終わる訳が無く、色々と楽しませて頂きましたｗ
・REST,SQL、片方だけでは移行できない、親子関係注意
・テーブルIDの階層的参照関係(統合前後の変換処理要)
・カスタムフィールドの数値文字列対応
・CV/Journalの各種データタイプ対応
・updateに数分掛かる(journal_details)
・refs #番号の変換(完全には出来てない)
・UNIQUE KEY使用箇所ででinsert失敗
・SVN/添付ファイル→コピーし調整するだけ
でも、なんとかなって運用できていると言う事で、終わり良ければry)

データ統合作業概要
• 統合作業概要
– 環境準備
• SV-A,Ｂ共に保守停止(一日)
• VMフルバックアップ
• 統合先サーバのサイジング、users/projects最新確認
– 統合対象データの転送
• 統合対象テーブルの作業用ダンプ
• 添付ファイル、SVNリポジトリ、その他
– チケット一括追加(REST)
– ID変換が必要なテーブルは、SV-A時代のID保持
用カラムを一時的に追加
– 移動したテーブルのデータ変換、追加実施(SQL)

チケット統合
• 前提：統合先15000件,被統合:3000件を、20001-
23000に移行
• Issuesのlft,rgt関連で、DB直接INSERTは断念
• 作業概要
– RESTで大量のダミーチケット追加し番号取得
(15000-23000までの8000件)
– Issuesはデータupdate(チケット番号+20000)
– Versions,categories,userid
変換テーブル噛ませてupdate
• 注意事項
– 数千件のREST追加→所要時間注意(数十分)
– (前日夜間実行もアリ)

データ変換(ID参照関係無)
• 単純なもの(versions,categories,,)
– SV-B上で、SV-Aから移動したテーブルのデー
タ変換
– project_id,user_id,issue_idを変換
– SV-B側テーブルにINSERTする

データ変換(ID参照関係有)
• IDを階層的に参照しているもの
– versions,journals,changesets,,,,,
• 対応手法
– SV-B上で、SV-Aから移動したテーブルのデータ変換
– project_id,user_id,issue_idを変換
– SV-A時代の旧ID保持用カラムを、当該テーブル上に一時
追加（SV-A,SV-B分テーブル共に)
– SV-AのデータをSV-BにINSERT
– SV-B上で割り当てたIDをSV-Aからのテーブルに書き戻し、
次のデータを変換
– (元データは全てSV-B上にコピー済なので、SV-B上で作業
完結)
– 動作確認後、追加したカラムをdropする。

insert時の重複キーエラー発生
(発表後訂正)
– 発表時内容ではデータロス発生の可能性があるため、
下記訂正します。
– 変更内容
• 対策(1)のreplace into ではなく、対策(2)のdrop index で
対応してください。
• 作業手順として、統合前後のレコード数を確認してください。
– 理由
• >replace intoでは、キーが既に存在する場合、元のデータが
DELETEしてからINSERTされる。
• キーが誤って重複判定されていた場合、誤ってDELETEされ、
意図せぬデータロスを招く可能性がある。

insert時の重複キーエラー発生
• 対象projects_trackers (custom_fields_projectsも同様)
• 現象
– mysql> insert into projects_trackers(project_id,tracker_id)
– -> select project_id,tracker_id from projects_trackers_sv_a;
– ERROR 1062 (23000): Duplicate entry '214-5' for key
'projects_trackers_unique'
• 今回追加しようとしたデータに上記データは存在しない(数百レコード)何故？
• SQL定義内容
– UNIQUE KEY `projects_trackers_unique` (`project_id`,`tracker_id`),
• 対策
– insert into ではなく、replace into を利用
– (replace intoでは、キーが既に存在する場合、そのデータをDELETEして
からINSERTする。)
– replace into projects_trackers(project_id,tracker_id)
• select project_id,tracker_id from projects_trackers_sv_a;
対策次頁参照

insertで重複キーエラー発生２
• 対象members
• 現象
– membersテーブルのinsert時に、重複キーエラー発生
– insert into
members(user_id,project_id,created_on,mail_notification,id_sv_a)
– select user_id,project_id,created_on,mail_notification,id_sv_a from
members_sv_a;
• SQL定義内容
– UNIQUE KEY `index_members_on_user_id_and_project_id`
(`user_id`,`project_id`),
• 対策
– update/insert作業前に、UNIQUE KEYの制約を外す。
– alter table members drop index
index_members_on_user_id_and_project_id;
– 統合作業後は再設定してください。

insert重複キーエラーの発生原因？
• (注)これは私の想像です。識者の指摘希望
• MySQL内でUNIQUE KEYの判断に用いる
HASHが、テーブル間でCollisionを起こし易
い？
• レコード数が数百件程度の異なる値で発生
• Collision-衝突-計算結果が同じ-重複とみなす
• 類似内容
– avoiding unique key collisions across tables
– http://dba.stackexchange.com/questions/53196/avoiding-unique-
key-collisions-across-tables

updateに長時間掛かる
(journal_details)
• 問題点
– journal_detailsのデータ変換(数値はcast)に、分単位の時間が掛かる
• 原因
– 新旧値が数値文字列で保存されているため、
– castによる変換処理時間増加・インデックス利用が行えず遅くなる。
• 対策
– int変換済カラムを一時追加する。indexを付ける(old_valueも同様)
– alter table journal_details_sv_a add value_int int;
– update journal_details_sv_a set value_int=cast(value as signed);
– alter table journal_details_sv_a add index(value_int);
– alter table journal_details_sv_a add index(prop_key,value_int);
– 変換作業（fixed_version_id）
– update journal_details_test, translate_versions set
journal_details_test.old_value=translate_versions.id_sv_b
where journal_details_test.old_value_int=translate_versions.id_sv_b
and journal_details_sv_a.prop_key='fixed_version_id';
– 手元のメモでは(3分→1秒)

統合作業例示
• issue_categories
• issues
• custom_vaules
• changeset(関連)/repositories
• journals(関連)
• 他テーブルも、概ね同様に処理します。

環境準備
– 環境準備
• SV-A,Ｂ共に保守停止(一日)
• VMフルバックアップ
• 統合先サーバの調整
– （事前検討に基づき、VMのDISK容量/メモリ調整)

テーブル統合作業概要
(issue_categories)
• (事前準備)
– projects, usersの事前追加登録(最終確認)
– 変換テーブル(translate_users,projects)
• (被統合サーバ:SV_A)
– 作業用テーブルにコピー,SQLダンプ
• (統合先サーバ:SV_B)
– 被統合サーバでダンプした作業用テーブルのSQLをインポート
– 被統合サーバでのID保持用カラム追加(id_sv_a), # 作業用＋統合先の両方
– project_id,assigned_to_id 変換
– 統合先テーブルにinsertし追加
– 統合先テーブルから、issue_categoriesのID変換テーブルを出力
(issuesの統合作業で利用するため、その前に準備必要)
– 統合作業完了後、旧サーバでのID保持用カラムを削除

テーブル統合作業例
(issue_categories) 対象テーブル
• mysql> desc issue_categories;
+----------------+--------------+------+-----+---------+---------+
| Field | Type | Null | Key | Default | Extra |
+----------------+--------------+------+-----+---------+---------+
| id | int(11) | NO | PRI | NULL | auto_inc|
| project_id | int(11) | NO | MUL | 0 | |
| name | varchar(30) | NO | | | |
| assigned_to_id | int(11) | YES | MUL | NULL | |
| sharing(注) | varchar(255) | NO | MUL | none |#11898 |
+----------------+--------------+------+-----+---------+---------+
5 rows in set (0.00 sec)
• 変換内容
変換作業
緑：設計統合時変換
青：サーバ統合時変換
黒：通常変換無
– project_id,assigned_to_id →事前作成済の変換テーブル利用
– 統合後のidは、統合先サーバに追加して確定する。
新旧id変換テーブル作成要
(issues,custom_values・journal_details(categories)の変換で利用)
• 注: カテゴリのPJ継承パッチ(本家#11898)によりsharing追加済
(今回は両サーバとも追加済で,統合作業への影響無)

issue_categories(1)
• (被統合サーバ:SV-A)
• ＃別名で作業用テーブルを作成しSQLダンプ
– mysql> create table issue_categories_sv_a like issue_categories;
– mysql> insert into issue_categories_sv_a select * from
issue_categories;
– mysqldump -u root -pDBパスワードbitnami_redmine
issue_categories_sv_a > issue_categories_sv_a.sql
SV-A(被統合サーバ)からのダンプ、
SV-B(統合先サーバ)へのインポート、
次ページの変換テーブル作成は、
各テーブルについて実施必要。(Sample兼用)
実際には最初に一括処理する。(依存関係注意)

issue_categories(2)
• (統合先サーバ:SV-B)
• ＃ SV-Aで出力したSQLダンプ(作業用テーブル)をインポート
– mysql -u root -pDBパスワードbitnami_redmine < issue_categories_sv_a.sql
• ＃ id_sv_aカラムを追加し、SV-A時点のIDを設定
– mysql > alter table issue_categories add id_sv_a int;
– mysql > alter table issue_categories_sv_a add id_sv_a int;
– mysql > update issue_categories_sv_a set id_sv_a=id;
• ＃ project_id,assigned_to_id を、SV-A → SV-B上のIDに変換
– mysql > update issue_categories_sv_a,translate_pj
set issue_categories_sv_a.project_id=translate_pj.sv_b_id
where issue_categories_sv_a.project_id=translate_pj.sv_a_id;
– mysql > update issue_categories_sv_a,translate_users
set issue_categories_sv_a.author_id=translate_users.id_sv_b
where issue_categories_sv_a.author_id=translate_users.id_sv_a;

issue_categories(3)
• (統合先サーバ:SV-B)
• ＃統合先テーブルに追加
– mysql> insert into issue_categories select * from
issue_categories_sv_a;
• ＃変換テーブルを出力
• ＃ translate_issue_categories テーブル、id 統合先(sv_b)、id_sv_a 被統合(sv_a)
• ＃ issuesの統合前に、このテーブルを利用して変換する。
– mysql> create table translate_issue_categories (id_sv_a int,id_sv_b int);
– mysql> insert into translate_issue_categories select id_sv_a,id
from issue_categories where id_sv_a >0;
• ＃統合作業完了後、不要カラム、テーブルを削除
– mysql> drop table issue_categories_sv_a;
– mysql> alter table issue_categories drop id_sv_a;
Issuesの統合時に、この変換テーブルを利用する。

• 作業経緯

テーブル統合作業概要
(issues)
• (事前準備:SV-B)
– SV-A分の事前追加登録/変換テーブル(projects, users,versions,issue_categories)
• (統合先サーバ:SV_B 作業用テーブルのデータ変換)
– 被統合サーバでダンプした作業用テーブルのSQLをインポート
– 統合先ID割当用カラム追加(id_sv_b),新id（旧id+20000)を設定
– 統合先サーバ用にデータ変換
(project_id, author_id, assigned_to_id, fixed_version, issue_categories)
• (統合先サーバ:SV_B テーブル更新)
– RESTでチケット追加(移行分＋途中埋め)
– 統合先issuesテーブルを被統合サーバの変換データで更新
(id,parent_id,root_id,lft,rgt以外の各カラム)

issues テーブル
• mysql> desc issues;
– +------------------+--------------+------+-----+---------+----------------+
– | Field | Type | Null | Key | Default | Extra |
– +------------------+--------------+------+-----+---------+----------------+
– | id | int(11) | NO | PRI | NULL |auto_increment |
– | tracker_id | int(11) | NO | MUL | NULL |tracker_i(設計) |
– | project_id | int(11) | NO | MUL | NULL |project_id |
– | subject | varchar(255) | NO | | | |
– | description | text | YES | | NULL | |
– | due_date | date | YES | | NULL | |
– | category_id | int(11) | YES | MUL | NULL |issue_categories|
– | status_id | int(11) | NO | MUL | NULL |status_id(設計) |
– | assigned_to_id | int(11) | YES | MUL | NULL |user_id |
– | priority_id | int(11) | NO | MUL | NULL | |
– | fixed_version_id | int(11) | YES | MUL | NULL |version_id |
– | author_id | int(11) | NO | MUL | NULL |user_id |
– | lock_version | int(11) | NO | | 0 | |
– | created_on | datetime | YES | MUL | NULL | |
– | updated_on | datetime | YES | | NULL | |
– | start_date | date | YES | | NULL | |
– | done_ratio | int(11) | NO | | 0 | |
– | estimated_hours | float | YES | | NULL | |
– | parent_id | int(11) | YES | | NULL |危険|
– | root_id | int(11) | YES | MUL | NULL |危険|
– | lft | int(11) | YES | | NULL |対象外|
– | rgt | int(11) | YES | | NULL |対象外|
– | is_private | tinyint(1) | NO | | 0 | |
– | closed_on | datetime | YES | | NULL | |
– +------------------+--------------+------+-----+---------+----------------+
変換作業
親子関係部分は
危険回避の為
RESTで別途設定
(今回利用せず)

(issues)
• RESTでチケット追加
• 今回はSQLからupdateしたが、RESTでも設定可能
• チケット親子関係は、登録後にRESTで設定する。
• (REST設定の参考リンク)
• チケット親子関係使用時の注意
– 親子関係は、SQLではなくRESTでparent_issue_idを設定すること。
– 異常発生すると大変
– (参考)チケット親子関係トラブル-修復事例
– http://dqn.sakusakutto.jp/2012/04/redmine.html

カスタムフィールド内容の変換
• 定義:custom_fields(統合済)
• 値:custom_values(データ統合)
• カスタムフィールドは、数値(id含)も数値文
字列のテキストデータで表現している。
• 種別:users,versions テーブル参照し変換
• 管理区分の記号など、業務ロジックを反映し
変換
• 調整必要(DB差異有？)
• 作業例示

(custom_values)対象テーブル
• mysql> desc custom_values;
変換作業
– +-----------------+-------------+------+-----+---------+----------|
| Field | Type | Null | Key | Default | Extra |
+-----------------+-------------+------+-----+---------+----------+
| id | int(11) | NO | PRI | NULL |auto_inc |
| customized_type | varchar(30) | NO | MUL | |データ形式|
| customized_id | int(11) | NO | MUL | 0 |issue_id |
| custom_field_id | int(11) | NO | MUL | 0 | |
| value | text | YES | | NULL |内容依存|
+-----------------+-------------+------+-----+---------+----------+
• valueはtextとして保存される。customized_typeにより処理は異なる。
データ形式格納形態変換
テキスト/長いテキス
ト/リストから選択
テキストのまま通常不要
ユーザー/
バージョン
user_id,version_idの
数値文字列
Cast でsigned指
定し変換
数値数値文字列通常不要
日付日付文字列通常不要
真偽値0,1,NULL 通常不要

(custom_values,1)
• (統合先サーバ:SV_B データ変換)
– 旧サーバでダンプしたSQLをインポート
– チケットID(customized_id)に新id（旧id+20000)を設定
mysql> update custom_values_sv_a set
customized_id=customized_id+20000 where customized_type='Issue';
• ＃カスタムフィールドのデータを統合先サーバ用に変換する。
– ＃カスタムフィールドID=12,15について、ユーザIDを変換する場合(例)
– Mysql>update custom_values_sv_a,translate_user
set custom_values_sv_a.value=translate_user.id_sv_b
where cast(custom_values_sv_a.value as signed)=tｒanslate_user.id_sv_a
and custom_values_sv_a.custom_field_id in(12,15);

(custom_values,2)
• ＃RESTチケット追加時のcustom_valuesを削除
– チケットID/カスタムフィールドIDが同一のcustom_valuesレコー
ドが複数存在する場合、後から追加したデータが表示されない。
– 最初にRESTでticketを追加した時点で、そのチケットの
custom_valuesが作成されている。
→CV追加後、カスタムフィールドが全て空白で表示される
– 対策：変換データのInsert前に、
置換範囲のcustom_valuesを削除する。
– mysql> delete from custom_values where customized_id > 20000
and customized_id< 23001;
• ＃変換した作業用テーブルをinsertする。
– Mysql> insert into
custom_values(customized_type,customized_id,custom_field_id,value)
select customized_type,customized_id,custom_field_id,value
from custom_values_sv_a;

• 作業経緯

時間確認
• ここで20分経過していたら
• 残りの変換作業は飛ばします。
• 後日資料参照
• (22分経過していたので飛ばしました)

Changeset/repositories(SCM連携)
テーブル統合概要
• 内容
• 内訳
テーブル名概要
changes コミット内の各変更(ファイル単位)
changesets 1回のコミット単位
changesets_issue
コミット-チケット関連付け(n..n)
s
repositories レポジトリ定義(Project単位指定)
– repositoriesは、changes内で参照されている。
– changesは、changeset_idをキーとしてchangesetsに結合してい
る。
– changesetsとissuesは、changesets_issuesにより、n..mで関連付
けられている。

changeset/repositories
統合作業概要(1)
• (事前準備、旧サーバからの作業テーブルSQLダンプ/インポート）
• 旧ID保持用カラム追加
(repositories,changesets 統合元、統合先共に追加)
• ＃ repositories(統合先repositories_sv_a)
– 変更先のurl,root_urlを設定
– project_idを変換
– 統合先repositoriesに追加
– 統合前後のID変換テーブル作成
• ＃ changesets(統合先changesets_sv_a) コミット時IDの処理は後記
– repository_idを変換
– 統合先changesetsに追加

• ＃ changes(統合先changes_sv_a)
– changeset_idを変換
– 統合先changesに追加
• ＃ changesets_issues統合先
changes_issues_sv_a)
– changeset_idとissue_idを変換
– 統合先に追加
– 統合先サーバのjournal_detailsにinsertし追加

• ＃ changesets追加変換分(コミット時refs #ID)
– Changesetsのcommentsカラムには、refs #チケット
IDとコメントが記録されており、変換作業が望まれ
る。(変更しないと後から誤認可能性有)
– mysql上で、replaceとregexpを利用して変換した。
– 統合するチケット番号範囲(今回は1-3000)を考慮し、
#1[0-9]{3},#2[0-9]{3},#1[0-9]{2},#2[0-9]{2},順番に変換
した。
– UPDATE changesets SET comments =
REPLACE(comments, '#1', '#21') where (comments
regexp "refs #1[0-9]{3}" )and not(comments regexp
"refs #1[0-9]{2}"); #1001->#21001の例
– (完全な変換は出来ていないので識者補足希望)

Journalsテーブル統合概要
• 内容
テーブル名概要
journals 一回のチケット変更毎情報
journal_details 一回のチケット変更中の、各変更項目
• 内訳(journal_details)
(変更者、日時、、)
(標準のチケット属性、カスタムフィールド、
添付ファイル、チケット関連付け)
– 変更内容の新旧の変更内容がテキストで保存されている。(value,old_value)
– 標準/カスタムフィールドのID変更分は、intではなく数値文字列として保存。
(custom_valueと同様)
– 数値変換した上で、内容に応じ変換処理を実行する必要がある。
– 添付ファイルの場合、prop_key には、attachmentsのidが設定されている。
– journalは、journalized_id(issue_id)をキーとしてissuesに結合している。
– journal_detailsは、journal_idをキーとして結合している。

Journalsテーブル統合作業概要
• (事前準備、旧サーバからの作業テーブルSQLダンプ/インポート）
• Journals(統合先journals_sv_a)
– journalized_id チケット番号変換、user_id 変換
– 統合先テーブルにinsertし、新旧journal_idの変換テーブル作成
• journal_details (統合先journal_details_sv_a)
– 新旧journal_idの変換
– 標準・カスタムフィールド:データ属性に応じ、old_value,value
変更
– チケット関連付け:相手のチケット番号文字列変更
– 添付ファイル:prop_keyに、attachmentsのid再設定(新旧id変換)
– 統合先テーブルにinsertする。（このid利用は無い)

Journalsテーブル
• mysql> desc journals;
– +------------------+-------------+------+-----+---------+---------+
– +------------------+-------------+------+-----+---------+---------+
– | id | int(11) | NO | PRI | NULL |auto_inc |
– | journalized_id | int(11) | NO | MUL | 0 |issue_id |
– | journalized_type | varchar(30) | NO | | |'Issue'他|
– | user_id | int(11) | NO | MUL | 0 |変換|
– | notes | text | YES | | NULL | |
– | created_on | datetime | NO | MUL | NULL | |
– | private_notes | tinyint(1) | NO | | 0 | |
– +------------------+-------------+------+-----+---------+---------+
– 7 rows in set (0.00 sec)
チケット上のrefs #1234などのコメントはnotesカラムに入る。変換必要
変換作業
黒：通常変換無-黒

journal_detailsテーブル
• mysql> desc journal_details;
– +------------+-------------+------+-----+---------+----------------+
– +------------+-------------+------+-----+---------+----------------+
– | id | int(11) | NO | PRI | NULL | auto_increment |
– | journal_id | int(11) | NO | MUL | 0 |新旧変換|
– | property | varchar(30) | NO | | |種別|
– | prop_key | varchar(30) | NO | | |項目/cf_id |
– | old_value | text | YES | | NULL |数値文字列変換|
– | value | text | YES | | NULL |数値文字列変換|
– +------------+-------------+------+-----+---------+----------------+
– 6 rows in set (0.00 sec)
変換作業
黒：通常変換無-黒

Journal_details属性3(cf)
• mysql> select prop_key from journal_details
• where property=‘cf' group by prop_key;
– +----------+
– | prop_key |prop_keyは、カスタムフィールド番号
– +----------+
– | 1 |変換作業はフィールド属性に依存
– | 10 |
– | 11 |
– ...

Journal_details属性4
– property
– | attachment | attachmentsのid(数値文字列)
– | relation | 関連付け相手チケットのid(数値文字列)
– old_value,value 新旧数値文字列を変換

Journalsのコミット時チケット番号
変換
• 無理やりSQLで変換した。
• 完全な対応はできていない。
• # Changeset/repoの３と同じ

データ統合作業(添付/SVN)
• 作業経緯

添付ファイル
• 添付ファイル自体は単純にファイルコピー
– Redmine内に保管されているファイル名は、
ファイルのアップロード日時分秒_ファイル名
– 通常の利用(人の操作で添付)で、
サーバ間重複することは、事実上考えられない。
• 変換処理
– attachmentsテーブル
チケット番号/ユーザID部分を一括変換
– journalsでattachmentsのid利用
→変換テーブル作成要

SVNレポジトリ
• (前提)
– SVN-Apache経由で公開,ADのIDでアクセス制限
– レポジトリ自体の統合は行わない(必要時別途作業)
– 統合後もレポジトリ名が一意になるよう事前調整
• (作業)
– レポジトリ自体は単純コピー
– Httpd.confは追加修正(レポジトリ名、保管フォルダ変更)
– 各レポジトリのaccess.txtは変更無
– Journals上のrefs#チケット番号はSQLで変更した。
(changesets_issuesとは別に)
– SVN log上のチケット番号は変換しなかった。
(チケット番号の対比が明確で容易のため省略)

利用者習熟、統合作業準備
• 作業経緯

後始末、フォロー
• 制限/今回実施せず
– カスタムクエリ定義は手動設定変更で対処した。
Cf-番号で変換できそうだが、定義数も少なかったため。
– グローバルのカスタムクエリは残した。
SV-Aでは顧客毎にPJ作成しており、グローバルにSV-Bと同一名称のカスタムクエリを
設定していた。顧客数分設定は無理なので、(SV-A移行分)と名前付けて残した。
• 運用変更
– SV-Aの移行時の運用担当者にAdmin権限付けた。
– (コンソールは渡してない）
• 移行作業後
– 移行作業自体に起因するトラブルはなく運用できている。
– 当初目的の計数管理の一元化は実施できた。
• 作業終わって、Shinagawa.redmineに発表打診

変換作業時の留意点(復習)
• 特に注意すべき点/面倒な点の復習
– 複合Indexを一旦削除必要な場合があった
– refs #IDの変換
– RESTチケット追加後、cv追加前にREST追加時のcvを
削除必要
• その他。。
– チケット親子関係はRESTで別途設定
– プロジェクトの親子関係は手動設定(REST無)
– issues以外のカスタムフィールドがある場合は、変換
処理を追加必要(custom_values,journal_details)
– REST大量チケット追加時の所要時間(事前確認)

AFTER

Redmineの適切な運用規模？
ユーザ数10,30(個別)/100,300(部門)/1000,3000(全体)
PJ/Gr/事業部/全社、ニーズ差異
立場、運用姿勢によっても異なる？対立構造
本来の目的現場視点の品質/生産性向上管理する事が目的？
Redmine 個別管理(PJ/Gr) 部門管理全体統合
機能変更対応影響範囲少/
迅速な対応
(要管理者)
影響範囲中/
迅速な対応
影響範囲拡大、
全体の変更困難/遅
い
管理面バラバラシステム
管理者有無
管理レベル差異
管理者有全体最適？？
一元管理
管理者有
ユーザ側意識小集団活動
自分の物にする。
愛着、
主体性持って管理
顔が見える範囲
顔が見えている
範囲(のつもり)
だが、
人/場所差異？
(部内関係、対人
関係,,,)
押付け、
やらされ感
一体感無
ニーズ合わず
→結果的に二重管理

Notes→Redmine移行時(回顧録)
• 作業制約
– NotesR6からRedmine1.3へ移行したため、使える道具が限られていた。
– NotesR6からRESTによる登録は無理(HTTP-POST無)
– 自分のスキル/利用可能な機能により一品料理実施
• PJ階層構造化
– Notes上では製品単位にDBを作成していた。
– →派生製品の管理にRedmineのPJ階層構造を利用することとした(機能定義集約含)
• CSVインポート作業時制約
– CSVインポート時、CF上の未登録データはRedmine上に取り込まれなかった。
– (Author,Assignee,Versionは自動登録されたが、それ以外の担当者情報、affectedVersionは、最初に
出現した場合に自動登録されなかったため、後からSQL出力して対応した(と記憶している)
– (最新プラグインの動作は未確認)
• Notes参照利用の継続
– Notesは参照用に当面残すこととしたので、相互の参照関係が必要になった。
• 制限事項
– NotesのEmbeddedは取り込めていない。

Notes→Redmine移行時作業例
サーバ事前設定対象作業内容(基本的にadmin作業)
設計Redmine 移行フィールド、Role、WF設計
ID登録Redmine Notes上IDをRedmine上に登録
Notes NotesID/RedmineID変換表作成
NotesDB単位作業内容対象作業内容
集約/要否確認Notes 移行単位、階層構造(派生製品)、ユーザ情報、確認依頼→利用者
機能,version集約Notes 機能、Versionの一覧出力、要否/集約依頼→利用者
PJ階層作成Redmine PJ/階層構造を事前に作成する
機能,version事前設定Notes 機能,Version設定用SQL出力(LS)
Redmine 機能,Versionを事前に登録(SQL実行)
CSV出力Notes
Notes→Redmine移行用CSVファイル出力
(旧管理番号とNotesIDを含む)
Redmine Redmine上でCSVインポート
Notes→Redmine変換情報Redmine Redmine上で、チケットID/旧ID変換表出力
Notes Notes上で変換表を取込、各文書に対応するチケット番号を設定
担当者/発生バージョン情報設
定
Notes 各担当者、発生バージョン情報のRedmine設定用SQL出力（CFのUpdate)
Redmine SQL文を実行し、各担当者/発生バージョン等を設定
添付ファイル取込Notes 取込用メールIDに添付ファイル送信(LS)
Redmine RAKEでメール受信/添付ファイル取込
Role設定Redmine PJメンバ,担当MgrなどのRoleを初期設定し利用者に渡す
Notes参照専用設定Notes NotesDBは参照のみ可能とした(ACL設定）
LS LotusScript

御清聴ありがとうございました
• 統合作業が必要になったとき、多少なり
とも参考になれば幸いです。
• ご意見、内容指摘などはredmine.tokyoまで..
• 発表内容の受け皿/育成場所希望>スタッフ

後日補足/訂正(2014/11/30)
• 作業手順訂正(P41-43)
• 関連参考情報
– Redmineはプロジェクトを横断して使うべきか否かという議論
の感想
• http://forza.cocolog-nifty.com/blog/2014/11/redmine-
3e6e.html
– Notes移行作業例(第3回勉強会、町井さん、豊福さん)
• http://www.slideshare.net/vegashrine/redmineredmine-
12980139
– RedmineとRedmineを統合した話
• http://www.dabits.net/archives/226
• 2014/3発表で、自分の着手時は気が付きませんでした。
• 気付いていれば少しは楽できたかもorz

Redmineサーバ統合事例

Redmineサーバ統合事例

Recommended

More Related Content

What's hot

What's hot(20)

Similar to Redmineサーバ統合事例

Similar to Redmineサーバ統合事例(20)

More from Yuuki Nara

More from Yuuki Nara(7)

Redmineサーバ統合事例