Furyu
[フリュー公式]

Tech Blog

フリュー株式会社の技術ブログです

2018年12月25日

adachi

チーム開発で Epic branch を運用した話

 
🎅Merry Christmas🎄
 

こんにちは。
ピクトリンク事業部 開発部の足立です。

 

とうとう念願の iPhone XSApple 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 となるブランチを作成します。

$ git branch epic/enhancement-news develop
作成したらプッシュしておきましょう。チーム開発ですから。
 

次に「API層の作成」を行うとします。
ここで注意するのが develop ブランチからではなく、Epic branch である epic/enhancement-news から作成することです。

$ git branch feature/add-api epic/enhancement-news

あとは、通常の開発と同様に feature/add-api のブランチで作業を進めるだけです。
 

他の人が作業をする場合も、上記「API層の作成」と同様に epic/enhancement-news から作業用ブランチを作成すればOKです。

$ git branch feature/add-vc epic/enhancement-news

 

イメージ図
epic-branch-create
 

ブランチのマージは?

難しいことはなく、自分自身の親ブランチにマージすれば良いだけです。
PRを出す時に base のブランチを epic/enhancement-news に変更することを忘れないようにしましょう。
 

マージタイミングも基本的にはPRレビューが完了した任意のタイミングで大丈夫です。
他の人がすでにマージしておりコンフリクトが起きるようであれば通常通りコンフリクトは解消してあげてください。
 

イメージ図
epic-branch-merge

 

実際、何が良いの?

これだけを見るとメリットらしいものがイメージしにくいですよね。
実際に運用した時のメリットを挙げてみます。
 

  • PRのマージタイミングを調整できる
  • PRレビューの時の差分を必要最低限にできる
  • 指摘事項(機能テストバグとか、企画からの指摘)を即時対応しやすい
    • 仕様がFIXしていなくても作業を進められる
  • 他の機能開発と混ざらない
  • Epic branch のPRレビューはほぼ不要
  • 作業の終わった感を感じられる
  • Epic branch へのマージタイミングで確認用アプリが配布される
    • Circle CI/Deploygate の設定要
  • Github project のカードとして扱いやすい
     

など、色々挙げられそうです。
その中でも特に「作業の終わった感を感じられる」が意外と大きな功績だと思います。
「長時間の開発」「終わりの見えない開発」といったものほどキツイものはないですよね。
 

「タスクを分担し、どんどんタスクを終わらせる」ことを実感するためだけに Epic branch の運用をしてみるのも良いと思います。
Epic branch をチーム開発はもちろん、ソロ開発でもぜひ導入してみてください!!

 
 

adachi

ピクトリンク事業部 開発部 足立
ピクトリンク のiOS版アプリ開発を担当。Swiftでごりごりと書いています💻


2018年12月6日

adachi

Github project の導入事例

こんにちは。
ピクトリンク事業部の足立です。

ピクトリンクはプリントシール機で撮影した画像データを使ったコミュニケーションツールで、私はそのiOS版のアプリの開発を担当をしてます。

 

この記事は フリュー Advent Calendar 2018 の 12/07(金) の記事になります。
今回はiOSアプリ開発チームでの Github project 導入事例の紹介です。
 

ちなみに今日は私が在籍している京都事業所の忘年会なので楽しみにしています🍻🍷
テーマが 南国気分🏝で ほっこり☺️ リフレッシュ らしいので、夜は南国🏖に行ってきます。

 

Github project

Github が2016/09に開催した GitHub Universe 2016 で発表された新機能の一つです。
タスクをカンバン形式で管理してくれるツールです。

詳しくは About project boards をどうぞ。

 

きっかけ

導入したきっかけとしては、アプリの新機能開発を進める際に、iOSチーム内でタスクを分割し作業を進めることになったタイミングでした。
個人的には何回か使っていたので、せっかくなのでチームとして使ってみたいと思い提案しました。
 
新機能が大規模改修だったため、誰が何を担当していて、関連する Pull request がレビュー中 or マージ済みなのか?などの状況把握を簡単に管理できる状態が必須でした。
チャンスだと思い Github project はとても理想的なツールだと説明しました。
 

チームとして使うことは初めてでしたが、結果から見れば 導入したことは大成功🎉✨ だったと言えそうです。

 

Github project のよかったところ

使い方などの前に、まず良かったところを書かせていただきます😉
 

  • あとで見返したときにどんな対応をしたかが一目でわかる
  • Column が好きなだけ作れる
  • Card は Github Markdown形式で入力可能
  • Card に Pull request や Issue の番号を書くとプレビュー表示
  • Automated の設定だと Pull request や Issue の状態によって自動でカラムが移動される
     

などが挙げられそうです。

 

使い方

Github project の作り方

  1. Github で対象のリポジトリを選び Projects を選ぶ
  2. New Project クリックして新規作成する
    github-projects_toppage

  3. Project board nameDescription に必要な情報を記入

  4. Project template を選ぶ
  5. Create project クリックで完了
    github-projects_new-project

ここで重要なのが Project template を選ぶ です。
 

Automated kanban または Automated kanban with review がチョーおすすめです💕
これを設定しておくことで Pull request を紐付けていると、レビュー状態になった時や、マージされたタイミングで自動でカラムの移動をしてくれます。
動かし忘れなどもないので、とても便利でしたね。

Column / Card の使い方

Project を作った後は、使うだけです。
使い方も簡単でテンプレートで出来上がったものをそのまま使うもよし、必要な Column を追加しても良いです。
最近使用した例としては以下のような構成にしました。
 

  • Bug: 開発中に見つけたバグのタスク
  • Enhancement: 機能開発するタスク
  • Refactoring: 開発中に見つけたリファクタしたいタスク
  • In progress: 作業中タスクや Pull requestカード
  • Done: 作業が終わったタスクやマージされた Pull requestカード
     

複数人で作業していても(ほぼ)リアルタイムで同期されるので安心です。
他の人が動かしているのを見てちょっと感動したり・・・😂✨
 

Card は Markdown 形式で記述できるのも良いです。
1タスク1カードにするのがおすすめです。
 

全てが Github の中で管理されているので Card に Pull request や Issue の番号(#1234)と書くと参照情報としてプレビューもしてくれるのとても便利でした。

 

まとめ

Github project の導入事例というか使い方になってしまいましたが、簡単にまとめてみました。
はじめに書いた よかったところ に挙げているようにとても使いやすく、これからのチーム開発で活躍してくれそうなツールでした。
 

この記事では書けませんでしたが iOS開発チームでは大規模な機能開発の時は Epic branch 運用 も取り入れているのですが Github project とはとても相性も良い感じでした。
 

Epic branch 運用 については チーム開発で Epic branch を運用した話 の記事を見ていただければと思います。
 
 

みなさんもぜひ Github project を導入してチーム開発の効率をあげてみませんか?