Upgrade to Pro — share decks privately, control downloads, hide ads and more …

30 million workflows reveal about DevOps in pra...

30 million workflows reveal about DevOps in practice

Noboru Kurumai

February 13, 2020
Tweet

More Decks by Noboru Kurumai

Other Decks in Programming

Transcript

  1. 3

  2. 社のご紹介 • 世界最大規模のクラウド CI/CD サービス • より良いコードをより速く、簡単にリリースすることを可能に • 2011年設立、サンフランシスコ本社 •

    250人+の社員(米国、東京、英国にオフィス) • 19年7月 5,600万ドルのシリーズDを実施、合計1億1,550万ドルを調達
  3. 8 - 自動化したい ツールを 使う動機 - コストを削減したい - 開発スピードを上げたい -

    品質も・・・ - セキュr・・・ - 最高のチームづくりを したいから
  4. 11 の動作実績と対象データ 動作状況 - 月間3,500万件以上のジョブを処理中 (Linux, MacOS, Windowsをすべて含むが、オンプレ版は含まない) 対象データ -

    2019年6月1日〜8月30日に確認された3000万強のワークフローデータ - 40,000以上のOrganization(≒組織・企業) - 150,000以上のプロジェクト
  5. 14

  6. 17 ワークフローの動作時間(考察) - リードタイムはプロジェクトに強く依存するため、一概に何分(何秒)以内がベストとは言い切れない。 - ただし、3日以上というのは明らかに長過ぎるし、 2.1秒では何も出来ない。 - CircleCIの経験上、最適なワークフローは数分から数十分程度 -

    ワークフローの実行時間とは、アーティファクトをデプロイするものだけではなく、 そのワークフローの成果に到達する時間である。 - また、ワークフローの価値は、単にすばやく実行することではなく、 開発者に適切なフィードバックがすば やく行われること。 - ワークフローには理想的な長さに普遍的な標準があるわけではない。 大事なのは、長さを短縮できるポイントを探すべき。 - 本データはCircleCI上で自動化された時間だけを計測している。もしまだ自動化されていないテストやセ キュリティチェックなどがあれば積極的に自動化すべき。
  7. 20 デプロイの頻度(分析結果) レベルで 日に実行される数 6回 プロジェクトレベルで 日に実行される数 3回 プロジェクトレベルで デフォルトブランチの

    ワークフローが実行される数 1回 レベルで 日に実行される数 250回 プロジェクトレベルで 日に実行される数 74回 プロジェクトレベルで デフォルトブランチの ワークフローが実行される数 39回 50 パーセンタイル 95 パーセンタイル
  8. 21 デプロイの頻度(考察) - Flickrのプレゼンテーション以降、数多くのプロジェクトが高頻度のデプロイに挑戦している。 - しかしながら、1日に10回以上デプロイしているプロジェクトは多くはない 。 - 2019 Accelerate

    State of DevOps Reportでは、下記に分類されている。 - 非常に優れたチーム( Elite):1日に数回のデプロイ - ハイパフォーマンスのチーム: 1日から1週間に1回 - 低パフォーマンスのチーム: 1ヶ月から6ヶ月に1回 - CircleCI を使用している組織は、必要なときにいつでもデプロイできるため、デプロイ回数は、組織の事 情を反映したものになり、必ずしも優れた開発チームかどうかの指標にはならない - 代わりに、組織がコードをテストおよび統合する頻度 と、エラーが発生したときにどれだけ早く復旧できる かという指標は、開発チームのパフォーマンスが高いことを示します。
  9. 22

  10. 24 平均修復時間: (分析結果) 最も長い 最も短い 30日 1秒 未満 17.5時間 中央値

    おそらく、一日の終わりに失敗を検出して、 次の日に修正していることが多い State of DevOps 2019では、 Eliteで1時間以内 すべてのブランチの場合
  11. 25 平均修復時間: (分析結果) 最も長い 最も短い 1時間以下 中央値 デフォルトブランチの場合 15分 25

    パーセン タイル 30%のプロジェクトは90日間で一度も失敗していない(100% グリーン) 50%のOrganizationは1回で修正されている。 25%になると2回で修正されている
  12. 27 失敗の頻度(考察) - 全体で27%のワークフローが失敗に終わっているものの、 多くはトピックブランチの失敗に起因している。 これはGit Flowなどのプラクティスが有効に働いているため - デフォルトブランチでも 18%が失敗に終わっているが、

    State of DevOps Report 2019ではEliteでも 0-15%となっていて近い数値になっている。 - 50%のプロジェクトがCI/CDパイプラインの設定を変更してもビルドに失敗していない 。 これは、設定ファイルを使い回すか、設定ファイルのパッケージング機能である Orbsを使っているため。 今後は、CI/CDパイプラインのベストプラクティスをいかに早く取り込むか が重要となってくる。
  13. 28 回数は良いチームの指 標にはならない いつでもデプロイできる 状態を維持すること まとめ 最適なワークフローは 数分から数十分 開発者のフィードバック のスピードを意識

    修復時間を短くするに はプロアクティブな対応 と高度な自動化が必須 トピックブランチでの失 敗は恐れない。むしろ積 極的に結合する。 ベストプラクティスを取り 入れる
  14. 32