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

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

Transcript

1. 2019/5/18 redmine.tokyo 第16回勉強会
   鴻池 祐輔
   Redmine + GitBucket で実現する
   「Redmine でプルリクエスト」
   第14回パネルディスカッションへのアンサーとして
   1
   

   View Slide

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
   

   View Slide

3. 知っていますか︖
   uRedmine
   uGitHub
   uGitBucket (×BitBucket)
   3
   

   View Slide

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
   

   View Slide

5. redmine.tokyo#14
   パネルディスカッション
   「GitとRedmineをどのように連携するのが効果的か」
   【使⽤状況】
   u 楠川さん
   u 「GitLabと連携」といってもgitリポジトリ作成/管理ツールとしてしか使ってない
   u 川端さん
   u GitHub利⽤・Issue管理とPR管理を分離して使っている
   【論点＝そのまま結論︖】
   u 「RedmineとGitHub/GitLabは住み分け」
   【所感】
   u 技術的に出来ていないことを運⽤⾯での対処ですり替えている
   u GitBucketならどうだろう︖
   5
   

   View Slide

6. 認めるべき事実
   6
   RedmineとGitHub等を
   Pull Requestも含めた形で
   連携する⼿段は、
   これまではなかった
   

   View Slide

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

   View Slide

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
   メリット
   

   View Slide

9. GitHubの不満点︓
   Issueがシンプルすぎる
   9
   タイトル
   本⽂
   担当者、ラベル
   プロジェクト
   マイルストーン
   Redmineの⾼機能なチケットに置き換えたい︕
   Ex.カスタムフィールド・ワークフロー
   

   View Slide

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

    View Slide

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は区別せず発番
    

    View Slide

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︖
    

    View Slide

13. 連携の真の課題は何か(3)
    →GitHub側を修正できない
    u github.com / bitbucket.org / gitlab.com
    ⇒× SaaS
    u GitHub Enterprise
    ⇒× プロプライエタリ
    u GitLab@オンプレ
    ⇒× プラグインで出来ることが限定的
    u GitBucket
    ⇒◎ オープンソース、プラグインの⾃由度が⾼い（本体機能の上書可）
    13
    

    View Slide

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等は
    変更できない︕
    

    View Slide

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なら
    プラグイン作成可能︕
    

    View Slide

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対応︕
    ⇒再検証…
    

    View Slide

17. 公開先
    u https://github.com/kounoike/gitbucket-
    redmine-plugin
    まだまだ作りかけですが…
    17
    

    View Slide

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

    View Slide

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

    View Slide

20. 連携実現
    通常チケットの発⾏
    20
    Redmineでチケットの発⾏⇒GitBucketにコピー
    番号（＆タイトル）を⼀致させる
    #10 #10
    

    View Slide

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

    View Slide

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

    View Slide

23. 23
    完成
    …とはいかず
    

    View Slide

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
    

    View Slide

25. 開発を進める上での課題
    技術⾯以外
    （私が）今はRedmineもGitBucketも使っていない
    u 実運⽤時の課題が想定できない
    – ご意⾒募集中︕
    – お試し利⽤者募集中︕
    u モチベーションが維持できない
    – ご感想・ご意⾒・フィードバック募集中︕
    – 現在、副業可能な職場です︕
    25
    

    View Slide