4つのメトリクスでCircleCI上の膨大なワークフローを分析
CI/CDツールを使う動機として多いのは、「自動化したい」「コストを削減したい」「開発スピードを上げたい」といったところだろう。ほかにも、ソフトウェアの品質やセキュリティの強化などが考えられる。
「これらはすべて、『最高のチームづくりをしたい』ということに収束するのではないか」と、車井氏は冒頭で述べた。
では、最高のチーム、優れたパフォーマンスを発揮できるチームとはどのようなものか。それをデータに基づいて分析するために、CircleCIでは膨大なワークフローの調査を実施した。対象となったのは、CircleCIのクラウドプラットフォーム上で2019年6月1日～8月30日の3カ月間に確認された3000万件強のワークフローデータ。これらは、4万以上のOrganization（組織・企業）と、15万以上のプロジェクトから取得されたものだ。なお、CircleCIの「ワークフロー」とは、複数のジョブ（ビルド、テスト、デプロイなど）を組み合わせて構築するCI/CDパイプラインの全体を指す。
3000万件のワークフローから具体的にどのようなデータを抽出したのかについて車井氏は、「DORA（DevOps Research and Assessment）が公表した『2019 Accelerate State of DevOps Report』（以下、State of DevOps Report）で示されている4つのメトリクスをベースにした」と説明。
それらは「スループット」と「安定性」の2つに大きく分かれ、前者は「変更のリードタイム」と「デプロイ頻度」、後者は「平均修復時間（MTTR）」と「失敗の頻度」といったメトリクスで構成されている。
ただし、CircleCIはあくまでもCI/CDツールであり、State of DevOps Reportで示されているこれらのメトリクスをそのまま適用するのは難しいという。実際には、それぞれ次のようなCircleCI上で取得可能なメトリクスを採用し、分析を行っている。
ワークフローデータの分析結果と得られた知見
各メトリクスの分析結果と、それに基づく考察は次のとおり。
ワークフローの動作時間（変更のリードタイム）
全体の中央値は3分27秒。ちなみに、90パーセンタイル（速い順で全体の90/100の位置にあたるデータ）の値は28分で、ほとんどのワークフローが30分以内に終わっていることがわかった。
ワークフローの動作時間はプロジェクトの中身に依存するため、何分以内がよいとは一概には言えないが、「CircleCIの経験上、最適なワークフローは数分から数十分」とのこと。また、ワークフローの価値はデプロイをすばやく実行するということだけではなく、「開発者に適切なフィードバックが速やかに行われることが重要」と車井氏は強調した。
ワークフローが開始される頻度（デプロイ頻度）
中央値（50パーセンタイル）は、Organizationレベルで1日に6回。プロジェクトレベルでは1日3回、その中でデフォルトブランチ（マスターブランチ）に関しては、1日1回という結果となった。また、最大頻度に近い95パーセンタイル（少ない順で全体の95/100の値）のCircleCIユーザーでは、1日あたりOrganizationレベルで250回、プロジェクトレベルで74回、デフォルトブランチに限っても39回ものワークフローを実行していることも判明した。
高頻度のデプロイが注目されるようになったのは、10年ほど前からだ。DevOpsの原点として知られる、Flickrの2009年のプレゼンテーション「10+ Deploys per Day Dev and Ops Cooperation at Flickr」では、その名のとおり1日に10回以上デプロイを行うことが紹介されて話題となった。さらに、2012年にはAWSがre:Inventの基調講演で、Amazon.comにおける「平均11秒に1回のデプロイ」「最大で1時間に1079回のデプロイ」を発表。以来、数多くのプロジェクトが高頻度のデプロイに挑戦しているが、車井氏によれば、今日でも1日10回以上のデプロイを実践しているプロジェクトはそう多くはないそうだ。
今回の分析に用いるメトリクスのベースとなったState of DevOps Reportでも、「1日数回のデプロイ」を「非常に優れたチーム（Elite）」として分類している。そのレベルであれば、平均的なCircleCIユーザー（中央値）もクリアしていることになるが、「デプロイ回数自体は、必ずしも優れた開発チームかどうかを示す指標にはならない」と車井氏は指摘する。
「最終的なデプロイ回数は、組織の事情を反映したものになる。それよりも、必要なときにいつでもデプロイできる状態を維持することを意識するべきだ。一方、ワークフローの頻度は、Organizationやプロジェクトがコードを結合する頻度を示すものでもあり、細かく修正してテストを繰り返すことで、品質を高めていくという意味で、開発チームのパフォーマンスを表す指標になり得る」
車井氏は併せて、フィーチャーフラグを使ってリリースとデプロイを切り離し、コントロールすることもリリースの安全性を高めるうえで有効であり、ワークフローを設計する際にはフィーチャーフラグの使用も検討することを推奨した。
レッドビルドがグリーンビルドになるのに要する時間（平均修復時間）
レッドビルドとは、CircleCI上でワークフローが失敗で終わった状態のことだ。それが同じブランチでグリーン（成功）ビルドに変わるまでに要する時間を、平均修復時間として集計・分析した。
すべてのブランチを対象とした集計結果は、中央値が17.5時間。これはおそらく、「1日の終わりに失敗を検知して、翌日に修正する」パターンが多いためと考えられる。また、デフォルトブランチに絞った集計では、中央値が1時間以下となった。State of DevOps Reportによると、Eliteは「1時間以内に修復」とされており、CircleCIの平均的ユーザーも、デフォルトブランチについてはそのレベルをクリアしている。これはそう簡単に実現できるものではないと車井氏は言う。
「少なくともユーザーから報告を受けて初めて対応開始するようでは、1時間以内の修復は難しい。これを実現するには、プロアクティブな対応と高度な自動化が必須。これから取り組む方は、まず1時間以内の修復を目指すところから始めて、そのためには何が必要なのか、何を変えなければいけないのかを考えていく必要がある」
ワークフローの失敗率（失敗の頻度）
分析の結果、CircleCI上にある3000万件のワークフローのうち27％が失敗で終わっていることがわかった。これはすべてのブランチを対象とした数値であり、ブランチ別で見るとトピックブランチの失敗率は31％、デフォルトブランチの失敗率は18％となっている。トピックブランチの失敗が多くを占めているが、「トピックブランチでの失敗については恐れるべきではない」と車井氏は指摘する。
これは、むしろGitFlowなどのプラクティスが有効に働いているということ。ここでの失敗は問題ないので、積極的に結合して早めにテストしていくほうが望ましいという。
デフォルトブランチの失敗率18％についても、State of DevOps Reportで報告されているEliteの失敗率が0～15％であり、少し足りないものの近いレベルにはあるようだ。
もう1つ特筆すべき分析結果として、50％のプロジェクトがCI/CDパイプラインの設定を変更しても、ビルドに失敗していないことがわかった。
「おそらく設定ファイルを使い回しているか、あるいは設定ファイルをパッケージングしてシェアできるCircleCIの『Orbs』という機能を使っているためと思われる。Orbsを利用して検証済みの設定を取り組むことにより、新しいパイプラインに変わっても失敗せずにグリーンビルドできるようになる。今後はこのように、テストやデプロイを単に自動化するだけでなく、CI/CDパイプラインのベストプラクティスをいかに早く取り込んでいくかが、より重要になってくるのではないか」
なお、今回のワークフローデータの調査・分析では、CircleCIの実行環境（Dockerコンテナ、Linux VM、macOSなど）や言語の差異などは考慮されていないが、次はより細分化した分析の必要性も感じているという。
最後に車井氏は、「例えばPHPで書かれたプロジェクトの平均失敗率は7％と、全体平均と比べて非常に少ない結果が出ている。これだけの差異があるのは、明らかに何らかの原因があるはず。また、ブランチの種類や数の違いによる影響などについてもさらに細かく見ていきたい」と、今後もより詳細な分析を進めていく意向を示し、セッションを結んだ。
お問い合わせ
CircleCI
