背景
今日GitHubの中の人のLTを聞く機会があって本当のGitHub-flowを聞いてきたので
忘れない間にメモ
GitHub-Flowのお約束
- Masterにあるものは即座にデプロイ可能な状態に保つこと
- ブランチの上で必ず作業し、その生存期間を短くすること
- すぐにPRを作り、フィードバックやサインオフを求めること
- マージしたらすぐにデプロイすること
本当のGitHub-flow
中の人曰くよくマージしてからデプロイすると言っている人がいるらしい。
だが本当のGitHub-flowは違う。
本当のflowは
PR作成
⇩
修正
⇩
デプロイ
⇩
フィードバック
⇩
マージ
らしい。
マージ前にデプロイすることでさらにユーザーに近いところでフィードバックを受けることができるとのこと。
ダメなら直ちにmasterに戻す。なので決まりごとの中にmasterは直ちにデプロイできる状態にあることと記載がある。
GitHubの中の人のコミュニケーションのやり方
GitHubは現在全世界に約600人の社員が点在しているとのこと
その中で日本に在住しているのはたったの10人！
しかも東京にいるのはその中の8人だとか。
全国各地に点在しているGitHubの中の人はどうやってコミュニケーションをとっているのだろうか？
コミュニケーションには常にURLをつける
URLをつけるとはどうゆうことなのか？
それは常にURLを参照すればどこにいても何時でも参照できるようにするため。
そのURLはPRのURLかもしれないし、ドキュメントの置いてあるURLかもしれないはたまたメールのやり取りを参照できるURLかもしれない。
こうすることにより後から参戦してもわかる、「いつ」、「誰が」、「なにを」、「どう」したかわかるのが素晴らしい。
GitHub運用での心構え
その1
pushしたらすぐにPRを作ろう！
こうすることでなにがいいのかというとすぐにみんなの目に触れフィードバックを受けることができる。
そうすることにより手戻りを減らしたり、より良いサービス、ソースコード作成につながるらしい。
なので修正の方向性が決まった時点でまずはpushしてPRを作成しよう！
その２
なるべく多くのことを自動化しよう！
テストやデプロイ、データの計測などより多くのことを自動化することにより人はより多くの時間をソースコードのレビューに力を注ぐことができる。
それにより、よりよい品質のコードができる。
その３
コミュニケーションにはチャットツールを活用しよう！
なぜチャットツールを使用するか。
それは大人数で現在の作業を共有することにより、全体の作業の透明性が上がり
今誰がなにをやっているかを認識することができる。
こうすることによりフローの共通化や教育に活かすことができる。
その４
より多くのことをbotにやらせよう！
なぜbotにやらせるか。
それはbotを通して誰がなにをやっているかをみんなで共有するため。
ここでチャットツールを活用することで得られる利益が実際どうして得られるのかわかる。
チャットツールを通してbotにデプロイやマージをやらせることにより現在誰がどの作業をやっていて
さらにどんなフローで作業をしているのか共有することができるのだ。
実際botにやらせること
実際botには以下のようなことをやらせるといいらしい。
- Implement on new branch
- Run build
- Communicate Build status
- Respond to build issues
- Create pull request
- Communicate ready for feedback
- Review
- Communicate review
- Respond to review
- Sign off
- Integrate master
- Branch deploy
- Test in production
- Fix issues
- Integrate master
- Re-deploy branch
- Merge branch
- Deploy master
※まじ誰か翻訳お願いします。
人間がやること
- かんぱい
ようはほとんどはbotにやらせて人間がやることはビールを飲むことということである
※大いに語弊があると思われるが苦情は一切受け付けません。
GitHub-flowを実現するには
PRはなるべく小さく
変更量はなるべく小さく切り分ける。
5行から10行程度の修正でも全然あり。
むしろそれくらいにしろやレベル
どのアプリケーションがデプロイされているかわかるようにする
基本的に一つのテスト環境にデプロイできるのは１PRである
なのでその環境にデプロイされている環境はどのブランチのどんな変更か一目でわかるようにしておく
複数のPRを並列で試験するためにはデプロイ環境を複数用意する必要がある。
フィーチャーフラグを使ってリスクを軽減する
フィーチャーフラグを設定してテスト対象ユーザーを一部に絞ることにより
デプロイによるリスクを軽減することで気持ち的にも楽にデプロイすることが可能である。
また、いざ全ユーザーに配布するときはそのフラグを切り替えるだけで全ユーザーに配布できる。
GitHub-flowを最大限に引き出すために必要なツール
- チャットツール
- 上記で記載しているようにチャットツールはGitHub-flowの開発では必要不可欠のツールの一つだ
- 監視ツール
- 常に死活監視や性能監視を行って、変更や修正を加えたことによる影響を見る
- 見える化ツール
- 監視ツールで収集したデータを常に見える化しておくことによりより多くの情報を一瞬にして認識することが可能である。
まとめ(感想)
以上ここまでが私が今日中の人の話を聞いていて感じたことである。
GitHub-flowは大変素晴らしく今すぐにでも試せることはたくさんあるが
全ての力を引き出すにはやはり自分のサービスや自社プロダクトなど
やった人が責任を取れる範囲でしか試せないflowだと感じた。
日本にはあるとき突然動かなくなった！！！！！を許してくれるお客様はまだまだ少ないように感じる。
大切なのは復旧までの時間とデータのバックアップだと思う。
なのでこれを読んでいただけた方は「バグは手作りの証」というのを世の中に広めていただきたい。
そしてさらに日本の技術の進化を後押ししていただけると日本で働く一エンジニアとして大変ハッピーな未来が待っていると信じている。
2016/7/1 追記
zuhiroさんから私の参加したLTの動画URLを提供していただきました！ありがとうございます！
私の記事を読んで質問が湧いた方がいらっしゃると思います是非動画を確認してみてください！
LT動画
50分位からGitHubの方の発表があります。
https://www.youtube.com/watch?v=lNdorWZ0aqc&feature=youtu.be&t=50m00s
また中の人から原本の英語バージョンのURLを提供していただきました！こちらも合わせてご覧いただければと思います！
ついでに宣伝
今回私が参加させていただいたのはIBMのBluemixUser会です
毎回色々なセッションをご用意しているのでよろしければご参加ください！
以下FacebookのURLです！
https://www.facebook.com/groups/bmxug/