featureブランチを運用する

[keiji]

その機能リクエストは何らかの問題に関連しますか / Is your feature request related to a problem?

大きめの機能を追加するときに一つのPull Reqeustで進めると、PR自体の生存期間が長くなりがちです。

レビューを重ねてコードコメントが多くなると見通しも悪くなり、後からコントリビューターが見たときに経緯を確認する負荷が大きくなります。もちろん、Pull Reqeustのオーナーもレビュアーも、変更が重なるにつれて対応負荷が上がります。

解決策についてお書きください / Describe the solution you'd like

一定の規模以上（定義は難しい）でcocoaリポジトリにfeatureブランチを作って、そこで育てていく体制にしたいとぼくは考えています。

たとえば、現在Pull Requestが出ている中で変更が大きいなと感じている代表格に「ログの改善」と「デバッグページ」があります。
この二つに関しては次のブランチを用意して、そこにPull Requestを提出することで小さめの変更として取り込んでいくことを目指したいと考えています。

• feature/log_improvement 「ログ出力時に毎回ファイルを開いている」の修正 #67
• feature/debug DebugPage の実装 #178 Debug_Mockの機能拡張（高リスク接触、陽性登録） #191

これは重要な点ですが、 featureブランチになること＝将来の取り込み確約ではありません。 その上で、この方法だとcocoaのリポジトリにブランチがあるので、元になったPull Requestオーナー以外がfeatureブランチに対してPull Requestを出す機会が増えて、開発が加速して、結果として取り込みの確度が上がることが期待できます。

最終的な取り込みについてですが、featureブランチがある程度育ったところで、あらためてdevelopブランチ宛てにPull Reqeustを出す流れです。developに対するPull Reqeustが出たあとで開発チームがレビューすればいいので、開発チームの負荷には影響しないと考えています。

その他 / Additional context

今後「全ページのデザインを微調整する」「コードを少しずつNull安全に書き換えていく」のような作業でfeatureブランチが役立ちそうです。

[b-wind]

feature ブランチを利用するかはさておき、デバックページについては feature ブランチに用意する意味合いは少ないかなと言う印象を受けます。

現状のPR（ #178 #191 ）がそこそこ大きくなっている事実です。なのでPRの分割を提案します。

分割例）

1. デバッグページ自体のひな形とナビゲーションを用意する（デバッグページの中身は無し）
2. （主に）静的な情報閲覧機能を追加する
3. 動的に変わりうる情報の閲覧機能を追加する
4. 情報操作系のボタンと機能を追加する（機能毎にPRを分ける）
5. 追加したい機能が出る毎にPRを作成する

1, 2 まで程度であればレビューの量も少なく、develop への取り込みもスムーズに行われるのではと期待しています。
最低限の機能だけでも早く使える方が嬉しいと言う事もあります。

デバッグページに取り込みたい機能、色々あると思います。「完成」を待ってしまうと超巨大なPRが出来るのと変わらないコストがかかるのではと懸念します。

開発チームの負担に関しては、「小さな機能が小まめに追加されるのと、巨大な機能の塊が一気に追加されるのとどちらが良いか」を当事者に聞くしか無いかなとは思います。
自分は前者の方が楽と感じますが、開発チームの都合は分からないので後者の方が良いのかも知れません。

もちろん実際に開発する側として、feature ブランチが有った方がやりやすいと言う意見も有るでしょう。
その場合はやりやすい方をとって貰えれば良いかと。

参考： https://techracho.bpsinc.jp/hachi8833/2018_02_07/51095

[keiji]

ぼくは実際にそれなりの大きさのPull Requestを作る側でもあります。featureブランチについては、そういう立場からの提案でもあります。

PRの分割については、分割の依頼と対応でオーバーヘッドがあります。開発チームは計画に則ってレビューするPull Requestを決めます。レビューには当然ながら実際に動作させてのテストも含まれるので、小さな変更でもオーバーヘッドが積み重なるので効率が下がってしまいます。

なのでfeatureブランチをやります。

[b-wind]

提案じゃ無くて決定事項だったんですね。これは失礼しました。

特に反対する理由は無いです。

[b-wind]

失礼ついでという事で確認させて欲しいのですが、今後 develop ブランチには（時期はともかく）リリースされる物しか取り込まれないし、PR が取り込まれる場合でも開発チームのレビューが必須となると言う理解で良いのでしょうか。

あと、ずっと疑問でしたが cocoa-dev が開発チームのアカウントという事で合っていますか？

[b-wind]

どうしても気になってしまうので一点だけ確認を。
例えば、 feature/log_improvement ブランチを作成、運用する事を考えたとき、このブランチに取り込むPRはログ機能に関する物に限るという事で良いでしょうか？

特に対象の feature ブランチが作成されていない問題へのPRは develop に対するPRを作成する。と言う運用だと思うのですが間違いありませんか？

もちろん例外は発生すると思うので、「原則そうなるはず」というスタンスで構いません。

[keiji]

featureブランチのCIが動き始めたので、本Issueはcloseします。

いろいろ疑問等あるかもしれませんが、あまりケース別に厳密に定めると言うことはしていません。
Pull Requestを送るにあたってこんなfeatureブランチが欲しいのだけど。みたいな提案は歓迎します。PRの送り先をfeatureブランチするか、developにするかは、判断が難しければご相談いただければと思います。またPRいただいた後に話し合って調整することもできます。