@shiba_yu36
今日の話
- はてなブログチームについて
- 開発フローの課題とその解決
Gitでおこった問題とか。
はてなブログチーム
はてなブログのチームである。
- 5 engineeers
- 2 designers
- 170 PR per month
- 1300 commits per month
- 45 releases per months
on GHE
- 開発速度を保てている
開発フローの問題発生開発フローの改善
- タスク管理
- レビュー
- リリース
開発の流れ
- issue登録 アサイン
- issueに対応するbranch作成 など
ブランチ運用
- master(本番と同一)
- develop(リリース可能ならmerge)
- feature branch(機能ごと)
masterにdevelopをmergeし、developに各featureをmerge
タスク管理
- REDMINE
- GHのissue
redmine
タスクはredmine コードレビューはgithubで
- 両方のツールを見る必要がある
コードとの連携も便利ではない
あんまりうまくいかない
- マネージャの効率はともかく開発者の効率は上がらない
ツールを１つにして、issueとコードを連携する
- タスク管理はissuesのみ
- コードレビューはPR
開発者の効率が上がった
問題発生
チームの重要なものがよくわからなくなった issuesは優先度や締め切りの仕組みが少ない 誰が何をやっているのか分からず、進行中のタスクを俯瞰できない
開発者はともかく、マネージャがチームの俯瞰を出来ない
issuesをメインにしつつ、チームの重要なもの、進行中のものは他をサポート。
カンバンで補助
Github x カンバン
- Issuesすべてのタスクはここに入っている
- だれでもここには追加していい
- 追加されたタスクは毎朝検討
カンバン
- issuesのなかで重要なものだけマネージャが選択
- 重要なものしか追加しない
- 朝会でしか見ない
カンバンは、重要なものリストと、その進捗の２枚
開発者は１日中GHのみを見る
- マネージャは朝会だけを見る
重要なものは把握しつつ、開発者効率の良い管理で。
- issuesメイン
- ホワイトボードで重要なものを管理
- スクラムまでいかないゆるいタスク管理
変に導入すると今までの文化が壊れたり、開発効率が下がったりする
レビュー
PRお願いします→はい、やります(個別にお願いする)
普通のやつっぽいPR
問題その１
PRの状態がよくわからなくって、レビューをためらう
- WIP？
- マージまち？
- 依頼中？
その２
- PRがすごい量に
レビューツールとしては最高だけど、促進があんまりない
解決案
- レビュー状態をはっきり
- レビュー依頼一覧をわかりやすく
- 雰囲気作り
ラベルとレビュータイムを導入
ラベル
レビュー依頼をはっきりする レビュー完了でもし問題があったら、レビュー依頼に戻す、みたいなのをやる。
ラベルは簡単につけられるので、今まさにレビューしたいものがわかる
自分のアサインからレビューも見やすい
GHEにChromeの自作プラグインを突っ込む
レビュータイム
みんなでレビューする雰囲気作り ikachanでレビュー依頼するようにIRC通知→昼飯後にレビュー依頼されたPRを見る
Githubとレビュー
- PRだけだとレビューの促進がうまくいかない
リリース
- mergeされた瞬間にリリース
- デプロイ自体はコマンド一発にしていた
デプロイ作業そのもの以外にリリースに必要なものがある
(上長に確認するとか)
- マネージャ確認
- stagingで最終確認
- リリース
全部自動化できてない
問題１
- マネージャ確認せずにリリースしちゃった(自動化失敗のミス)
- その部分を教えないと新人がリリースできない
- デプロイ作業以外をうまくサポートできないか
→PRにリリース手順書をつける
確認してチェック(チェックボックスをつける)
全チェックしてリリース→だれでもリリースできるように
git-pr-release
- リリースまちのissueを集める
独自に作業手順書のテンプレートを作れる
デプロイはできるだけ自動化
- 全部自動化は難しい
PRをうまくつかって手順書をサポート
GHをメインに最大限活用
- いろんな問題、そのたびに解決方法を検討
- ちょっとした工夫
ワークフローは改善し続けることが大切
- 今言ったことが絶対ではなく、参考にして改善していったらいい
- 具体的な話があったらブログとかで紹介していってくれ
