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サーバ統合事例

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Was ist angesagt?

Was ist angesagt? (20)

Ähnlich wie Redmineサーバ統合事例

Ähnlich wie Redmineサーバ統合事例 (20)

Mehr von Yuuki Nara

Mehr von Yuuki Nara (8)

Redmineサーバ統合事例