Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

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

4,228 views

Published on

Redmine 4.0 に向けたプラグイン開発の話。 at redmine.tokyo 13

Published in: Engineering
  • Be the first to comment

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

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

×