Successfully reported this slideshow.

Redmineサーバ統合事例

8

Share

1 of 87
1 of 87

More Related Content

Related Books

Free with a 14 day trial from Scribd

See all

Related Audiobooks

Free with a 14 day trial from Scribd

See all

Redmineサーバ統合事例

  1. 1. Redmineサーバ統合事例 (2014/11/30公開版、発表後一部補足訂正有) 2014/11/15 redmine.tokyo 第7回勉強会 @y503unavailable 2014/11/15 第7回redmine.tokyo 勉強会Redmineサーバ統合事例@y503unavailable 1
  2. 2. Agenda • 自己紹介/謝辞/免責 • サーバ統合の背景 • Redmineサーバ統合作業手順 • Redmineの最適な運用規模? • Notes→Redmine移行回顧録 2014/11/30公開版 ・発表後一部内容訂正有、特にP41-43) ・最終頁に事後補足/関連情報追記 2014/11/15 第7回redmine.tokyo 勉強会Redmineサーバ統合事例@y503unavailable 2
  3. 3. 自己紹介 • 名前:y503unavailable – http503 ,貧乏暇無し、首が回らんorz – 503 Service Unavailable – サービス利用不可。サービスが一時的に過負荷やメンテナンスで使用不可能である。 – 例として、アクセスが殺到して処理不能に陥った場合に返される。 • 製造業で製品開発部門のadminやってます。 – 部門サーバ、LAN、PC、全般の子守 – (全社単位の情報システムとは別、部門所属) 2014/11/15 第7回redmine.tokyo 勉強会Redmineサーバ統合事例@y503unavailable 3
  4. 4. 謝辞 • 謝辞 – 公開されている各種情報を参考にして、Redmineを自 力で部内基幹情報システムとして構築運用すること ができました。 – Special Thans to • Redmine.Tokyo • R-labs • Redmine.JP • Redmine本家 • 各種サイト • ということで、自分も少しは貢献させてください。 2014/11/15 第7回redmine.tokyo 勉強会Redmineサーバ統合事例@y503unavailable 4
  5. 5. お断り • 発表内容は、自分が管理する環境における実施事例です。 • あくまで参考程度にお願いします。 – 使用していない機能は検証していません。 – 各自環境への適合性は勿論保証できません。 – データ破損が後日発見されるかもしれません。 – 異常処理は何も行っていません. – より効率的な方法もあるでしょう。 • 例 – チケット親子関係は利用せず – カスタムフィールドはissuesのみ利用 – トラッカーは、ほぼ単一(統合元サーバ) – MySQL依存 – Git未検証 • 説明対象:低レベルadminの作業参考(作業時の自分のレベル) 2014/11/15 第7回redmine.tokyo 勉強会Redmineサーバ統合事例@y503unavailable 5
  6. 6. サーバ統合作業の背景 簡単で便利な物は流行る • – Redmineの立ち上げは極簡単 • Bitnami(Win/VM)簡単過ぎ – 自PC上の野良Redmineも容易 – 低レベルadminでも立上げ可能(自分の事:-) • 予算措置、購入申請不要 • Rubyインストール済ならアプリ監視不能 – 使い始めれば必須のツールになる。 • 誰でも自分の構築した環境は可愛いもの • 結果的に長期間運用継続することになる。 – 利用を後押しする環境 • 有力なユーザコミュニテイ/サイト • ベストセラー本、好意的な雑誌 2014/11/15 第7回redmine.tokyo 勉強会Redmineサーバ統合事例@y503unavailable 6
  7. 7. サーバ統合作業の背景2 しかし • 数年経てば業務を取り巻く環境も変わる。 – 組織統廃合/天の声/上司・担当者の異動・退職、、、 • Redmineサーバを統合できないのか? • 一寸先は闇。その可能性は誰も否定できない。 • 備えあれば憂い無し 2014/11/15 第7回redmine.tokyo 勉強会Redmineサーバ統合事例@y503unavailable 7
  8. 8. BEFORE 2014/11/15 第7回redmine.tokyo 勉強会Redmineサーバ統合事例@y503unavailable 8
  9. 9. Redmineサーバ統合 • 作業経緯 • 作業方針/仕様 • 統合手法調査/準備 • 設計統合作業 • 利用者習熟、統合事前準備 • データ統合作業 – (統合-1)Versions,categories,変換して追加1 – (統合-2)Issues,members,cf,,,変換して追加2 – (統合-3)changesets, Journals,複雑なもの – 添付ファイル、SVN • 後始末/フォロー 2014/11/15 第7回redmine.tokyo 勉強会Redmineサーバ統合事例@y503unavailable 9
  10. 10. 試行PJ移行 結果良好 Go! Lotus Notes Redmine (SV-A) 作業経緯 担当退職 管理項目 フロー独自調整 Redmine (SV-B) 主な説明範囲 作業方針/仕様検討 統合手法調査,準備 設計統合データ統合 習熟 運用調整 統合運用 統合 事前準備 一元管理 計数管理 運用・設計 差異発生 計数管理問題 ・VerUp ・機能追加 SV-AはRedmine移行試行、 SV-Bに全体集約する予定だった ・VerUp ・機能追加 統合完了し 実運用中 2014/11/15 第7回redmine.tokyo 勉強会Redmineサーバ統合事例@y503unavailable 10 発表
  11. 11. 対象環境 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 2014/11/15 第7回redmine.tokyo 勉強会Redmineサーバ統合事例@y503unavailable 11
  12. 12. (参考)S/W障害管理属性 管理項目は概ね下記と同様 (チケット駆動開発P39-表2.1 より引用) 2014/11/15 第7回redmine.tokyo 勉強会Redmineサーバ統合事例@y503unavailable 12
  13. 13. 作業方針 • 一品料理で構わない – 過度の汎用化、ツール化はしない(工数削減、自分の能力:-) – 使用していない機能は対応しない(同上) – 例外処理は行わない.(同上、自慢することでは無い:-) – 手法は適材適所で利用,シンプルに,全体として安全方向に • 繰り返し作業は効率化 – 一回で作業が済む訳無い。(可能な範囲でBAT化) – 編集手作業を減らす。(SQL dump/import直接利用) – 手順書書くよりBAT化の方が楽(見通し効く範囲) • 上手く行ったら発表しよう – 前回の勉強会の時から目論んでましたw (モチベーション確保) 2014/11/15 第7回redmine.tokyo 勉強会Redmineサーバ統合事例@y503unavailable 13
  14. 14. 仕様/設計調整方針(1) • 仕様調整 – 共通化推進(管理項目(CF)/ステータス/ワークフロー) – 但し、PJの規模等で適切な管理項目/ステータスは異なる. (現実的な対応-ユーザとの信頼関係維持は必要) – 基本片寄せとするが、被統合サーバからの項目取込も有り • 共通化困難な箇所の対応 – PJ単位選択のカスタムフィールド – ステータス/ワークフロー複線化 (PJ内のメンバーRole指定で移行可否制御) – ENUMは調整不能(優先度、作業分類) – 類似業務のトラッカーは分割しない (歯止めが効かなくなる事を危惧) 2014/11/15 第7回redmine.tokyo 勉強会Redmineサーバ統合事例@y503unavailable 14
  15. 15. 仕様/設計調整方針(2) • チケット番号の重複対応 – 回避不能、統合前+20000とし、対比容易にした – SVNとのリンク含め、番号以外は継続利用 • PJ識別子、SVNレポジトリパス変更 – 名前空間調整(製品名prefix-後はPJ内判断) – 変更は統合作業時に実施 • 試行作業環境として手元のVM利用 • 試行環境コピー(VM)をユーザに公開しフィー ドバック/確認実施 2014/11/15 第7回redmine.tokyo 勉強会Redmineサーバ統合事例@y503unavailable 15
  16. 16. 仕様打合せ結果 • SV-A(被統合サーバ)利用者との打ち合わせ結果(2014/3) • 必須要件 – 従来同様に利用できること – 既存チケット/入力内容が継続利用可能 – チケット/SVN間のリンク保持 • 変更合意事項 – 管理項目/WFは,SV-B(統合先サーバ)に原則統合(片寄せ) – サーバIP/URL自体の変更 – チケットNoは、判り易く平行移動(1->20001,3000->23000) – PJ/REPOSの識別子は、一意性確保のため変更 (製品名略称-種別-名前) – その他、協議して調整(内容によってはSV-Aからの取込有) – 作業は2フェーズ(設計統合/サーバ統合)、フェーズ1-GW連休 2014/11/15 第7回redmine.tokyo 勉強会Redmineサーバ統合事例@y503unavailable 16
  17. 17. 統合手法調査/準備 • 作業経緯 • 作業方針/仕様 • 統合手法調査/準備 • 設計統合作業 • 利用者習熟、統合事前準備 • データ統合作業 – (統合-1)Versions,categories,変換して追加1 – (統合-2)Issues,members,cf,,,変換して追加2 – (統合-3)changesets, Journals,複雑なもの – 添付ファイル、SVN • 後始末/フォロー 2014/11/15 第7回redmine.tokyo 勉強会Redmineサーバ統合事例@y503unavailable 17
  18. 18. 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を処理する必要があり諦めた。 2014/11/15 第7回redmine.tokyo 勉強会Redmineサーバ統合事例@y503unavailable 18
  19. 19. テーブル調査 • (参考)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のテーブル – 現在使っていないプラグインのデータなど(更新日時) – 0で無くとも少ないものは要否判断/手作業移行有 2014/11/15 第7回redmine.tokyo 勉強会Redmineサーバ統合事例@y503unavailable 19
  20. 20. DB変換概要 • Users,Projects – Redmineシステム単位定義であり、大半のテーブルで参照 – 統合前に移行先に追加登録、変換テーブルを事前作成し、各テーブル を単純に変換 • Issue_Categories,Versions – Issuesなどで参照 – 単一テーブル上、所属PJ含み定義 – 統合作業最初に登録し、変換テーブル作成 • Issues,,その他 変換実施 支障: Duplicate entry • Changesets*,Journals*,Wiki* 多段のテーブル間参照関係、ちょっと複雑な作業になる。 • Settings 標準/プラグインの設定、YAML記録 • 詳細はRedmine自体のDB設計参照 • Pluginも要注意 2014/11/15 第7回redmine.tokyo 勉強会Redmineサーバ統合事例@y503unavailable 20
  21. 21. ID変換表作成(設計統合) • 設計統合に伴うID変換表を事前作成 • 設計統合作業の最後に、 変換テーブルまたはupdate文羅列で変換 – Status_id SV-A SV-B (被統合) (統合先) – Tracker_id – Role_id – Custom_field_id – CF内データ変換(管理用記号の置換など) 状態 3 4 受付待 4 6 分析中 5 9 処置完了 2014/11/15 第7回redmine.tokyo 勉強会Redmineサーバ統合事例@y503unavailable 21
  22. 22. settingsテーブル • 標準/プラグインの定義テーブル • 定義内容はYAMLで記録 • 各種定義内容の調整、差異比較確認必要 – 今回は何も作業しなかったが、結果的に問題は起きてない。 – (顕在化/認識していないだけかもしれない) – 移行作業時は気付かず、原稿作成中に発覚した。 2014/11/15 第7回redmine.tokyo 勉強会Redmineサーバ統合事例@y503unavailable 22
  23. 23. Redmineサーバ統合 • 作業経緯 • 作業方針/仕様 • 統合手法調査/準備 • 設計統合作業 • 利用者習熟、統合事前準備 • データ統合作業 – (統合-1)Versions,categories,変換して追加1 – (統合-2)Issues,members,cf,,,変換して追加2 – (統合-3)changesets, Journals,複雑なもの – 添付ファイル、SVN • 後始末/フォロー 2014/11/15 第7回redmine.tokyo 勉強会Redmineサーバ統合事例@y503unavailable 23
  24. 24. 設計統合作業 一言で言うと 統合先サーバのコピーに、 被統合サーバのデータを入れて差し替える。 データは被統合サーバ、動作/内部設計は統合先サーバ 統合先サーバ由来: OS/Redmine/Plugin/Redmine上設計情報(内部ID一致) (CF,WF,Status,Tracker,Roles,Plugin) 被統合サーバ由来: チケットデータ、ユーザ、プロジェクト、添付ファイル、SVN そのための作業内容 環境準備 Redmine本体/PluginのVer一本化 WF/CF/ステータス/ロール調整 2014/11/15 第7回redmine.tokyo 勉強会Redmineサーバ統合事例@y503unavailable 24
  25. 25. 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) 2014/11/15 第7回redmine.tokyo 勉強会Redmineサーバ統合事例@y503unavailable 25
  26. 26. Redmine設計統合作業ー2 (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) (詳細な動作確認は、データ変換後に実施) 2014/11/15 第7回redmine.tokyo 勉強会Redmineサーバ統合事例@y503unavailable 26
  27. 27. Redmine設計統合作業ー3 (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など) 2014/11/15 第7回redmine.tokyo 勉強会Redmineサーバ統合事例@y503unavailable 27
  28. 28. 設計統合時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 2014/11/15 第7回redmine.tokyo 勉強会Redmineサーバ統合事例@y503unavailable 28
  29. 29. 設計統合完了時のOUTPUT • 統合先(SV-B)と一致 – DB設計と内部ID(CF,WF,Status,Tracker,Roles,Plugin) – Redmine/Pluginのコード、OS – 基本片寄せ統合、一部項目は取込共通化 • 被統合(SV-A)の状態を保持(変換済項目除く) – Issues,Users,Projects,Repositories,Versions, issueCategories,members,,, 2014/11/15 第7回redmine.tokyo 勉強会Redmineサーバ統合事例@y503unavailable 29
  30. 30. 利用者習熟、統合作業準備 • 作業経緯 • 作業方針/仕様 • 統合手法調査/準備 • 設計統合作業 • 利用者習熟、統合事前準備 • データ統合作業 – (統合-1)Versions,categories,変換して追加1 – (統合-2)Issues,members,cf,,,変換して追加2 – (統合-3)changesets, Journals,複雑なもの – 添付ファイル、SVN • 後始末/フォロー 2014/11/15 第7回redmine.tokyo 勉強会Redmineサーバ統合事例@y503unavailable 30
  31. 31. 利用者習熟、統合事前準備 一言で言うと usersとprojectsは多くのテーブルが参照する。 統合先に事前追加し変換表を作成→統合作業の単純化 所要時間と作業リスク削減 段階的移行作業により、移行調整中の影響範囲を限定 (緊急対応時に影響受けるのは被統合サーバ利用者のみ) 統合作業準備/試行/デモの時間稼ぎ そのための作業内容 設計統合状態で1ヶ月仮運用(被統合サーバ) 被統合サーバのusers/projectsを統合先に先行追加/変換表作成 統合作業試行/作業手順調整数回(VM) 2014/11/15 第7回redmine.tokyo 勉強会Redmineサーバ統合事例@y503unavailable 31
  32. 32. 設計統合~統合作業前の作業 (利用者習熟/運用調整) • 最終的なサーバ統合前に、 設計統合状態で1か月仮運用した。 • 仮運用の目的 – サーバAユーザの移行先環境への習熟(項目、WF) – 問題点洗い出し/対応 – 調整要/トラブル発生時の影響範囲限定(リスク低減) • サーバA/B間の設計同一性は堅持 – 統合までの間、CF/WF/Status/Role/Pluginの 追加変更は、サーバA/B両方に実施した。 • 統合前準備作業(次頁)を並行実施 2014/11/15 第7回redmine.tokyo 勉強会Redmineサーバ統合事例@y503unavailable 32
  33. 33. 統合前事前準備作業(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変換テーブル有 2014/11/15 第7回redmine.tokyo 勉強会Redmineサーバ統合事例@y503unavailable 33
  34. 34. 統合前事前準備作業(2) • 統合前準備作業(統合作業準備) – 各テーブルの依存関係/登録数を調査 – 統合後サーバのサイジング • DISK:添付ファイル,SVN,DB,作業ワーク • MEMORY:DB割当メモリの検討(追加record数,,) • 対処不足→パフォーマンス問題、DISKFULL発生可能性 – 統合作業前にVM上で試行/リハーサル実施 – 統合作業直前に、users,projectsが最新取込済 か確認 2014/11/15 第7回redmine.tokyo 勉強会Redmineサーバ統合事例@y503unavailable 34
  35. 35. データ統合作業(1) • 作業経緯 • 作業方針/仕様 • 統合手法調査/準備 • 設計統合作業 • 利用者習熟、統合事前準備 • データ統合作業 – (統合-1)Versions,categories,変換して追加1 – (統合-2)Issues,members,cf,,,変換して追加2 – (統合-3)changesets, Journals,複雑なもの – 添付ファイル、SVN • 後始末/フォロー 2014/11/15 第7回redmine.tokyo 勉強会Redmineサーバ統合事例@y503unavailable 35
  36. 36. データ統合作業 一言?で言うと 設計統合済、users/projects追加済(の前提で) 被統合サーバデータを変換し、統合先に追加する。 (issues,custom_values,versions,issue_categories,members,journals一族,changesets一族,,,) ,,,だけで終わる訳が無く、色々と楽しませて頂きましたw ・REST,SQL、片方だけでは移行できない、親子関係注意 ・テーブルIDの階層的参照関係(統合前後の変換処理要) ・カスタムフィールドの数値文字列対応 ・CV/Journalの各種データタイプ対応 ・updateに数分掛かる(journal_details) ・refs #番号の変換(完全には出来てない) ・UNIQUE KEY使用箇所ででinsert失敗 ・SVN/添付ファイル→コピーし調整するだけ でも、なんとかなって運用できていると言う事で、終わり良ければry) 2014/11/15 第7回redmine.tokyo 勉強会Redmineサーバ統合事例@y503unavailable 36
  37. 37. データ統合作業概要 • 統合作業概要 – 環境準備 • SV-A,B共に保守停止(一日) • VMフルバックアップ • 統合先サーバのサイジング、users/projects最新確認 – 統合対象データの転送 • 統合対象テーブルの作業用ダンプ • 添付ファイル、SVNリポジトリ、その他 – チケット一括追加(REST) – ID変換が必要なテーブルは、SV-A時代のID保持 用カラムを一時的に追加 – 移動したテーブルのデータ変換、追加実施(SQL) 2014/11/15 第7回redmine.tokyo 勉強会Redmineサーバ統合事例@y503unavailable 37
  38. 38. チケット統合 • 前提:統合先15000件,被統合:3000件を、20001- 23000に移行 • Issuesのlft,rgt関連で、DB直接INSERTは断念 • 作業概要 – RESTで大量のダミーチケット追加し番号取得 (15000-23000までの8000件) – Issuesはデータupdate(チケット番号+20000) – Versions,categories,userid 変換テーブル噛ませてupdate • 注意事項 – 数千件のREST追加→所要時間注意(数十分) – (前日夜間実行もアリ) 2014/11/15 第7回redmine.tokyo 勉強会Redmineサーバ統合事例@y503unavailable 38
  39. 39. データ変換(ID参照関係無) • 単純なもの(versions,categories,,) – SV-B上で、SV-Aから移動したテーブルのデー タ変換 – project_id,user_id,issue_idを変換 – SV-B側テーブルにINSERTする 2014/11/15 第7回redmine.tokyo 勉強会Redmineサーバ統合事例@y503unavailable 39
  40. 40. データ変換(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する。 2014/11/15 第7回redmine.tokyo 勉強会Redmineサーバ統合事例@y503unavailable 40
  41. 41. insert時の重複キーエラー発生 (発表後訂正) – 発表時内容ではデータロス発生の可能性があるため、 下記訂正します。 – 変更内容 • 対策(1)のreplace into ではなく、対策(2)のdrop index で 対応してください。 • 作業手順として、統合前後のレコード数を確認してください。 – 理由 • >replace intoでは、キーが既に存在する場合、元のデータが DELETEしてからINSERTされる。 • キーが誤って重複判定されていた場合、誤ってDELETEされ、 意図せぬデータロスを招く可能性がある。 2014/11/15 第7回redmine.tokyo 勉強会Redmineサーバ統合事例@y503unavailable 41
  42. 42. 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; 対策次頁参照 2014/11/15 第7回redmine.tokyo 勉強会Redmineサーバ統合事例@y503unavailable 42
  43. 43. insertで重複キーエラー発生2 • 対象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; – 統合作業後は再設定してください。 2014/11/15 第7回redmine.tokyo 勉強会Redmineサーバ統合事例@y503unavailable 43
  44. 44. 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 2014/11/15 第7回redmine.tokyo 勉強会Redmineサーバ統合事例@y503unavailable 44
  45. 45. 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秒) 2014/11/15 第7回redmine.tokyo 勉強会Redmineサーバ統合事例@y503unavailable 45
  46. 46. 統合作業例示 • issue_categories • issues • custom_vaules • changeset(関連)/repositories • journals(関連) • 他テーブルも、概ね同様に処理します。 2014/11/15 第7回redmine.tokyo 勉強会Redmineサーバ統合事例@y503unavailable 46
  47. 47. 環境準備 – 環境準備 • SV-A,B共に保守停止(一日) • VMフルバックアップ • 統合先サーバの調整 – (事前検討に基づき、VMのDISK容量/メモリ調整) 2014/11/15 第7回redmine.tokyo 勉強会Redmineサーバ統合事例@y503unavailable 47
  48. 48. テーブル統合作業概要 (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保持用カラムを削除 2014/11/15 第7回redmine.tokyo 勉強会Redmineサーバ統合事例@y503unavailable 48
  49. 49. テーブル統合作業例 (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追加済 (今回は両サーバとも追加済で,統合作業への影響無) 2014/11/15 第7回redmine.tokyo 勉強会Redmineサーバ統合事例@y503unavailable 49
  50. 50. テーブル統合作業例 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兼用) 実際には最初に一括処理する。(依存関係注意) 2014/11/15 第7回redmine.tokyo 勉強会Redmineサーバ統合事例@y503unavailable 50
  51. 51. テーブル統合作業例 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; 2014/11/15 第7回redmine.tokyo 勉強会Redmineサーバ統合事例@y503unavailable 51
  52. 52. テーブル統合作業例 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の統合時に、この変換テーブルを利用する。 2014/11/15 第7回redmine.tokyo 勉強会Redmineサーバ統合事例@y503unavailable 52
  53. 53. データ統合作業(2) • 作業経緯 • 作業方針/仕様 • 統合手法調査/準備 • 設計統合作業 • 利用者習熟、統合事前準備 • データ統合作業 – (統合-1)Versions,categories,変換して追加1 – (統合-2)Issues,members,cf,,,変換して追加2 – (統合-3)changesets, Journals,複雑なもの – 添付ファイル、SVN • 後始末/フォロー 2014/11/15 第7回redmine.tokyo 勉強会Redmineサーバ統合事例@y503unavailable 53
  54. 54. テーブル統合作業概要 (issues) • (事前準備:SV-B) – SV-A分の事前追加登録/変換テーブル(projects, users,versions,issue_categories) • (被統合サーバ:SV_A) – 作業用テーブルにコピー,SQLダンプ • (統合先サーバ: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以外の各カラム) 2014/11/15 第7回redmine.tokyo 勉強会Redmineサーバ統合事例@y503unavailable 54
  55. 55. 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で別途設定 (今回利用せず) 2014/11/15 第7回redmine.tokyo 勉強会Redmineサーバ統合事例@y503unavailable 55
  56. 56. テーブル統合作業例 (issues) • RESTでチケット追加 • 今回はSQLからupdateしたが、RESTでも設定可能 • チケット親子関係は、登録後にRESTで設定する。 • (REST設定の参考リンク) • チケット親子関係使用時の注意 – 親子関係は、SQLではなくRESTでparent_issue_idを設定すること。 – 異常発生すると大変 – (参考)チケット親子関係トラブル-修復事例 – http://dqn.sakusakutto.jp/2012/04/redmine.html 2014/11/15 第7回redmine.tokyo 勉強会Redmineサーバ統合事例@y503unavailable 56
  57. 57. カスタムフィールド内容の変換 • 定義:custom_fields(統合済) • 値:custom_values(データ統合) • カスタムフィールドは、数値(id含)も数値文 字列のテキストデータで表現している。 • 種別:users,versions テーブル参照し変換 • 管理区分の記号など、業務ロジックを反映し 変換 • 調整必要(DB差異有?) • 作業例示 2014/11/15 第7回redmine.tokyo 勉強会Redmineサーバ統合事例@y503unavailable 57
  58. 58. テーブル統合作業例 (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 通常不要 2014/11/15 第7回redmine.tokyo 勉強会Redmineサーバ統合事例@y503unavailable 58
  59. 59. テーブル統合作業例 (custom_values,1) • (被統合サーバ:SV_A) – 作業用テーブルにコピー,SQLダンプ • (統合先サーバ: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)=translate_user.id_sv_a and custom_values_sv_a.custom_field_id in(12,15); 2014/11/15 第7回redmine.tokyo 勉強会Redmineサーバ統合事例@y503unavailable 59
  60. 60. テーブル統合作業例 (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; 2014/11/15 第7回redmine.tokyo 勉強会Redmineサーバ統合事例@y503unavailable 60
  61. 61. データ統合作業(3) • 作業経緯 • 作業方針/仕様 • 統合手法調査/準備 • 設計統合作業 • 利用者習熟、統合事前準備 • データ統合作業 – (統合-1)Versions,categories,変換して追加1 – (統合-2)Issues,members,cf,,,変換して追加2 – (統合-3)changesets, Journals,複雑なもの – 添付ファイル、SVN • 後始末/フォロー 2014/11/15 第7回redmine.tokyo 勉強会Redmineサーバ統合事例@y503unavailable 61
  62. 62. 時間確認 • ここで20分経過していたら • 残りの変換作業は飛ばします。 • 後日資料参照 • (22分経過していたので飛ばしました) 2014/11/15 第7回redmine.tokyo 勉強会Redmineサーバ統合事例@y503unavailable 62
  63. 63. 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で関連付 けられている。 2014/11/15 第7回redmine.tokyo 勉強会Redmineサーバ統合事例@y503unavailable 63
  64. 64. 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に追加 – 統合前後のID変換テーブル作成 2014/11/15 第7回redmine.tokyo 勉強会Redmineサーバ統合事例@y503unavailable 64
  65. 65. changeset/repositories 統合作業概要(2) • # changes(統合先changes_sv_a) – changeset_idを変換 – 統合先changesに追加 – 統合前後のID変換テーブル作成 • # changesets_issues統合先 changes_issues_sv_a) – changeset_idとissue_idを変換 – 統合先に追加 – 統合先サーバのjournal_detailsにinsertし追加 2014/11/15 第7回redmine.tokyo 勉強会Redmineサーバ統合事例@y503unavailable 65
  66. 66. changeset/repositories 統合作業概要(3) • # 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の例 – (完全な変換は出来ていないので識者補足希望) 2014/11/15 第7回redmine.tokyo 勉強会Redmineサーバ統合事例@y503unavailable 66
  67. 67. 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をキーとして結合している。 2014/11/15 第7回redmine.tokyo 勉強会Redmineサーバ統合事例@y503unavailable 67
  68. 68. 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利用は無い) 2014/11/15 第7回redmine.tokyo 勉強会Redmineサーバ統合事例@y503unavailable 68
  69. 69. Journalsテーブル • mysql> desc journals; – +------------------+-------------+------+-----+---------+---------+ – | Field | Type | Null | Key | Default | Extra | – +------------------+-------------+------+-----+---------+---------+ – | 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カラムに入る。変換必要 変換作業 緑:設計統合時変換 青:サーバ統合時変換 黒:通常変換無-黒 2014/11/15 第7回redmine.tokyo 勉強会Redmineサーバ統合事例@y503unavailable 69
  70. 70. journal_detailsテーブル • mysql> desc journal_details; – +------------+-------------+------+-----+---------+----------------+ – | Field | Type | Null | Key | Default | Extra | – +------------+-------------+------+-----+---------+----------------+ – | 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) 変換作業 緑:設計統合時変換 青:サーバ統合時変換 黒:通常変換無-黒 2014/11/15 第7回redmine.tokyo 勉強会Redmineサーバ統合事例@y503unavailable 70
  71. 71. Journal_details属性 • mysql> select property • from journal_details group by property; – +------------+ – | property | – +------------+ – | attr |標準項目の属性変更 – | cf |カスタムフィールドの変更 – | attachment |添付ファイル追加変更 – | relation |チケット間の関連付け – +------------+ 2014/11/15 第7回redmine.tokyo 勉強会Redmineサーバ統合事例@y503unavailable 71
  72. 72. Journal_details属性2(標準:attr) • mysql> select prop_key from journal_details • where property='attr' group by prop_key; – +------------------+ – | prop_key | – +------------------+ – | assigned_to_id |user_id変換 – | category_id |issue_categories変換 – | fixed_version_id |versions変換 – | parent_id |issue_id変換 – | project_id |project_id変換 – 上記以外は変換無: 2014/11/15 第7回redmine.tokyo 勉強会Redmineサーバ統合事例@y503unavailable 72
  73. 73. 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 | – ... 2014/11/15 第7回redmine.tokyo 勉強会Redmineサーバ統合事例@y503unavailable 73
  74. 74. Journal_details属性4 – property – | attachment | attachmentsのid(数値文字列) – | relation | 関連付け相手チケットのid(数値文字列) – old_value,value 新旧数値文字列を変換 2014/11/15 第7回redmine.tokyo 勉強会Redmineサーバ統合事例@y503unavailable 74
  75. 75. Journalsのコミット時チケット番号 変換 • 無理やりSQLで変換した。 • 完全な対応はできていない。 • # Changeset/repoの3と同じ 2014/11/15 第7回redmine.tokyo 勉強会Redmineサーバ統合事例@y503unavailable 75
  76. 76. データ統合作業(添付/SVN) • 作業経緯 • 作業方針/仕様 • 統合手法調査/準備 • 設計統合作業 • 利用者習熟、統合事前準備 • データ統合作業 – (統合-1)Versions,categories,変換して追加1 – (統合-2)Issues,members,cf,,,変換して追加2 – (統合-3)changesets, Journals,複雑なもの – 添付ファイル、SVN • 後始末/フォロー 2014/11/15 第7回redmine.tokyo 勉強会Redmineサーバ統合事例@y503unavailable 76
  77. 77. 添付ファイル • 添付ファイル自体は単純にファイルコピー – Redmine内に保管されているファイル名は、 ファイルのアップロード日時分秒_ファイル名 – 通常の利用(人の操作で添付)で、 サーバ間重複することは、事実上考えられない。 • 変換処理 – attachmentsテーブル チケット番号/ユーザID部分を一括変換 – journalsでattachmentsのid利用 →変換テーブル作成要 2014/11/15 第7回redmine.tokyo 勉強会Redmineサーバ統合事例@y503unavailable 77
  78. 78. SVNレポジトリ • (前提) – SVN-Apache経由で公開,ADのIDでアクセス制限 – レポジトリ自体の統合は行わない(必要時別途作業) – 統合後もレポジトリ名が一意になるよう事前調整 • (作業) – レポジトリ自体は単純コピー – Httpd.confは追加修正(レポジトリ名、保管フォルダ変更) – 各レポジトリのaccess.txtは変更無 – Journals上のrefs#チケット番号はSQLで変更した。 (changesets_issuesとは別に) – SVN log上のチケット番号は変換しなかった。 (チケット番号の対比が明確で容易のため省略) 2014/11/15 第7回redmine.tokyo 勉強会Redmineサーバ統合事例@y503unavailable 78
  79. 79. 利用者習熟、統合作業準備 • 作業経緯 • 作業方針/仕様 • 統合手法調査/準備 • 設計統合作業 • 利用者習熟、統合事前準備 • データ統合作業 – (統合-1)Versions,categories,変換して追加1 – (統合-2)Issues,members,cf,,,変換して追加2 – (統合-3)changesets, Journals,複雑なもの – 添付ファイル、SVN • 後始末/フォロー 2014/11/15 第7回redmine.tokyo 勉強会Redmineサーバ統合事例@y503unavailable 79
  80. 80. 後始末、フォロー • 制限/今回実施せず – カスタムクエリ定義は手動設定変更で対処した。 Cf-番号で変換できそうだが、定義数も少なかったため。 – グローバルのカスタムクエリは残した。 SV-Aでは顧客毎にPJ作成しており、グローバルにSV-Bと同一名称のカスタムクエリを 設定していた。顧客数分設定は無理なので、(SV-A移行分)と名前付けて残した。 • 運用変更 – SV-Aの移行時の運用担当者にAdmin権限付けた。 – (コンソールは渡してない) • 移行作業後 – 移行作業自体に起因するトラブルはなく運用できている。 – 当初目的の計数管理の一元化は実施できた。 • 作業終わって、Shinagawa.redmineに発表打診 2014/11/15 第7回redmine.tokyo 勉強会Redmineサーバ統合事例@y503unavailable 80
  81. 81. 変換作業時の留意点(復習) • 特に注意すべき点/面倒な点の復習 – 複合Indexを一旦削除必要な場合があった – refs #IDの変換 – RESTチケット追加後、cv追加前にREST追加時のcvを 削除必要 • その他。。 – チケット親子関係はRESTで別途設定 – プロジェクトの親子関係は手動設定(REST無) – issues以外のカスタムフィールドがある場合は、変換 処理を追加必要(custom_values,journal_details) – REST大量チケット追加時の所要時間(事前確認) 2014/11/15 第7回redmine.tokyo 勉強会Redmineサーバ統合事例@y503unavailable 81
  82. 82. AFTER 2014/11/15 第7回redmine.tokyo 勉強会Redmineサーバ統合事例@y503unavailable 82
  83. 83. Redmineの適切な運用規模? ユーザ数10,30(個別)/100,300(部門)/1000,3000(全体) PJ/Gr/事業部/全社、ニーズ差異 立場、運用姿勢によっても異なる?対立構造 本来の目的現場視点の品質/生産性向上管理する事が目的? Redmine 個別管理(PJ/Gr) 部門管理全体統合 機能変更対応影響範囲少/ 迅速な対応 (要管理者) 影響範囲中/ 迅速な対応 影響範囲拡大、 全体の変更困難/遅 い 管理面バラバラシステム 管理者有無 管理レベル差異 管理者有全体最適?? 一元管理 管理者有 ユーザ側意識小集団活動 自分の物にする。 愛着、 主体性持って管理 顔が見える範囲 顔が見えている 範囲(のつもり) だが、 人/場所差異? (部内関係、対人 関係,,,) 押付け、 やらされ感 一体感無 ニーズ合わず →結果的に二重管理 2014/11/15 第7回redmine.tokyo 勉強会Redmineサーバ統合事例@y503unavailable 83
  84. 84. 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は取り込めていない。 2014/11/15 第7回redmine.tokyo 勉強会Redmineサーバ統合事例@y503unavailable 84
  85. 85. 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 2014/11/15 第7回redmine.tokyo 勉強会Redmineサーバ統合事例@y503unavailable 85
  86. 86. 御清聴ありがとうございました • 統合作業が必要になったとき、多少なり とも参考になれば幸いです。 • ご意見、内容指摘などはredmine.tokyoまで.. • 発表内容の受け皿/育成場所希望>スタッフ 2014/11/15 第7回redmine.tokyo 勉強会Redmineサーバ統合事例@y503unavailable 86
  87. 87. 後日補足/訂正(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 2014/11/15 第7回redmine.tokyo 勉強会Redmineサーバ統合事例@y503unavailable 87

×