レポート：「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