Redmine4時代の
プラグイン開発
強いプラグインを開発しよう
Agileware Inc. Sho DOUHASHI

自己紹介

自己紹介
堂端 翔 ( Sho DOUHASHI )
facebook.com/douhashi
twitter @douhashi
Agileware Inc. CTO
プログラミング歴20年弱。最近はインフラ屋さん。AWS大
好き。

Agileware?
http://agileware.jp
Ruby/Railsを得意とするソフトウェアベンダー。
Redmineプラグイン「LycheeRedmine」シリーズを開発。
https://lychee-redmine.jp/

突然ですが、アンケート

Q1. Redmineバージョンいくつですか？

Q2. Redmineプラグイン使ってますか？

Q3. 独自のプラグインを
開発して使ってますか？

ご協力ありがとうございます！

今日はRedmineの
プラグイン開発についてお話します

本日のアジェンダ

本日のアジェンダ
1. RedmineとRailsの関係
2. 強いプラグインの開発方
3. Redmine 4.x 時代のプラグイン開発 (ダークサイド)
4. Redmine 4.x 時代のプラグイン開発 (ライトサイド)
5. まとめ

本日のアジェンダ
1. RedmineとRailsの関係
2. 強いプラグインの開発方
3. Redmine 4.x 時代のプラグイン開発 (ダークサイド)
4. Redmine 4.x 時代のプラグイン開発 (ライトサイド)
5. まとめ

RedmineとRailsの関係

の前に、

Railsのリリース傾向の話

Railsの(だいたいの)リリース傾向
● だいたい、３年スパンでメジャーが上がる
● だいたい、.0系(2.0, 3.0, 4.0)はアップデートを促すための
過渡期リリース
● だいたい、.0系リリースは旧バージョンへのDeplication
Warningを出して、その後のリリースで削除してく
● だいたい、.1 とか .2 でドラスティックな機能追加、API
削除が入る

その上で、RedmineとRailsのバージョン
の関係をみていきましょう。

RedmineとRailsの関係
● Redmine 2.0 ~
○ Rails 3.2系
● Redmine 3.0 ~
○ Rails 4.2 系

おわかりいただけただろうか...

RedmineとRailsの関係
● Redmine 2.0 ~
○ Rails 3.2系
● Redmine 3.0 ~
○ Rails 4.2 系

ド、ドラスティッ
ク...
ドラスティック【drastic】
（ 形動 ）
徹底的で激烈なさま。 「政治情勢は－に展開している」 「 －な変
化」

なので、

Redmineプラグインあるある

新バージョンでいきなりデスる

解決策
(びっくりしないために)

次リリースブランチでも動かそう
● 次期リリースバージョンのRedmineで動かしておこう。
● 毎度動かすのは大変なのでテスト書こう。
● 特に、Railsのメジャーが上がるときは覚悟しておこう。

その他にも「強い」プラグインを
作る工夫は色々

ということで、次の話題

本日のアジェンダ
1. RedmineとRailsの関係
2. 強いプラグインの開発方
3. Redmine 4.x 時代のプラグイン開発 (ダークサイド)
4. Redmine 4.x 時代のプラグイン開発 (ライトサイド)
5. まとめ

弊社で実践しているプラグイン開発の仕
方

ルールその１
本体のDBにカラム追加/変更しない

本体のDBにカラム追加/変更しない

本体のDBにカラム追加/変更しない
● 本体DBに直接カラム追加しないことで、Redmine本体へ
の侵食を減らす
○ 本体側で同等機能が追加されてもバッティングしない
○ Redmine本体のバージョンアップを妨げない
○ 他のプラグインの動作を妨げない

ルールその2
開発時必要なGemはGemfile.localに書く
（= Gemfileは最小限に留める）

プラグインあるある
● たまーに、Gemfileにバージョン指定して書いてあるプラ
グインがいる
○ 同じGemを違うバージョン指定でいれようとする
=> bundleできなくてデスる ☠
=> コレ、テスト用のGemとかで非常に多い

開発時のみ必要なGemはGemfile.localに書く
● Gemfile.localに書いて、Redmine本体直下へsymlink
● Gemfileには「プラグインに必ず必要なGemのみ」書く
○ これでGemがバッティングする可能性を減らせる
○ それでもたまーにバッティングするので、その時は
githubでissueをあげてみましょう

弊社のGemfile.local

ルールその3
テストはRSpecで書く

プラグインあるある
● Redmine標準はMinitestベース
○ テストデータはfixturesで作られてる
=> 正直、fixturesでかすぎて覚えてられない。
=> setupに必要な情報が多すぎる

テストはRspecで書く
● RSpec、FactoryBotで書く
● 画面系はcapybaraでE2Eテスト
○ controllerのテストは労力に見合わないかも
=> Factory書くのしんどいけど、一回書けば使い回しできる

他にも細かいTipsはいろいろあります

細かいTips
● Rubocopいれてコードをキレイに保つ
● init.rbにはあんまり処理を実装しない
● モンキーパッチは最小限に
などなど...

語り尽くせないほどあるので、
とっ捕まえて聞いてください...

次の話題

本日のアジェンダ
1. RedmineとRailsの関係
2. 強いプラグインの開発方
3. Redmine 4.x 時代のプラグイン開発 (ダークサイド)
4. Redmine 4.x 時代のプラグイン開発 (ライトサイド)
5. まとめ

いよいよ、Redmine4.0が見えてきまし
た

Redmine 4.0開発状況

Redmine 4.0の目玉はやっぱり

Rails 5.x 対応！

Redmine4.0のRailsバージョンは...

ド、ドラ(ry
ドラスティック【drastic】
（ 形動 ）
徹底的で激烈なさま。 「政治情勢は－に展開している」 「 －な変
化」

いろんなプラグインの悲鳴が聞こえる

Rails 5で消えるAPI (影響度の大きそうなもの)
1. before_filter / after_filter (4.x時点でDeplication)
○ 歴史の古いプラグインはそのままのことが多い
2. alias_method_chain
○ Redmineの標準動作を書き換えるときの常套手段
○ お世話になってる人多いはず

対策

Rails 5対応
1. before_filter / after_filter (4.x時点でDeplication)
○ before_action / after_action を使う
2. alias_method_chain
○ Module#prepend (Ruby 2.0からの標準機能)を使う
○ https://docs.ruby-
lang.org/ja/latest/method/Module/i/prepend.html

ただし、一個問題が。

問題: Redmine 3.x系 との共存

課題: Redmine 3.xとの共存
1. Redmine 3.x は ruby 1.9.3 もサポートしている
○ つまり、ruby 2.0.0 からの Module#prepand が使えな
い
=> コード内にバージョン判別書くのはしんどい...
=> しばらくbranch分けるとかで様子見か...?

こんな、後ろ向きな話ばかりじゃないよ

本日のアジェンダ
1. RedmineとRailsの関係
2. 強いプラグインの開発方
3. Redmine 4.x 時代のプラグイン開発 (ダークサイド)
4. Redmine 4.x 時代のプラグイン開発 (ライトサイド)
5. まとめ

Rails 5.1の目玉機能

ActionCable！

ActionCableって？
1. Rails上でWebSocket通信を実現するためのライブラリ
2. ソケット通信のように双方向の通信がリアルタイムで行
えるので、よりインタラクティブなプラグインが作れる

例えば...

Redmine上にチャットシステム導入！

例えば...

チケット更新のリアルタイム通知!

夢が広がりますね！

本日のアジェンダ
1. RedmineとRailsの関係
2. 強いプラグインの開発方
3. Redmine 4.x 時代のプラグイン開発 (ダークサイド)
4. Redmine 4.x 時代のプラグイン開発 (ライトサイド)
5. まとめ

まとめ
1. Redmineはドラスティックに変わる
○ 強いプラグインの開発が大事
2. Redmine 4.x でもドラスティックに変わる
○ 旧バージョンとの共存が課題
○ Rails5のおかげで夢が広がる！

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