Redmine4時代のプラグイン開発 redmine.tokyo #13
- 2. 自己紹介
- 3. 自己紹介 堂端 翔 ( Sho DOUHASHI ) facebook.com/douhashi twitter @douhashi Agileware Inc. CTO プログラミング歴20年弱。最近はインフラ屋さん。AWS大 好き。
- 5. 突然ですが、アンケート
- 11. 本日のアジェンダ
- 12. 本日のアジェンダ 1. RedmineとRailsの関係 2. 強いプラグインの開発方 3. Redmine 4.x 時代のプラグイン開発 (ダークサイド) 4. Redmine 4.x 時代のプラグイン開発 (ライトサイド) 5. まとめ
- 13. 本日のアジェンダ 1. RedmineとRailsの関係 2. 強いプラグインの開発方 3. Redmine 4.x 時代のプラグイン開発 (ダークサイド) 4. Redmine 4.x 時代のプラグイン開発 (ライトサイド) 5. まとめ
- 14. RedmineとRailsの関係
- 15. の前に、
- 16. Railsのリリース傾向の話
- 17. Railsの(だいたいの)リリース傾向 ● だいたい、３年スパンでメジャーが上がる ● だいたい、.0系(2.0, 3.0, 4.0)はアップデートを促すための 過渡期リリース ● だいたい、.0系リリースは旧バージョンへのDeplication Warningを出して、その後のリリースで削除してく ● だいたい、.1 とか .2 でドラスティックな機能追加、API 削除が入る
- 19. RedmineとRailsの関係 ● Redmine 2.0 ~ ○ Rails 3.2系 ● Redmine 3.0 ~ ○ Rails 4.2 系
- 20. おわかりいただけただろうか...
- 21. RedmineとRailsの関係 ● Redmine 2.0 ~ ○ Rails 3.2系 ● Redmine 3.0 ~ ○ Rails 4.2 系
- 22. ド、ドラスティッ ク... ドラスティック【drastic】 （ 形動 ） 徹底的で激烈なさま。 「政治情勢は－に展開している」 「 －な変 化」
- 23. なので、
- 24. Redmineプラグインあるある
- 25. 新バージョンでいきなりデスる
- 26. 解決策 (びっくりしないために)
- 27. 次リリースブランチでも動かそう ● 次期リリースバージョンのRedmineで動かしておこう。 ● 毎度動かすのは大変なのでテスト書こう。 ● 特に、Railsのメジャーが上がるときは覚悟しておこう。
- 29. ということで、次の話題
- 30. 本日のアジェンダ 1. RedmineとRailsの関係 2. 強いプラグインの開発方 3. Redmine 4.x 時代のプラグイン開発 (ダークサイド) 4. Redmine 4.x 時代のプラグイン開発 (ライトサイド) 5. まとめ
- 34. 本体のDBにカラム追加/変更しない ● 本体DBに直接カラム追加しないことで、Redmine本体へ の侵食を減らす ○ 本体側で同等機能が追加されてもバッティングしない ○ Redmine本体のバージョンアップを妨げない ○ 他のプラグインの動作を妨げない
- 36. プラグインあるある ● たまーに、Gemfileにバージョン指定して書いてあるプラ グインがいる ○ 同じGemを違うバージョン指定でいれようとする => bundleできなくてデスる ☠ => コレ、テスト用のGemとかで非常に多い
- 37. 開発時のみ必要なGemはGemfile.localに書く ● Gemfile.localに書いて、Redmine本体直下へsymlink ● Gemfileには「プラグインに必ず必要なGemのみ」書く ○ これでGemがバッティングする可能性を減らせる ○ それでもたまーにバッティングするので、その時は githubでissueをあげてみましょう
- 38. 弊社のGemfile.local
- 40. プラグインあるある ● Redmine標準はMinitestベース ○ テストデータはfixturesで作られてる => 正直、fixturesでかすぎて覚えてられない。 => setupに必要な情報が多すぎる
- 41. テストはRspecで書く ● RSpec、FactoryBotで書く ● 画面系はcapybaraでE2Eテスト ○ controllerのテストは労力に見合わないかも => Factory書くのしんどいけど、一回書けば使い回しできる
- 43. 細かいTips ● Rubocopいれてコードをキレイに保つ ● init.rbにはあんまり処理を実装しない ● モンキーパッチは最小限に などなど...
- 45. 次の話題
- 46. 本日のアジェンダ 1. RedmineとRailsの関係 2. 強いプラグインの開発方 3. Redmine 4.x 時代のプラグイン開発 (ダークサイド) 4. Redmine 4.x 時代のプラグイン開発 (ライトサイド) 5. まとめ
- 48. Redmine 4.0開発状況
- 50. Rails 5.x 対応！
- 53. ド、ドラ(ry ドラスティック【drastic】 （ 形動 ） 徹底的で激烈なさま。 「政治情勢は－に展開している」 「 －な変 化」
- 55. Rails 5で消えるAPI (影響度の大きそうなもの) 1. before_filter / after_filter (4.x時点でDeplication) ○ 歴史の古いプラグインはそのままのことが多い 2. alias_method_chain ○ Redmineの標準動作を書き換えるときの常套手段 ○ お世話になってる人多いはず
- 56. 対策
- 57. 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
- 58. ただし、一個問題が。
- 59. 問題: Redmine 3.x系 との共存
- 60. 課題: Redmine 3.xとの共存 1. Redmine 3.x は ruby 1.9.3 もサポートしている ○ つまり、ruby 2.0.0 からの Module#prepand が使えな い => コード内にバージョン判別書くのはしんどい... => しばらくbranch分けるとかで様子見か...?
- 62. 本日のアジェンダ 1. RedmineとRailsの関係 2. 強いプラグインの開発方 3. Redmine 4.x 時代のプラグイン開発 (ダークサイド) 4. Redmine 4.x 時代のプラグイン開発 (ライトサイド) 5. まとめ
- 63. Rails 5.1の目玉機能
- 64. ActionCable！
- 66. 例えば...
- 68. 例えば...
- 69. チケット更新のリアルタイム通知!
- 70. 夢が広がりますね！
- 71. 本日のアジェンダ 1. RedmineとRailsの関係 2. 強いプラグインの開発方 3. Redmine 4.x 時代のプラグイン開発 (ダークサイド) 4. Redmine 4.x 時代のプラグイン開発 (ライトサイド) 5. まとめ
- 72. まとめ 1. Redmineはドラスティックに変わる ○ 強いプラグインの開発が大事 2. Redmine 4.x でもドラスティックに変わる ○ 旧バージョンとの共存が課題 ○ Rails5のおかげで夢が広がる！
- 73. ご清聴ありがとうございました