読者です 読者をやめる 読者になる 読者になる

kentana20 技忘録

技術ネタを中心に、セミナー、勉強会、書籍、会社での出来事を綴っていきます。不定期更新。

GitHub Kaigi参加レポート#1(はてなブログの開発フローと Github @shiba_yu36)

本日(6/1)、渋谷のサイバーエージェントさんで開催されたGitHub会議に参加してきました。

GitHub会議はnaoyaさんが中心となって企画したGitHubのユーザイベントです。タイムスケジュールはこんな感じ。休日のイベントとしてはかなり長めでした。

スケジュール

本編

  • Hello, Github Kaigi @naoya
  • GitHub実践入門 ─ Pull Request による開発の変革 @hirocaster
  • はてなブログチームの開発フローとGitHub @shibayu36
  • OSSGitHub @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

    • ツールGitHubのissuesメインとした
    • 結果、開発者の効率は上がったが数カ月後に問題発生
  • 問題点-2

    • issuesだけでは優先度・納期が見えづらい
    • issuesだけでは進行中のタスクを俯瞰できない
    • 開発者の効率は良くなったが、マネージャにとっては管理しづらい問題が発生
  • 解決策-2

    • issuesをメインにして開発者の効率はキープ
    • issuesに加えて、一部の案件のステータスはカンバンで見える化
    • GitHub → 開発者 / カンバン → マネージャ・朝会
  • 解決策-2(issues)

    • すべてのタスクを入れる
    • 社内の誰でも(非エンジニアも)追加してよい
    • 追加されたタスクは毎朝検討する
  • 解決策-2(カンバン)

    • Issuesの中で重要なものだけをマネージャが選んで掲載
    • 重要なものしか掲載しない
  • 結果

    • 重要なものは把握しつつ、開発効率重視のスタイルをとった
    • スクラムまでいかないゆるいタスク管理でうまく運用できるようになった

レビュー

  • 以前のレビュー

    • Pull Requestは開発者がレビュアーを指名して個別にお願いしていた
    • レビューするときは、時間のあるときにPull Requestの一覧から選んでレビュー
  • 発生した問題

    • Pull Requestの状態がわからない(レビュー依頼中?修正中?WIP?)
    • レビューが消化されずに貯まる
    • ベテランだけがレビューし続けるという属人的なレビュー体制になっていた
  • 解決案

    • レビュー状態ラベルを作ってレビュー状態を見える化
    • Chrome拡張を使ってPull Requestにラベルを貼る
    • みんなでレビューする文化・雰囲気作りのため、毎日14:00〜レビュータイムを導入(IRC botがレビュータイムを告げる)
  • 結果

    • レビュー状態ラベルによって、「いまレビューをしなければいけないもの」が見える化できた
    • レビュータイムによって、みんながコードレビューをする文化が醸成できた

リリース

  • 以前のリリースの流れ

    • マネージャにリリースして良いかを確認
    • 検証環境で最終確認(各自)
    • デプロイコマンド(手動)でデプロイ(リリース)
    • (そもそも、自動化し切れない部分があった)
  • 発生した問題

    • マネージャに確認せずにリリースしてしまった(自動化していない手動作業部分でのオペミス)
    • 新人が入社したときに手動作業部分をしっかり説明しないと、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をうまく使って手順をサポート

まとめ

  • タスク管理
  • レビュー
    • レビュータイム
    • レビューラベル
  • デプロイ
    • リリース内容をPull Requestにまとめる
  • ワークフロー
    • 改善をし続けることが大事
    • ベストな解ではない(はてなブログチームはこうしてるよ、というだけ)
    • 自分たちのスタイルに合ったフローを少しづつ作っていくことが大切
    • 新しいやり方を試すと必ず問題が発生するので、短期でふりかえりを行い、放置しない
    • ちょっとした工夫が奏功することがある

所感

非常に参考になったこと

  • タスク管理
  • リリース(デリバリー)
  • レビュー

という課題項目自体、一休でこれから実施をしていく(一部実施している)内容にマッチしていたので、発生した問題や解決策へのアプローチなど、とても参考になる部分が多かったです。

やってみることの大切さ

どうしても「きっちり決めてからやり始めたい」と考えてしまいがちなのですが、「やってみて、ふりかえりながら小さく改善を続ける」ということが非常に大切なのだと改めて感じました。

他の発表でもそうでしたが、いきなりうまくいくことなんてあるわけないので、Try and Errorで発生した問題に対してふりかえりをしっかり行い、KPTを残していく形で、これから改善を続けていきたいと強く思った1日でした。