adachi
目次
🎅Merry Christmas🎄
こんにちは。
ピクトリンク事業部 開発部の足立です。
とうとう念願の iPhone XS と Apple Watch SERIES 4 が手元に届き快適なガジェット生活を満喫しています。
Apple Watch すごくて第1世代の時はWorkoutのWalkingを使っている状態で電車待っててもそのまま計測を続けていたんですが、Apple Watch SERIES 4 だと「ねぇ？Workout終わる？」的な感じで通知してくれるんです。可愛いやつっすよね。
では、本題に入りたいと思います。
この記事は フリュー Advent Calendar 2018 の 12/25(火) の記事になります。
今回はピクトリンクアプリの開発で導入した Epic branch 運用 のお話です。
はじめに
みなさんはチーム開発をする際、どのように作業を進めていますか？
1人で担当できそうな機能開発であればソロプログラミング、少し大きめの機能開発をペアプログラミングなどしている感じでしょうか？
これらの機能開発では基本的にブランチは1本あれば十分ですよね。
では、もっと大きな機能をチーム内の複数人で開発するとなった場合、当然ですがブランチ1本を共有して作業するなんてほぼ無理ですよね。
というか、Git使っててそんな運用するなんてちょっと考えものですよね。
そこで Epic branch を導入する
はじめに
大きな機能の中にいくつものサブ機能があり、そのサブ機能を複数人で開発する。
例えばこんな感じ。
ニュース機能
-
画面周り作成
- プロフィール部分
- タイムライン部分
- アルバム一覧部分
- お気に入り一覧部分
-
サービス層作成
-
API層の作成
-
画面とサービス層つなぎこみ
-
ログ実装
-
デザイン調整
-
リファクタリング
-
機能テストのバグ対応
…..etc
ざっくりと例を示すためにタスクを大きく分けていますが、実際に作業する場合はもっと細かい粒度にしても良いと思います。
なぜかというと Github project と併用することで、 Epic branch での開発は活きてきます。
詳しくは Github project の導入事例 を見てください。
ブランチを用意する
まずは develop ブランチから Epic branch となるブランチを作成します。
次に「API層の作成」を行うとします。
ここで注意するのが develop ブランチからではなく、Epic branch である epic/enhancement-news から作成することです。
あとは、通常の開発と同様に feature/add-api のブランチで作業を進めるだけです。
他の人が作業をする場合も、上記「API層の作成」と同様に epic/enhancement-news から作業用ブランチを作成すればOKです。
イメージ図
ブランチのマージは？
難しいことはなく、自分自身の親ブランチにマージすれば良いだけです。
PRを出す時に base のブランチを epic/enhancement-news に変更することを忘れないようにしましょう。
マージタイミングも基本的にはPRレビューが完了した任意のタイミングで大丈夫です。
他の人がすでにマージしておりコンフリクトが起きるようであれば通常通りコンフリクトは解消してあげてください。
イメージ図
実際、何が良いの？
これだけを見るとメリットらしいものがイメージしにくいですよね。
実際に運用した時のメリットを挙げてみます。
-
PRのマージタイミングを調整できる
-
PRレビューの時の差分を必要最低限にできる
-
指摘事項（機能テストバグとか、企画からの指摘）を即時対応しやすい
- 仕様がFIXしていなくても作業を進められる
-
他の機能開発と混ざらない
-
Epic branch のPRレビューはほぼ不要
-
作業の終わった感を感じられる
-
Epic branch へのマージタイミングで確認用アプリが配布される
- Circle CI/Deploygate の設定要
-
Github project のカードとして扱いやすい
など、色々挙げられそうです。
その中でも特に「作業の終わった感を感じられる」が意外と大きな功績だと思います。
「長時間の開発」「終わりの見えない開発」といったものほどキツイものはないですよね。
「タスクを分担し、どんどんタスクを終わらせる」ことを実感するためだけに Epic branch の運用をしてみるのも良いと思います。
Epic branch をチーム開発はもちろん、ソロ開発でもぜひ導入してみてください！！