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

BCP(ビジネスの継続性)の次は、CI(開発に継続的インテグレーション)が必要

 BCP(ビジネスの継続性)の次は、CI(開発に継続的インテグレーション)が必要

Masahiko Funaki(舟木 将彦)

February 01, 2022
Tweet

More Decks by Masahiko Funaki(舟木 将彦)

Other Decks in Technology

Transcript

  1. 従来のソフト開発と今、求められるソフト開発の違い • 前提 ソフトウェアは頻繁に インストール、更新できない ゴール 数年後にリリースする新バージョンでたくさんの良 い機能をお届け 手段(数年かけて実行) ヒヤリング→機能洗い出し→実装(遅延)→テスト

    (遅延)→リリース(遅延) • 前提 ソフトウェアは頻繁にプッシュで 更新がかけられる ゴール テレメトリー(行動)を元に、スムーズにシナリオ達成 可能なUIをお届け 手段(より短い周期で実行 ) シナリオ策定→フロー設計→実装→テスト→リリー ス→ログ取得→(先頭) ウォーターフォール手法 アジャイル手法 常時テストされ、実際に試用可能な状態を実現 実際に試用できるのは、数年ー数か月の結合時
  2. アジャイルさ(俊敏さ)を支える DevOps とコアとなる CI/CD プラン コード ビルド テスト リリース デプ

    ロイ 運用 監視 継続的インテグレーション (CI) 継続的 デプロイ (CD) 自動化できない 非正常系は 自動化できない 自動化できる コード追加・修正時は 常にビルド・テスト (最後にまとめてやらな い→早く失敗すれば 早く品質が安定する) サービス停止せず常に リリース/デプロイ (失敗時にはクイックに 修正 / 前バージョンに 戻せる)しくみ 共有 リポジトリ上 で 常に作業 運用・監視しやすい 品質をコードに反映 (必要なデータの取得、 スケーラビリティの 確保) 変化+安定の両輪が揃ってこそ「継続的」に価値提供 (変革)を続けられる どうやって短期間で回す?
  3. 「継続的」に進めるためのカギは自動化 プラン コード ビルド テスト リリース デプ ロイ 運用 監視

    継続的インテグレーション (CI) 継続的 デプロイ (CD) エッセンシャル ワーカーに依存 非正常系は エッセンシャル ワーカーに依存 自動化できる 作業の抜け・漏れ・ミ ス・不正を回避 (不必要に心配 しない) 担当者がいなくても 作業がストップ しない (待ち状態が発生 しない) 人でなければできな い仕事への割り振り (スピード・質の 実現)
  4. 14 CI/CDとは - CI (Continuous Integration / 継続的インテグレーション) - CD

    (Continuous Delivery / 継続的デリバリ) 継続的であるためには「自動化」が必要ではあるが それだけでは十分ではない
  5. 15 CircleCIユーザーの 中央値(2020/08) ベンチマーク目標値 スループット ワークフローの実行数 0.7回/日 プルリクエストのマージごと いつでも(遠慮せずに)ビルド可能 実行時間

    ワークフローの実行時間 4分以内 5~10分 自動化可能なことは全て任せる 復旧時間 ワークフローの失敗~成功の時間 56分以内 60分以内 大きな失敗を最後にではなく、すぐ に復旧できる失敗を早期に 成功率 ワークフローの成功数/実行数 デフォルトブランチで 80% デフォルトブランチで 90%以上 自動化における4つの評価ポイント ここの数値に「近い目標」として まずは追いつき ここの数値を「あるべき姿」として 目指す 現時点での数値を「課題」として 把握した上で
  6. 16 CircleCIユーザーの 中央値(2020/08) ベンチマーク目標値 スループット ワークフローの実行数 0.7回/日 プルリクエストのマージごと いつでも(遠慮せずに)ビルド可能 評価ポイント1:

    スループット パーセンタイル 5 50 90 95 実行数(回/日) 平均値: 8.22 0.03 0.70 16.03 32.125 金曜日(UTC)のスループットは11%減少 土日(UTC)のスループットは70%減少 月曜日(UTC)のスループットは9%減少
  7. 17 CircleCIユーザーの 中央値(2020/08) ベンチマーク目標値 実行時間 ワークフローの平均実行時間 4分以内 5~10分 自動化可能なことは全て任せる 評価ポイント2:

    実行時間 パーセンタイル 5 50 90 95 実行時間 平均値: 24.6分 12秒 3.96分 21.35分 34.01分 エンジニア1人のチームで実行時間が最長
  8. 18 CircleCIユーザーの 中央値(2020/08) ベンチマーク目標値 復旧時間 ワークフローの失敗~成功の時間 56分以内 60分以内 大きな失敗を最後にではなく、すぐ に復旧できる失敗を早期に

    評価ポイント3: 復旧時間 パーセンタイル 5 50 75 90 95 復旧時間 平均値: 14.85時間 2.06分 55.11分 9.5時間 39時間 3.4日 75と90の間に夜(非労働時間)のギャップがある エンジニア数が増えるに従い(200人までは)減少 →チームの多様性重要(いつ、どれだけ働けるか+燃え尽きない)
  9. 19 CircleCIユーザーの 中央値(2020/08) ベンチマーク目標値 成功率 ワークフローの成功数/実行数 デフォルトブランチで 80% デフォルトブランチで 90%以上

    評価ポイント4: 成功率 パーセンタイル 5 50 75 90 95 成功率 平均値: 54% 0% 61% 89% 100% 100% 企業規模(エンジニアの数)と成功率の間に相関はない デフォルトブランチの成功率 > 非デフォルトブランチの成功率
  10. 21 • ワークフローのメトリクスをインテリジェントに収 集・可視化 ◦ ワークフローやジョブ別の内訳 ◦ どのプロジェクト、ワークフロー、ジョブが失 敗し、最もクレジットを消費しているのか ◦

    遅いテストワースト10 失敗するテストワースト10 ◦ 成功・失敗が不安定なテストはどれか ◦ テスト実行時のCPU/RAM使用推移 テスト インサイト
  11. 22 データの活用 ~ 停滞せず、さらに良く 外部プロダクト・サービスとの連携・拡張 • ジョブ終了時およびワークフロー終了時の Webhook 呼び出し Sumo

    Logicダッシュボード連携 (https://www.sumologic.com/application/circleci/) Datadog CI Visibility連携 (https://www.datadoghq.com/ja/blog/datadog-ci-v isibility/)