Embed Size (px)
Citation preview
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のおかげで夢が広がる！
ご清聴ありがとうございました
