Slide 1

Slide 1 text

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

Slide 2

Slide 2 text

⾃⼰紹介 鴻池(こうのいけ) 祐輔 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

Slide 3

Slide 3 text

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

Slide 4

Slide 4 text

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

Slide 5

Slide 5 text

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

Slide 6

Slide 6 text

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

Slide 7

Slide 7 text

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

Slide 8

Slide 8 text

おさらい︓ 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 メリット

Slide 9

Slide 9 text

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

Slide 10

Slide 10 text

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

Slide 11

Slide 11 text

連携の真の課題は何か(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は区別せず発番

Slide 12

Slide 12 text

連携の真の課題は何か(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︖

Slide 13

Slide 13 text

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

Slide 14

Slide 14 text

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

Slide 15

Slide 15 text

今回のアプローチ 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なら プラグイン作成可能︕

Slide 16

Slide 16 text

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

Slide 17

Slide 17 text

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

Slide 18

Slide 18 text

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

Slide 19

Slide 19 text

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

Slide 20

Slide 20 text

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

Slide 21

Slide 21 text

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

Slide 22

Slide 22 text

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

Slide 23

Slide 23 text

23 完成 …とはいかず

Slide 24

Slide 24 text

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

Slide 25

Slide 25 text

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