レポート：「CircleCIの3000 万件のワークフローから得られたDevOpsに関する知見」 #devsumi2020 #devsumiC

概要

developers summit 2020に参加してcircleciのお話を聞いてきました。
タイトルの通り、CircleCIの持っているデータを分析してみたよと言うお話。
NetflixやFlickr等々、有名企業のこういったデータは公開されることが多いですが
全体的なデータってなかなかないので面白かったですね。

セッション情報

発表資料

トピック

スライドに書いてあることをたらたら書いてもしゃーないので目立ったところだけ。

CI/CDツールを使う理由

CI/CDツールを使う理由って、いろいろあれど結局「最高のチームを作る」に帰結するよね。

最適なビルド時間

ワークフローの動作時間

中央値が3分27秒
90%タイルで28分
80％タイルで10分

世の中には28分もビルド待ってる人たちがいるのか（衝撃）

ビルド時間に関しては早いことが正義だと思ってるのでどんどん高速化していきたい。
並列実行とかwebhookのイベント毎に実行するジョブ変更するとか

ここらへんを社内で話してたら大規模なシステムだと1時間とか2時間普通で待ちますよと言うお話も聞きました。

ここで、登壇者の車井さんが下記のことを言っててなるほどな〜となった。

ワークフローの価値は、単にすばやく実行することではなく、
開発者に適切なフィードバックが素早く行われること。
https://speakerdeck.com/kurumai/30-million-workflows-reveal-about-devops-in-practice?slide=17 🔗

単純に考えれば、テストがコケただのコケた内容がどうのだのを開発者が素早く確認できる環境なのかな〜とか思ったけどどうなんでしょう。

デプロイ頻度

イケイケ企業を真似してデプロイ頻度を増やす取り組みをしている企業が多いらしい。

※デフォルトブランチ = masterブランチ（多分） ※プロジェクト = リポジトリ単位 ※Organization = 会社単位

本番のデプロイ頻度に関してはアレだけど、開発環境とかへのデプロイで言えば上半分には入ってるっぽい。
もっと上目指してこ。

非常に優れたチームは一日に複数回デプロイするって言われてるけど
そう言いきっちゃっていいの？と言う話もあった。

デプロイ頻度、リードタイム、MTTR、変更失敗率だけど。　アプリの場合リリース頻度が高いことが必ずしも良いわけじゃないと思っているのだけど、どうなんだろう。　昨今は自動アップデートをオンにしているユーザもある程度いるだろうし、頻度高いほうが良いといえば良いのかな。
— tarappo (@tarappo) February 10, 2020

後述するけど複合的なデータを見ないとね。と
デプロイ頻度だけ見てたらなんにもならんと。

あとはフィーチャーフラグのプラクティスうまく使ってデプロイ頻度を増やしてるところが多いと。
前職で扱ったシステムはレガシーだったけどちゃんとフィーチャーフラグだったり、
制御フラグ的なものを持ってて
管理画面から更新で顧客に機能開放とかやってたな〜とか思い出した。

MTTR

前職ではMTBFばかりを追いかけてたので、MTTRの分析の話は新鮮でよかった。
けれども、リバートすればすぐ復旧の世界なので大したデータではないかも。

masterブランチの場合
- 中央値が1時間
- 25％タイルが15分

MTTRの計測が無駄とかではなく、データが悪いかなと言う話。

失敗の頻度

CI/CDのプラクティス＆Git Flowなどのプラクティスをちゃんと取り入れてると
失敗が少ないねと言うお話だった。

まとめ

デプロイ回数は指標にならない。いつでもデプロイ出来る環境を維持することが大事
ビルド時間は開発者に素早くフィードバックするために早いほうが良い
MTTRを短縮するには自動化ガンガンしていけ
トピック（開発）ブランチでの失敗は恐れるな

雑感

VPNで閉域網使ってビルドもデプロイも手動な世界からCICDガンガン回せな世界ににやってきた人間なので
今の弊社でも十分すごいなって思ってるんですけど、もっと良くしていきたいですね。「俺の考えた最強のCI/CD」目指していきましょう。