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

きゆあもねあど @curelemonade2

@kyon_mm マスター直pushだとCI/CDはどうするのですか？

Masayuki Takahashi @masayuki

うちも PR 使ってるけど、差分を見ながら口頭でやり取りすることが多くなり、レビューコメントをつけることはかなり減った。確かに同じ時間・場所で仕事をしているので、実質レビューのタイミングだけが問題なのかも。

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

@curelemonade2 masterとfeatureブランチでCI/CDの何か大きい違いがあるんですかね？（どこが心配かちょっと具体的なところがわかってないです。

FUJI Goro @__gfx__

はー、そういう考え方があるのか…。 twitter.com/kyon_mm/status…

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

ちなみに、私はGitにおいてこの7年間でmasterブランチ一本を常に貫いてます。これは研修でも常にそう。（個々の対応は教えるとしても）

2019-10-25 21:56:16

きゆあもねあど @curelemonade2

@kyon_mm featureブランチがあればCIが通らないコードをfeatureブランチにpushした時にそれをmasterにpushせずに済みますが、master直pushだとmasterブランチ反映前にCIが通っているか確認するすべが無いように思いました。

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

@curelemonade2 なるほど！ integrated workflowとの組み合わせで実現してます。

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

@__gfx__ イケてないんですかねぇ。

ぷらむ @plum_shiga

きょんさんの master 党、なるほどみがある

FUJI Goro @__gfx__

@kyon_mm いや、それがよくわかりません。ぼくは業務ではほとんどgit/github、それもgithub flowとその亜種しか使ったことがなくて、他のやり方を知らないだけかもしれません

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

@__gfx__ なるほど。。。自分この一連でわかったのは、研修とかでは様々なコンテキストを話しているから通じるのであり、Twitterみたいなものではうまく伝えるスキルが不足しているんだなって思いました。Gihub flowも使うには使うんですけどねぇ。

きゆあもねあど @curelemonade2

@kyon_mm 返信ありがとうございますm(_ _)m 知らないソリューションなので調べてみます

FUJI Goro @__gfx__

@kyon_mm ぼくも正直なところまだ何がなんだかさっぱりです。興味深く思う人は多いと思うのでまとまった資料があれば見てみたいです！

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

@curelemonade2 pull専用とpush専用のリポジトリにわける感じです。push専用からpull専用へのpushはゲートウェイチェックインとしてCIが行う組み合わせになります。

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

@__gfx__ ですよねー。この一連のスレッドでの各々の主張が何を指しているのかがまとまってるだけでもまずはいいのかもですね。。。

methane @methane

同じ理由で、私がメンテしてるものはSquash&merge使ってmasterの履歴を直列化しています。 twitter.com/kyon_mm/status…

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

一連の話でわかったのは、モブプログラミングは全然広まってないのではとかですかね。。。（私は前提にしていないけども。。。

非実在naka aki @naka_aki_spl

@kyon_mm @curelemonade2 あ。「プル」リクと「マージ」リクの違いみたいなものですね。ブランチじゃなくリポジトリで分ける方式。 (俺が大昔の某で初期にやった(＆やらせた)のと似てるかも。テスト鯖にpushして調べてOKなら本番にpush。そいやアレもブランチろくに使ってなかったgkbr)

きゆあもねあど @curelemonade2

@kyon_mm マジョリティなブランチを分ける戦略ではなく、マイノリティなリポジトリを分かる戦略を取っているのでしょうか？気になります

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

@curelemonade2 まず、integrated workflowをつかうかどうかはどれくらいの機械的なルールを敷きたいかなので、べつになくてもいいです。 そもそもでいうと、機械がやらなくても大丈夫なチームになるというのがいいとおもっていて、そのときのアプローチにブランチorリポジトリでわけるというのがある。

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

@curelemonade2 件のはなしはどうやって保証するかはメインではなくて、いつ設計、実装、テストについて会話するのかというのが肝であるという話でした。 で、そのうえで技術的にゲートウェイをどうこうするとしては、master一本の場合はintegrated workflowで解決できますよっていう話でした。

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

@curelemonade2 integrated workflowがマイノリティといわれればそのとおりです。というよりはすごく昔からある手法なんですが、環境構築は面倒なのでやっているチームはすくなくて、そこにPRがでてきたので、そっちのほうが手軽だしドキュメント性もあるので受け入れられていると認識しています。