Redmine + GitBucketで実現する Redmineでプルリクエスト

Redmine + GitBucketで実現する Redmineでプルリクエスト

redmine.tokyo の第16回勉強会 で発表したLTのスライドです。もしかしたら後日Qiitaでフォローエントリを上げるかもしれません。

4bfdd9b38e3f81f80e543004d810093d?s=128

Yuusuke KOUNOIKE

May 18, 2019
Tweet

Transcript

  1. 2019/5/18 redmine.tokyo 第16回勉強会 鴻池 祐輔 Redmine + GitBucket で実現する 「Redmine

    でプルリクエスト」 第14回パネルディスカッションへのアンサーとして 1
  2. ⾃⼰紹介 鴻池(こうのいけ) 祐輔 u 各種アカウント u Twitter: @ko_noike / GitHub,

    Qiita等: kounoike u Redmine歴: ちょっと古い2.xくらいの時代にそれなりに u 前々職時代に職場でRedmine+Subversionで委託先(Gr会社)と連携 u プラグイン10個くらい⼊れてたかな︖&複雑なワークフロー・カスタムフィールド u 外注→内製シフトに合わせてGitBucketに移⾏ u GitBucket歴: 使う側から開発側に u 職場での使⽤経験を元に貢献→開発側に(Scala覚えました) u 現在#2 コミッタ u 現職︓株式会社フューチャースタンダード u RedmineもGitBucketも使ってません 2
  3. 知っていますか︖ uRedmine uGitHub uGitBucket (×BitBucket) 3

  4. GitBucket u https://github.com/gutbucket/gitbucket/ https://gitbucket.github.io/ u “A Git platform powered by

    Scala with easy installation, high extensibility & GitHub API compatibility” u GitHub のように Pull Request / Issue / Wiki を持つself hostedなWebアプリ u プラグインによる拡張が可能 u プラグイン例 u メール通知 / Gist / Pages / Emoji / 検索 / デスクトップ通知 / バックアップ u ファイルフォーマットごとのレンダリング u その気になればコア部分の動作をかなり操作可能 4
  5. redmine.tokyo#14 パネルディスカッション 「GitとRedmineをどのように連携するのが効果的か」 【使⽤状況】 u 楠川さん u 「GitLabと連携」といってもgitリポジトリ作成/管理ツールとしてしか使ってない u 川端さん

    u GitHub利⽤・Issue管理とPR管理を分離して使っている 【論点=そのまま結論︖】 u 「RedmineとGitHub/GitLabは住み分け」 【所感】 u 技術的に出来ていないことを運⽤⾯での対処ですり替えている u GitBucketならどうだろう︖ 5
  6. 認めるべき事実 6 RedmineとGitHub等を Pull Requestも含めた形で 連携する⼿段は、 これまではなかった

  7. 今⽇の発表内容 7 GitBucketならPull Requestを含めて Redmineと連携することが 「技術的には」出来る →実⽤レベルまで開発を進めるには︖ →運⽤⾯の課題は︖

  8. おさらい︓ GitHub等でのIssue/PRベース開発 8 print("Hello world!") print(1+1) ⽇本語化したい︕ Issue#1 対応したよ︕Close #1

    PR#3 print("こんにちは、世界︕") print(1+2) print("こんにちは、世界︕") マージ#4 マージと同時に Issue/PRをクローズ 計算式間違ってる︕ Issue#2 Issue: 開発の起点 PR: 開発の実体 リポジトリ: 開発成果の蓄積 Issue/PR/リポジトリの間での紐づけで 起点〜現状コードまでのトレーサビリティを実現 対応したよ︕Close #1 PR#4 print(1+2) マージ#3 並⾏開発 レビュー CI メリット
  9. GitHubの不満点︓ Issueがシンプルすぎる 9 タイトル 本⽂ 担当者、ラベル プロジェクト マイルストーン Redmineの⾼機能なチケットに置き換えたい︕ Ex.カスタムフィールド・ワークフロー

  10. 連携実現を妨げる課題 俗説 u 「Redmineとgitの相性が悪い」 ⇒×実は全然関係ない︕ 真の課題 u チケット発番ルールの違い u 番号記法の衝突

    u GitHub側を修正できない 10
  11. 連携の真の課題は何か(1) →チケット発番⽅式の違い Redmine GitHub等 ProjA ProjB ProjC #1 #2 #3

    #4 #5 UserA/ProjA UserA/ProjB UserB/ProjA #1 #1 #1 #2 #2 システム全体で 統⼀発番 リポジトリ (プロジェクト) ごとに発番 11 ※IssueとPRは区別せず発番
  12. 連携の真の課題は何か(2) →番号記法の衝突 Redmine GitHub等 ProjA ProjB ProjC #1 #2 #3

    #4 #5 UserA/ProjA #1 #2 12 チケット→Redmine PR→GitHub ⇒番号記法が衝突 ソースコードリポジトリ print("こんにちは") #1対応の 修正 RM#1を 解決する PR#1︖ どっちの#1︖ Wiki 〜〜は#1に記載。 どっちの#1︖
  13. 連携の真の課題は何か(3) →GitHub側を修正できない u github.com / bitbucket.org / gitlab.com ⇒× SaaS

    u GitHub Enterprise ⇒× プロプライエタリ u GitLab@オンプレ ⇒× プラグインで出来ることが限定的 u GitBucket ⇒◎ オープンソース、プラグインの⾃由度が⾼い(本体機能の上書可) 13
  14. Redmine側で対応しようとすると… 〜これまでのアプローチ〜 Redmine GitHub等 ProjA ProjB ProjC #1 #2 #3

    #4 #5 UserA/ProjA UserA/ProjB UserB/ProjA #1 #1 #1 #2 #2 システム全体で 統⼀発番 リポジトリ (プロジェクト) ごとに発番 14 ※IssueとPRは区別せず発番 #2 #1 発番ルールの変更 ⇒根本から変更 GitHub等は 変更できない︕
  15. 今回のアプローチ GitBucket側がRedmine番号に合わせる Redmine GitBucket ProjA ProjB ProjC #1 #2 #3

    #4 #5 UserA/ProjA UserA/ProjB UserB/ProjA #1 #1 #1 #2 #2 システム全体で 統⼀発番 リポジトリ (プロジェクト) ごとに発番 15 ※IssueとPRは区別せず発番 #4 #1 発番ルールの変更 ⇒プラグインで (⼩細⼯)出来る︕ GitBucketなら プラグイン作成可能︕
  16. Redmine-GitBucket連携の実現 実現⽅針 u GitBucket⇔Redmineで相互に通信 u Redmine→GitBucket: Webhook suer/redmine_webhook u GitBucket→Redmine:

    REST API u 設定でRedmineプロジェクト-GitBucketリポジトリ紐づけ u Issue/PRはRedmineで作成し、番号をそろえてGitBucketにコピー u PRを表す専⽤トラッカーを⽤意 u 他はすべてIssueにする u GitBucket側ではIssue/PRを触らない u Redmine側で作成したもののミラーリングに徹する u GitBucketは⿊⼦に徹する(ことを⽬指す) 16 5/2に4.0対応︕ ⇒再検証…
  17. 公開先 u https://github.com/kounoike/gitbucket- redmine-plugin まだまだ作りかけですが… 17

  18. 連携実現 リポジトリ/プロジェクト設定 18 GitBucket側︓Redmine URL/プロジェクト名/API キー Redmine︓Webhook(GitBucketリポジトリ名/トークン)

  19. 連携実現 PR表現⽤トラッカー u 専⽤トラッカー u カスタムフィールド u マージ元ブランチ名 u マージ先ブランチ名

    u 専⽤ワークフロー u マージ u マージ済 19
  20. 連携実現 通常チケットの発⾏ 20 Redmineでチケットの発⾏⇒GitBucketにコピー 番号(&タイトル)を⼀致させる #10 #10

  21. 連携実現 PRの作成 21 GitBucket側でPR作成 #11 #11

  22. 連携の実現 PRのマージ 22 GitBucket側でPRマージ Redmine側のステータスを マージ済に変更 リポジトリ内のソースが マージされる

  23. 23 完成 …とはいかず

  24. TODO/TBD TODO u GitBucket側でIssue/PR操作を防⽌する u JavascriptでUI封鎖︖ u GitBucketプラグインで操作を⽌める⽅法︖ u ForkしたリポジトリからのPRに対応する

    u Fork操作のためにGitBucketに⼊らなければならなくなる︖ or Redmineプラグイン開発︖ u Issue/PRのユーザをRedmine側に合わせる u GitBucket-Redmineユーザマッピング︖ u PR⽤トラッカーなどの設定の⾃動化 TBD u リポジトリビューワはどっちを使うべき︖ u PRの変更⾏へのコメント機能はどうする︖ 24
  25. 開発を進める上での課題 技術⾯以外 (私が)今はRedmineもGitBucketも使っていない u 実運⽤時の課題が想定できない – ご意⾒募集中︕ – お試し利⽤者募集中︕ u

    モチベーションが維持できない – ご感想・ご意⾒・フィードバック募集中︕ – 現在、副業可能な職場です︕ 25