masterを基本とするって話とGithub flowがいいじゃんって話 個人メモ

Takafumi Ikeda @ikeike443

@kyon_mm もしかして、作業ブランチを全メンバーで共有する前提でフローを設計されてますか？

きょん＠アジャイルコーチ、システムアーキテクト @kyon_mm

@ikeike443 PRでレビューされてくときにスキルアップという観点で貢献できるの、死なない程度にしかなりにくく、本当にあるべき設計をうまく伝えにくいなというのが私の感覚です。 あと、integrated workflowとgateway checkin使うとか。

Takafumi Ikeda @ikeike443

@kyon_mm というよりも、マスターに直接プッシュのスタイルだとテストもレビューも差し込むタイミングが作れなくないですか？　すくなくとも保証ができない。

きょん＠アジャイルコーチ、システムアーキテクト @kyon_mm

@ikeike443 まずはどうあるべきなのかをかんがえたときに、PRが必要ないくらいのスキルとプロセスだとおもっています。そこがちがっているならごめんなさい。ちょっとくわしくおしえてほしいです。で、できないときにPRつかうのあるよねっていうのはわかります。

きょん＠アジャイルコーチ、システムアーキテクト @kyon_mm

@ikeike443 なんかいかにチームのスキルをあげるかっていうアプローチの違いな気がしてきました。僕は常に統合して常にテストして常にレビューしていくっていうのがいいとおもっています。それを強制するためにブランチをへらして時には失敗してきづきたい。

Takafumi Ikeda @ikeike443

@kyon_mm プルリクエストが必要ないくらいのスキルとプロセスというのが分からないです。すみません。 マスター一本でやるメリットが見えてないので、そこがわからないとなんとも言えないです。 プルリクエストを使わない理由が見えないです。。

きょん＠アジャイルコーチ、システムアーキテクト @kyon_mm

@ikeike443 それでもできるだけ安全にするためのデプロイパイプライン、integrated workflow、ゲートウェイチェックイン、TCR、Limboだとおもっています。

Takafumi Ikeda @ikeike443

@kyon_mm そのために、プルリクエストを使うべきなのですが。。 プルリクエストに対する誤解があるのかもしれないです。githubなどの機能で担保するべきところを手作業でやられてるように聞こえてます。（誤解だと思いますが、今のところそう聞こえてしまうという意味です

きょん＠アジャイルコーチ、システムアーキテクト @kyon_mm

@ikeike443 PRをつかうとおきるデメリットをへらしたいです。 twitter.com/kyon_mm/status…

きょん＠アジャイルコーチ、システムアーキテクト @kyon_mm

@ikeike443 うーん。PRをすることって作業を並行したままで、こういったことを保証できるっていうのがメリットだとおもっているんですけど、あっていますか?

Takafumi Ikeda @ikeike443

@kyon_mm 常に統合して、常にレビュー、常にテストをするためには、プルリクエストを使うのがかんたん、というのが私の話です。マスターに直接プッシュしてしまうと、これらが全てできない、という話です。 プルリクエストにCIを組み、常にマスターと統合させてテストすれば、並行作業しつつ常に結合できます

Takafumi Ikeda @ikeike443

@kyon_mm きょんさんが知らないはずはないと思いますが、プルリクエストに対してCIを組むのを前提にしてます。

きょん＠アジャイルコーチ、システムアーキテクト @kyon_mm

@ikeike443 あ、はい。それはそのとおりです。 ただ、わたしはチーム内でビデオ通話なりペアプロするなりで相談するほうがもっとはやいとおもっています。 コンテキストをつたえる、よみとく、フィードバックするというのを会話と同等以上でPRでやるためのルールをわたしがわかっていないという課題があります。

きょん＠アジャイルコーチ、システムアーキテクト @kyon_mm

@ikeike443 すいません。ちょっと離脱します。

Takafumi Ikeda @ikeike443

@kyon_mm そこはまったく反対意見はないです。直接の対話を重視することと、プルリクエストを使うことは同時に成立しますし、マスターに直接プッシュすることを推奨する根拠にはならない、というのが僕の意見です。

Ryutaro YOSHIBA @ryuzee

少人数チームで全員の力量がはっきりしてるときは直接master更新しまくるなー。 It dependsな話な気がする

Takafumi Ikeda @ikeike443

@ryuzee 一人とか二人ならそうでしょうねー。あとはテストするまでもないような単純なスクリプトを作ってるとか。 それでもプルリクエストを作っておいたほうがあとで作業ログとして振り返るときに便利なのでオススメはしますけどね。

Ryutaro YOSHIBA @ryuzee

@ikeike443 まぁこの手の話って「自分のコンテキストではこうしている」っていうのと「みんなそうしたらいい」っていうのはイコールにならないので、大多数の人はエクストリームなやり方する前に、一般的なやり方すればいいと思う次第

きょん＠アジャイルコーチ、システムアーキテクト @kyon_mm

@ikeike443 僕が言いたかったのは対話がなされるまでのリードタイムを短くしたいということみたいです。で、masterに寄せると対話せざるを得ない。対話されてないPRの滞留時間が嫌とかですかね。PRにすると対話のフォースが弱まるというのが経験でした。同時に成立させるための上手いルールありますかね？

wtnabe, yet another yak shaver @wtnabe

@ryuzee @ikeike443 1人で立ち上げてる時はある程度の形になるまで型は無視してやっちゃいますね。で、継続しそうなものはlintとかtestとか準備し終わるまでやってから「手離れ=リリース」って感じです。動けばいいやつはドキュメントまで。現在の自分は他人じゃないけど未来の自分は他人、という線引きです。

wtnabe, yet another yak shaver @wtnabe

masterブランチ一本て表現は誤解を生みやすい気がするなぁ。複数releaseブランチをWIPで抱えないという意味ならいいけど、気軽にブランチ切れるのがDVCSのいいところなのにmasterしか使っちゃいけないの？って思っちゃいそう。

wtnabe, yet another yak shaver @wtnabe

Subversion文化が根強いところにはmaster一本の方がスムーズかもしれない。merge権限とかそういう運用にうるさいところだとごちゃごちゃ言わないでmasterだけ使っとけ、の方がまずは早そう。自分だったらお試しブランチを自由に切れないのは息苦しくてやってられないけど。

Takafumi Ikeda @ikeike443

@kyon_mm Master直接プッシュを容認してしまうと、むしろ対話が生まれないかもしれないので（メンバーのスキルが高くないと、対話が必要だという気付きに至らない気がします）、設定で直接プッシュを禁止して、PRとレビューを必須にした方が、対話が生まれやすいかと思います。

きょん＠アジャイルコーチ、システムアーキテクト @kyon_mm

@ikeike443 なるほど！！そこが違いですね！僕はチームビルディングへのコミットありきでの話をしていて、そうじゃないならPRにすべき。そのとおりだと思います！