Permalink
Switch branches/tags
Nothing to show
Find file Copy path
Fetching contributors…
Cannot retrieve contributors at this time
320 lines (222 sloc) 7.3 KB

name: inverse layout: true class: underscore


class: center, middle, hero

乱立してるRedmineを一つにまとめる話

@douhashi


自己紹介

  • 堂端 翔 (どうはし しょう)
  • facebook.com/douhashi
  • 一児の父 もう少しで4歳

class: center, middle

最近の出来事


class: center

ninebot(セグウェイ)買いました


class: center

うぇーい


仕事では

  • Agileware Inc. CTO
    • 最近はインフラ屋さん
    • Ansible / AWS マニア

ここで少し、会社の紹介をさせてください


class: center, middle

はい、会社紹介終わり。


class: center, middle

今日のお話


class: center, middle

いっぱいあるRedmineを統合するお話をします。


アンケート

社内にRedmineは複数ある or ない?


class: center, middle

ある日、お客さんと話していたら


class: center, middle

こんな依頼が。


class: center, middle

「複数あるRedmineを統合したい」


お客さんの情報

  • 富士機械製造株式会社 さま
    • ドメイン fuji.co.jp なんだぜ
  • 電子部品を作る機械を作る会社さん
    • nmとかいう単位で基盤に穴あけするとか。
  • 超カッコいい。

統合したい理由

  1. 現在 20台 以上のRedmineが乱立していて運用もバラバラ
    • ハード屋さんとソフト屋さんのワークフローが分離してたり。
  2. 大きなプロジェクト単位でRedmineが分かれてる
  3. すべてのインスタンスが1台のサーバに同居しているのでパフォーマンスの問題もでているので解消したい

class: center, middle

よくわかる。


Redmine運用って

  • 最初はワークフローもチーム(部署/開発チームとか)で自由に定義して運用したい
  • 最初からベストなワークフローなんて思いつかない
  • とりあえずインスタンス分けて小さくやっていくのは自然な流れ

でもある時点から

  • 大体各々の業務フローもわかってきた
    • 大部分は統一できるんじゃね?という思い
  • 横串で見たい
  • 分析したい

=> 統合したい、っていう欲求が生まれる


class: center, middle

わかった。じゃあ統合しよう。

(結構カジュアルに決断)


class: center, middle

ここから苦労話スタート。


Redmine側の課題 1

Redmineって...

チケット番号 = DBのIDなんだよね...


チケット番号 = ID問題

  1. DB上のauto incrementなid列をチケット番号に使用している
  2. コミットコメントやチケット等で「#100」などチケット番号で参照している

=> つまり、単純にCSV出力/インポートでは参照が崩れる!


Redmine側の課題 2

単純に統合しちゃうと、トラッカーとかステータス大爆発しちゃうよね

出来る限りはまとめたい、よねー。


class: center, middle

解決策


class: center, middle

賢いRedmine統合ツール作った

(弊社の優秀なエンジニアが...!)


こんな感じ

  1. 統合元Redmineのデータを 中間データ(SQLite) としてエクスポート
    • 統合前のIDを中間データに保存しておく(from ID)
  2. 統合先へインポート
    • 統合後のIDを保存しておく(to ID)
  3. from idを元に、チケット/Wiki/コミットコメント等の参照を張り替える

こんなことも出来る

  1. 統合元Redmineのトラッカーやカテゴリ、ステータス等を統合先の既存データに合わせる
    • 設定ファイルで定義できるようにした
  2. 添付ファイルをごっそり移行する

(技術的に)スゴいポイント

  1. 統合ツールはRedmineプラグインとして実装。
    • 外部ツールではない
    • メリット: Redmineが有する機能をそのまま使える
    • デメリット: Redmineバージョンにカナリ依存する

class: center, middle

賢いツールができたので

いざ、統合テスト!!


class: center, middle

ここで問題発生


class: center, middle

むっちゃ遅い!!!


最大級のRedmineだけで

  1. チケット 約 15,000
  2. 履歴 約 200,000
  3. カスタムフィールドの入力値 約 200,000

このデータ量で3日かけてもインポートまで終わらない...


class: center, middle

でも、業務は継続しないと

= 休日しか統合作業できない


class: center, middle

ここからが本当の戦い


インフラ的アプローチ

  1. サーバスペックの一時的増強
    • 通常運用時の倍ぐらいにあげて貰った

けど、IOが足を引っ張って1.3倍ぐらいの成果...


ソフト的アプローチ

  1. CPUの有効活用のため、プロセスを分割する
  2. 時間のかかる履歴/コミットログ等のチケット参照の書き換え処理を分離、統合後に実行可能とした

class: center, middle

ちなみに


class: center, middle

テスト開始からここまでで2ヶ月ぐらいかかってます

(土日は客先での寝泊まりの日々)


class: center, middle

守衛さんも顔パスするレベル

「アジャイルさんね。今日も遅いの?」


class: center, middle

流石に客先で寝るのは辛いので...


スマホに通知!

  1. 都度都度push通知するようにした
    • im.kayac.com というRESTでケータイに通知送れるサービス
    • 便利なのでぜひ。

class: center, middle

涙ぐましい努力の結果

一番デカい子が 43時間 で、統合出来るようになりました。


class: center, middle

。。。


class: center, middle

(43時間かよ... とか言わないで><)


class: center, middle

無事、最終的に移行対象となった16台のRedmineサーバが統合されました


統合後のRedmine

  • プロジェクト数: 1,434
  • チケット数: 92,710
  • 履歴: 377,513
  • CFの値: 851,932
  • コミットログ: 1,058,789

統合してみたメリット

  1. 一元管理が出来る
  2. 他のプロジェクトの様子が見える
  3. 業務フローを統合していける

感想

  1. 大変だったけど、チャレンジする価値はある
  2. 一元管理できると、プロジェクトの問題、運用の問題が見えるようになる

今後の運用課題

  1. アクセス集中によるパフォーマンス劣化対応
  2. 業務分析、ワークフローの統一化(大変そう)

やってみたいこと

  1. せっかくデカいRedmineができたので、いろいろデータ分析していきたい。
    • 業務フローのパターン洗い出しとか、出来そうだよね。
  2. パフォーマンスチューニングの練習。

class: center, middle

もし、Redmine統合したい方がいましたら、


class: center, middle

懇親会もいるので、お声がけください。


class: center, middle

ご清聴、ありがとうございました。