GitHub Kaigi参加レポート#1(はてなブログの開発フローと Github @shiba_yu36)
本日(6/1)、渋谷のサイバーエージェントさんで開催されたGitHub会議に参加してきました。
GitHub会議はnaoyaさんが中心となって企画したGitHubのユーザイベントです。タイムスケジュールはこんな感じ。休日のイベントとしてはかなり長めでした。
スケジュール
本編
- Hello, Github Kaigi @naoya
- GitHub実践入門 ─ Pull Request による開発の変革 @hirocaster
- はてなブログチームの開発フローとGitHub @shibayu36
- OSS と GitHub @amatsuda
- How Github Works @cobyism
- GitHubで 雑誌・書籍を作る @inao
- Atom, the Programmable Text Editor @nathansobo
- 入門書には載ってない Git & GitHub Tips @yuku-t
- Rebuild.fm Live @miyagawa
LT
- 新たなるソーシャルコーディング時代の幕開け @kenchan
- Git・Githubに隠された便利な機能 @sota0805
- GitHub@Ameba @pnsk
- GitHubで行うreproducible research @uribo
- Using GitHub to get a better job @pwim
- Hubot レビュアーおみくじ @sakatam
- 本当は怖くない!デザイナーがGitを大好きになった♡5つの理由 @yunico-jp
- pplog.net の作り方( ˘ω˘) @taea
rebuild.fmの生放送とかもあり、GitHubの中の人によるAtomエディタの発表とかもあって盛りだくさんの内容で、メモが取れてないところがあるので今回は参加レポートとして印象に残った id:shiba_yu36 さんの発表を書きたいと思います。
はてなブログチームの開発フローとGitHub
発表のスライドはこちら。
はてなブログチームについて
hatena blogチーム
- 5 Engineers / 2 Designer で構成
- 170 Pull Request / month
- 1280 Commit / month
- 45 Release / month
ソースコードはGHEで管理・運用しており、開発速度は保てている
開発フロー
hatena blogの開発フロー
- issue登録・アサイン
- issueに対応するbranch作成
- 開発・レビュー・merge
- mergeがたまったらリリース
ブランチ戦略(永続的に存在しているのは2ライン)
- git flowの簡易版で回している
- master
- 本番環境と同一
- developブランチからリリースするタイミングでmerge
- develop
- 開発ブランチでmasterより先行
- リリース可能な状態になったものをmerge
- feature branch
- 機能毎の開発ブランチ
各フェーズで発生した問題と解決策
タスク管理
以前のタスク管理
問題点-1
- 両方のツールを見ないといけない
- コードとの連携も実施していたが、そんなに便利ではなかった
- 結果、開発者の効率が上がらない問題が発生
解決策-1
問題点-2
- issuesだけでは優先度・納期が見えづらい
- issuesだけでは進行中のタスクを俯瞰できない
- 開発者の効率は良くなったが、マネージャにとっては管理しづらい問題が発生
解決策-2
解決策-2(issues)
- すべてのタスクを入れる
- 社内の誰でも(非エンジニアも)追加してよい
- 追加されたタスクは毎朝検討する
解決策-2(カンバン)
- Issuesの中で重要なものだけをマネージャが選んで掲載
- 重要なものしか掲載しない
結果
- 重要なものは把握しつつ、開発効率重視のスタイルをとった
- スクラムまでいかないゆるいタスク管理でうまく運用できるようになった
レビュー
以前のレビュー
- Pull Requestは開発者がレビュアーを指名して個別にお願いしていた
- レビューするときは、時間のあるときにPull Requestの一覧から選んでレビュー
発生した問題
- Pull Requestの状態がわからない(レビュー依頼中?修正中?WIP?)
- レビューが消化されずに貯まる
- ベテランだけがレビューし続けるという属人的なレビュー体制になっていた
解決案
結果
- レビュー状態ラベルによって、「いまレビューをしなければいけないもの」が見える化できた
- レビュータイムによって、みんながコードレビューをする文化が醸成できた
リリース
以前のリリースの流れ
- マネージャにリリースして良いかを確認
- 検証環境で最終確認(各自)
- デプロイコマンド(手動)でデプロイ(リリース)
- (そもそも、自動化し切れない部分があった)
発生した問題
- マネージャに確認せずにリリースしてしまった(自動化していない手動作業部分でのオペミス)
- 新人が入社したときに手動作業部分をしっかり説明しないと、1人でリリースできない(メンバーが増えるたびに同じことを繰り返し説明するN度手間)
解決策
- リリース用のPull Requestに手順書をまとめる(リリースするためのPull Requestを作る)
- Titleに概要がまとまっている
- ContentにRedmineのチケット番号と担当者を記述
- Contentに検証用のチェックボックスを配置(WIP)
- mentionつきなので、レビュアーや開発担当者にメールが飛ぶ
- レビュアーは確認したらPull Requestにチェックを入れる
- このPull Requestはコマンド一発で自動生成している(GitHubで公開)
- https://github.com/motemen/git-pr-release
GitHubとリリース
- デプロイ作業はできるだけ自動化する
- すべて自動化は難しい
- Pull Requestをうまく使って手順をサポート
まとめ
- タスク管理
- GitHub Issues
- カンバン
- レビュー
- レビュータイム
- レビューラベル
- デプロイ
- リリース内容をPull Requestにまとめる
- ワークフロー
- 改善をし続けることが大事
- ベストな解ではない(はてなブログチームはこうしてるよ、というだけ)
- 自分たちのスタイルに合ったフローを少しづつ作っていくことが大切
- 新しいやり方を試すと必ず問題が発生するので、短期でふりかえりを行い、放置しない
- ちょっとした工夫が奏功することがある
所感
非常に参考になったこと
- タスク管理
- リリース(デリバリー)
- レビュー
という課題項目自体、一休でこれから実施をしていく(一部実施している)内容にマッチしていたので、発生した問題や解決策へのアプローチなど、とても参考になる部分が多かったです。
やってみることの大切さ
どうしても「きっちり決めてからやり始めたい」と考えてしまいがちなのですが、「やってみて、ふりかえりながら小さく改善を続ける」ということが非常に大切なのだと改めて感じました。
他の発表でもそうでしたが、いきなりうまくいくことなんてあるわけないので、Try and Errorで発生した問題に対してふりかえりをしっかり行い、KPTを残していく形で、これから改善を続けていきたいと強く思った1日でした。