勉強会参加：はてなブログの実例で学ぶ「はてな流」大規模Webサービス開発の勘所
社内Wikiで共有したところ好評だったので、ブログの方にも投稿しておきます。
こちらの勉強会に参加してきました。
https://supporterzcolab.com/event/246/
色々話されたのですが、自分が「お！」っと思ったところだけ２点抜粋して書いていきます。
新規機能実装はプルリクは細かく、リリースも細かく
一機能を同一のプルリクで作業すると。。。
- マージする際のコンフリクト地獄
- レビューの労力がかかってしまい安定性が失われてしまう
- 大量のレビューのフィードバック対応
など問題があったので、細かくプルリクを書いて、細かくリリースする方法を行なっているようです。
よくある方法として、リリースブランチを切ってそこにマージしていく方法があるが、それもコンフリクト地獄は発生するし、他の部分との兼ね合いで大量に新機能の一部をcherry pickすることになってします。
この方法でも依然問題が残ります。
なのでユーザーに見えないような工夫をして、実装を行い細かくリリースしていっています。
例えば、ロジック部分のみの実装や動線を消した状態の実装を行なっています。
また、プルリクも細かく行なっています。
これもコンフリクトをなるべく無くしたり、レビューの労力を軽減する為です。
意識するのはだいたい１日の作業分が１プルリクになるようにしているそうです。
例えば、モデルだけとか、コントローラだけとかそういった分割しやすい単位で分けているみたいです。
＊ただし場合よってはモデルとコントローラーを一緒にやった方がいい場合もあるので、臨機応変に粒度は変えている。
その他具体的な方法は以下の記事により詳細が書いてあるので、そちらも確認していただければと思います。
http://developer.hatenastaff.com/entry/2017/08/07/170000
Mackerelのちょっと変わった利用方法
https://mackerel.io/ja/
Mackerelは、はてなが開発したサーバー監視ツールです。
一般的にはもちろん、サーバー監視に使っています。
ただ、それ以外の方法で使っており、いくつか例を教えてもらいました。
デプロイにかかる時間の計測
Makarelの機能を使って計測しているようです。
以前はてなではデプロイに時間がかかっていたので、そういったことを行なっているみたいです。
話は変わりますが、デプロイを短縮させたがたい的な方法は以下の記事により詳細に書いてあるので、そちらも確認していただければと思います。
http://this.aereal.org/entry/2016/12/16/170000
プルリク数の可視化
Mackerelを使ってプルリク数を可視化しています。
修正行数とかも計測しているようです。
そうすることで、実装の忙しさを見れるようにして、新規実装のタイミング等を図っています。
こういったことはmakarelのcliツールで簡単に行えます。
nodeのアップデートが必要なモジュールの数をトラッキング
以前はデプロイの度にモジュールのアップデートを行なっていたとのことです。 Mackerelでアップデートが必要なモジュール数を計測して可視化し、溜まって来たタイミングでアップデートをかけるそうです。
まとめ
プルリクを細かく分けて出す方法は今まで経験がないので一度試してみたいなと思いました。
Mackerelを使った方法ですが、特に「プルリク数の可視化」は非常にいいと思いました。
チケットベースで行なっていれば必要ないように思いますが、実際にのアウトプットもキチンと可視化することも重要に思いました。
またこのようなチーム運用を可視化する考えを発展させて、バグ・不具合の可視化も行なってみるのも面白いと思いました。
どういった場合のバグが多いのか、そして多いケースがわかれば、どのようにすればバグを減らせるのかの対策がより狙いやすくなる気がしています。
