Redmine4時代のプラグイン開発 redmine.tokyo #13

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/

http://agileware.jp

突然ですが、アンケート

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

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

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

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

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

本日のアジェンダ


1. RedmineとRailsの関係

2. 強いプラグインの開発方

3. Redmine 4.x 時代のプラグイン開発 (ダークサイド)

4. Redmine 4.x 時代のプラグイン開発 (ライトサイド)

5. まとめ






5. まとめ

RedmineとRailsの関係

の前に、

Railsのリリース傾向の話

Railsの(だいたいの)リリース傾向

● だいたい、３年スパンでメジャーが上がる

● だいたい、.0系(2.0, 3.0, 4.0)はアップデートを促すための

過渡期リリース

● だいたい、.0系リリースは旧バージョンへのDeplication

Warningを出して、その後のリリースで削除してく

● だいたい、.1 とか .2でドラスティックな機能追加、API

削除が入る

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


● Redmine 2.0 ~

○ Rails 3.2系

● Redmine 3.0 ~

○ Rails 4.2 系

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


● Redmine 2.0 ~

○ Rails 3.2系● Redmine 3.0 ~

○ Rails 4.2系

ド、ドラスティック...

ドラスティック【drastic】

（形動）

徹底的で激烈なさま。「政治情勢は－に展開している」「－な変

化」

なので、

Redmineプラグインあるある

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

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

次リリースブランチでも動かそう

● 次期リリースバージョンのRedmineで動かしておこう。

● 毎度動かすのは大変なのでテスト書こう。

● 特に、Railsのメジャーが上がるときは覚悟しておこう。

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

ということで、次の話題






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にはあんまり処理を実装しない

● モンキーパッチは最小限に

などなど...

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

次の話題






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分けるとかで様子見か...?

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






5. まとめ

Rails 5.1の目玉機能

ActionCable！

ActionCableって？

1. Rails上でWebSocket通信を実現するためのライブラリ

2. ソケット通信のように双方向の通信がリアルタイムで行

えるので、よりインタラクティブなプラグインが作れる

例えば...

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

例えば...

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

夢が広がりますね！






5. まとめ

まとめ

1. Redmineはドラスティックに変わる

○ 強いプラグインの開発が大事

2. Redmine 4.x でもドラスティックに変わる

○ 旧バージョンとの共存が課題

○ Rails5のおかげで夢が広がる！

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

Redmine4時代のプラグイン開発 redmine.tokyo #13

Engineering