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でごりごりと書いています💻


2015年01月8日

kunihira

GitBucketでコードレビュー

GitBucketGit

明けましておめでとうございます。国平です。 久々の投稿となってしまいましたが、今年も元気に開発して、たまったノウハウをこのブログに投稿していこうと思います。

今回は、以前ご紹介したGitBucketに、みんなが渇望していた あの機能 が追加されて、嬉しさのあまりブログ記事にしてしまいました。

GitBucketのおさらい

  • GitBucketは@takezoen さんが開発してOSSとして公開されているGitHubクローンのWebアプリです
  • Scalaで書かれていて、単体のjarでも実行できるので、お試し導入が非常にしやすいというメリットがあります
  • GitHubのクローンなので、GitHubでできることは大体できます
  • ただ、version2.6までは、コミットに対してコメントする機能がありませんでした

というのが、GitBucketの主な特徴でした。 なので、社内で利用するのに最適なGitHubクローンと言えます。

ついに登場したコメント機能

つい先日、2014年12月29日にGitBucketの最新バージョン2.7がリリースされました。 @takezoenさんのブログでも目玉機能として紹介されていますが、 ついに、コミットおよびdiffへコメントを付与する機能が追加されました。

これによって、ついにGitBucket上でプルリクエストをコードレビューしてマージすることができるようになりました。

さっそく使ってみる

早速、GitBucket内のリポジトリで管理しているドキュメントをちょっと修正してプルリクエストを出してみました。 ご覧のとおりプルリクエストの画面にコメントが一覧表示されています。

PullRequest


このうち、一番下のコメントは、

InLineComment

コミットのDiff表示内にインラインで投稿したコメントでしたー


ということで、完璧です。完璧すぎます。

まとめ

というわけで、ついにGitBucketにコメント機能が追加されました。 これで、社内OSSが活性化すること間違いなしです。(ほんとか?)

GitBucketを導入されている方は早急なアップデートを、導入検討中の方は早急な導入をオススメします。 特に、既にGitBucketを導入されている方は、 MarkDownに関するセキュリティ問題の修正が含まれているそうなので、早めにアップデートした方が良さそうです。

今回のバージョンのその他の内容については、Issueの一覧にまとまっています。

おまけ

コメント機能の中身

以前は、GitBucketにコメント機能を追加するには、かなりJavaScriptでがんばる感じになるんだろうと思っていました。 実際、@takezoenさんも2.7のリリース記事内で

と、jsについて言及されています。

しかし、コメント機能のコミットを見ると、意外とJavaScriptの変更は少なかったです。

GitBucketインストールのAnsible化

インラインコメントの画像に書いてますが、GitBucketのインストール/アップデートをPlaybookにまとめようと思います。 最近、ScalaよりAnsibleのPlaybookを書いてる時間の方が多いので、勢いに任せてやってしまって、いずれここでご報告しようと思います。 (ひょっとしたらもう誰か公開されてるかもしれませんが、勉強のため自作します)

関連記事


2014年06月10日

kunihira

GitBucketで社内OSSしませんか

GitBucketGit

皆様こんにちは。
季節の変わり目で夏風邪を引いてしまった国平です。
暑いからといって布団もかけずに扇風機つけっぱなしで寝て、 明け方に体を冷やしてしまいました。
皆様もご注意ください。

さて、今回は社内勉強会でGitBucketについてお話させていただいたので、 その内容を投稿させていただきます。

発表の目的

社内サーバにGitBucketを導入してしばらく一人で使っていたのですが、 問題なく利用できそうで、せっかくPullRequestやIssueなどの機能があるので、 もっと大勢で使いたいと思い、周知のために発表しました。

GitBucketとは

GitBucket@takezoen さんが開発してOSSとして公開されているGitHubクローンのWebアプリです。 Scalaで書かれていて、単体のjarでも実行できるので、お試し導入が非常にしやすいというメリットがあります。

もともと、お手軽に導入できるツールだったのですが、ここ最近、ブログやQiitaなどに記事が増えてきていて、情報も充実してきています。

参考

導入の経緯

フリューでは元々は普段の業務にSVNサーバを社内に立てて使っていたのですが、 2年ほど前からGitHubを使うようになりました。

それで社内にも自由に使えるGitリポジトリをホスティングしたかったのですが、 WindowsのGitクライアントであるmsysGitがgitプロトコルに未対応だったので、 Webフロントエンドを持っていてhttpプロトコルで利用できるGitBucketを導入しました。

勉強会の内容

要約すると、

  1. Gitいいよ、Git
  2. SocialCodingいいよ、SocialCoding
  3. でも、GitHubもBitBucketもちょっと社内ツールとか書き貯めるには制限が…
  4. そこでGitBucket!!
  5. いろいろリポジトリ作って上げてるので、プルリクください!

という感じです。

発表資料

発表資料はこちら↓

GitBucketで社内OSSしませんか? from Kiyotaka Kunihira

発表後の質疑

発表後にもらった質疑とその回答(加筆あり)をまとめます。

Q. GitHubでできてGitBucketでできないことはあるか?

A. 何点かあって、まずコミットに対してコメントをするレビュー機能が無いです。 これは、発表資料中にもあるソーシャルコーディングの機能の一つなのですが、Issueは上がっていて、対応予定はあるみたいです。

次に、コミットグラフの機能が無いです。これについてもIssueは上がっています。 とりあえず、下記のコマンドでCUI上でもグラフ表示することもできるので、問題にはならないと思います。

あと、GitHubはCircleCIとかいろいろ外部サービスと連携できる機能がありますが、 GitBucketはPushされたタイミングで、特定のURLを叩くだけになります。 とはいえ、社内ユースでJenkinsと連動させるなら十分だと思います。

Q. 同様のOSSにGitLabがあるけど、そっちは使わないの?

A. 昔、GitLabも検討したことがありますが、インストールが面倒で投げ出しました。 今は、rpmが公開されて導入が簡単になったみたいですが、すでにGitBucketインストール済みなので、試してないです。 あと、個人的にScalaを応援する意味でGitLab押しです。

Q. 会社のプロキシのせいでGit使いづらいんだけど…

A. こちらの方が素晴らしいツールを開発してくれてます。 git-proxy-clone Clone時はコレを使うと便利です。

すでにローカルにgitリポジトリがある場合は、 .git/config を修正したらOKです。 プロキシ経由したくない場合、下記みたいにしとけばプロキシを通らずにすみます。

プロキシを経由させたい場合は、Qiita / GitでProxyの設定を参考に、 local の設定を変更してもらったらいいと思います。

まとめ

GitBucketは導入が簡単で、社内で利用するのに最適なGitHubクローンです。 これを利用して、社内ツールの開発を活性化させて、快適な仕事環境を整えましょう。