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

ウォーターフォールが進化してもアジャイルにはならない

 ウォーターフォールが進化してもアジャイルにはならない

2022年4月13日、14日開催の 「ITモダナイゼーション Summit 2022 - 2025年の崖を乗り越えDXを加速させるテクノロジー戦略」の中で、「ウォーターフォールが進化してもアジャイルにはならない」と題して30分間お話させていただいた際のスライドです。

https://project.nikkeibp.co.jp/event/x22041314/

More Decks by Masahiko Funaki(舟木 将彦)

Other Decks in Technology

Transcript

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

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

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

    継続的インテグレーション (CI) 継続的 デプロイ (CD) エッセンシャル ワーカーに依存 非正常系は エッセンシャル ワーカーに依存 自動化できる 自社 自社 パート ナー
  4. 15 1. ビルドやテストを効率化する①〜無駄に待たない テストジョブの分析 ・過去100回のテストから、   成功率が低いテスト   実行時間が遅いテスト ・過去14日間のテストから   成功・失敗が不安定な   (Flakyな)5テスト

    ◎ ジョブ実行時のCPU/RAM   使用率をグラフ表示  (並列実行時はそれぞれに   ついて表示) Dockerコンテナの構築 ・開発環境や実行環境、  サーバレスなサービスなど  コンテナ構築が  CIのゴールに ・Dockerfile 作成のベスト  プラクティスを適用しても  まだ遅い(失敗はつらい) Docker レイヤー キャッシュで  変更箇所の前までは  3日間キャッシュ有効 ◎ npmやpip, Yarnなどの  ライブラリもキャッシュ   可能) テストの分割 ・ファイル名を元に  ファイルの数を均等に ・ファイルサイズを元に  ファイルの大きさを均等に ・タイミングデータを元に  処理時間を均等に →30並列まで  同時並行実行可能 30並列実行 キャッシュ活用 テスト結果の分析
  5. 18 1. ビルドやテストを効率化する①〜無駄に待たない テストジョブの分析 ・過去100回のテストから、   成功率が低いテスト   実行時間が遅いテスト ・過去14日間のテストから   成功・失敗が不安定な   (Flakyな)5テスト

    ◎ ジョブ実行時のCPU/RAM   使用率をグラフ表示  (並列実行時はそれぞれに   ついて表示) Dockerコンテナの構築 ・開発環境や実行環境、  サーバレスなサービスなど  コンテナ構築が  CIのゴールに ・Dockerfile 作成のベスト  プラクティスを適用しても  まだ遅い(失敗はつらい) Docker レイヤー キャッシュで  変更箇所の前までは  3日間キャッシュ有効 ◎ npmやpip, Yarnなどの  ライブラリもキャッシュ   可能) テストの分割 ・ファイル名を元に  ファイルの数を均等に ・ファイルサイズを元に  ファイルの大きさを均等に ・タイミングデータを元に  処理時間を均等に →30並列まで  同時並行実行可能 30並列実行 キャッシュ活用 テスト結果の分析
  6. 19 Dockerレイヤーキャッシュ (イメージビルドの高速化) Dockerレイヤーキャッシュ(DLC)は、CircleCI のジョブ中にビルドされた Docker イメージの 個々のレイヤーがキャッシュされます。その後で CircleCI を実行すると、イメージ全体が毎回

    リビルドされるのではなく、未変更のイメージ レイヤーが再利用されます。 つまり、コミット間で Dockerfile の変更が少ないほど、イメージ ビルド ステップが短時間で完了します。 https://youtu.be/ZqpIXKMn0G4
  7. 20 1. ビルドやテストを効率化する①〜無駄に待たない テストジョブの分析 ・過去100回のテストから、   成功率が低いテスト   実行時間が遅いテスト ・過去14日間のテストから   成功・失敗が不安定な   (Flakyな)5テスト

    ◎ ジョブ実行時のCPU/RAM   使用率をグラフ表示  (並列実行時はそれぞれに   ついて表示) Dockerコンテナの構築 ・開発環境や実行環境、  サーバレスなサービスなど  コンテナ構築が  CIのゴールに ・Dockerfile 作成のベスト  プラクティスを適用しても  まだ遅い(失敗はつらい) Docker レイヤー キャッシュで  変更箇所の前までは  3日間キャッシュ有効 ◎ npmやpip, Yarnなどの  ライブラリもキャッシュ   可能) テストの分割 ・ファイル名を元に  ファイルの数を均等に ・ファイルサイズを元に  ファイルの大きさを均等に ・タイミングデータを元に  処理時間を均等に →30並列まで  同時並行実行可能 30並列実行 キャッシュ活用 テスト結果の分析
  8. 21 • ワークフローのメトリクスをインテリジェントに収 集・可視化 ◦ ワークフローやジョブ別の内訳 ◦ どのプロジェクト、ワークフロー、ジョブが失 敗し、最もクレジットを消費しているのか ◦

    遅いテストワースト10 失敗するテストワースト10 ◦ 成功・失敗が不安定なテストはどれか ◦ テスト実行時のCPU/RAM使用推移 テスト インサイト
  9. 22 1. ビルドやテストを効率化する②〜無駄に待たない ジョブ実行環境 ・ビルドやテストに合わせた  適切なリソースを割り当て  可能 →中〜低スペックで  並列実行  VS

     (並列実行のメリット小  なら)  高スペックで単独実行 実行環境 リソースクラスと消費クレジット Docker Executor クラス vCPUs RAM クレジット small 1 2GB 5クレジット/分 medium 2 4GB 10クレジット/分 medium+ 3 6GB 15クレジット/分 large 4 8GB 20クレジット/分 Freeプランでは30,000クレジット/月が無料で付与 (mediumクラスなら3000分=50時間に相当) ※月20日換算で一日あたりのジョブ実行時間 2.5時間
  10. 24 2. 幅広いビルド環境をサポート 自分の用意した実行環境で CircleCIのジョブを実行 ・エージェントをインストー  ルすることで  CircleCIのジョブを実行 実行環境(サポート対象) ・Ubuntu

    18.04+(x86_64/ARM64) ・RHEL8 (x86_64/ARM64) ・Mac OS X 10.15+ (Intel) ・macOS 11.2+ (Apple M1) ・Docker (x86_64/ARM64) ・Kubernetes (x86_64) ・Windows Server 2019,2016 (x86_64) Dockerベースの実行環境 ・Linuxベースのコンテナを  実行可能 ・CircleCIからはCIに特化  した cimg/xxxxx イメージ  を提供 VMベースの実行環境 ・Linux(x86_64, aarch64) ・Windows ・macOS ・GPU(Linux/Windows with  Nvidia Tesla Tensor Core  GPU) Linux,Win,Mac ランナー x5
  11. 25 リソースクラス: マシンスペックのカスタマイズ • small (1vCPU, 2 GB RAM) •

    medium (2 vCPU, 4 GB RAM) • medium+ (3 vCPU, 6 GB RAM) • large (4 vCPU, 8 GB RAM) • xlarge (8 vCPU, 16 GB RAM) • 2xlarge* (16 vCPU, 32 GB RAM) • 2xlarge+* (20 vCPU, 40 GB RAM) 詳細はドキュメント をご参照ください Docker Linux (Machine) macOS • medium (2 vCPU, 7.5 GB RAM) • large (4 vCPU, 15 GB RAM) • xlarge (8 vCPU, 32 GB RAM) • 2xlarge* (16 vCPU, 64 GB RAM) • gpu-small* (4 vCPU, 15 GB RAM, 1 GPU, 8 GiB GPU RAM) • gpu-medium* (8 vCPU, 30 GB RAM, 1 GPU, 16 GiB GPU RAM) * カスタム年間プランが必須 詳細はドキュメントをご参照ください • medium (4 vCPU, 8 GB RAM) • large* (8 vCPU, 16 GB RAM) 詳細はドキュメントをご参照ください
  12. 26 リソースクラス: マシンスペックのカスタマイズ • arm.medium (2 vCPU, 8 GB RAM)

    • arm.large (4 vCPU, 16 GB RAM) Arm64のプレビューを開始する場合は下記の リンクをご覧ください。 Preview Docs Arm64 Linux Android + Emulator • Image for machine executor • Supports nested virtualization and x86 Android emulators • Also comes with Android SDK pre-installed 詳細な情報は下記のドキュメントをご 参照ください。 Preview Docs Windows • medium (4 vCPU, 15 GB RAM) • large (8 vCPU, 30 GB RAM) • xlarge (16 vCPU, 60 GB RAM) • 2xlarge* (32 vCPU, 128 GB RAM) • gpu-medium* (16 vCPU, 60 GB RAM, 1 GPU, 16 GiB GPU RAM) 詳細はドキュメントをご参照ください
  13. 27 2. 幅広いビルド環境をサポート 自分の用意した実行環境で CircleCIのジョブを実行 ・エージェントをインストー  ルすることで  CircleCIのジョブを実行 実行環境(サポート対象) ・Ubuntu

    18.04+(x86_64/ARM64) ・RHEL8 (x86_64/ARM64) ・Mac OS X 10.15+ (Intel) ・macOS 11.2+ (Apple M1) ・Docker (x86_64/ARM64) ・Kubernetes (x86_64) ・Windows Server 2019,2016 (x86_64) Dockerベースの実行環境 ・Linuxベースのコンテナを  実行可能 ・CircleCIからはCIに特化  した cimg/xxxxx イメージ  を提供 VMベースの実行環境 ・Linux(x86_64, aarch64) ・Windows ・macOS ・GPU(Linux/Windows with  Nvidia Tesla Tensor Core  GPU) Linux,Win,Mac ランナー x5 https://circleci.com/ja/blog/physical -computing-with-circleci-1/
  14. 28 3. チームでの開発生産性を高める セキュリティ認証 ・SOC 2 Type II 準拠 ・FedRAMP

    Tailored 認証 CircleCIの各種セキュリティに 関して https://circleci.com/ja/security/ Orb - 再利用可能な部品化 ・CircleCIでのCI/CDの定義は  コンフィグにYAML言語で  記述 ・コンフィグの一部分を切り  出し、他コンフィグで部品  と して使用可能(ノウハウ  共有) ・公開範囲はPublic(誰でも)  Private(組織内)を指定可能 誰もがプロジェクトに貢献 ・自分一人で始めることも、  組織のメンバーで始める  ことも、増減も自由 ・プロジェクトメンバー数に  上限はありません →アカウント共有のような  バッドノウハウ不要 ・OSSコミュニティには  毎月400,000クレジットを  無償付与 https://circleci.com/ja/open- source/ 無制限ユーザー 設定を社内共有 セキュアなCI/CD
  15. 29 3. チームでの開発生産性を高める セキュリティ認証 ・SOC 2 Type II 準拠 ・FedRAMP

    Tailored 認証 CircleCIの各種セキュリティに 関して https://circleci.com/ja/security/ Orb - 再利用可能な部品化 ・CircleCIでのCI/CDの定義は  コンフィグにYAML言語で  記述 ・コンフィグの一部分を切り  出し、他コンフィグで部品  と して使用可能(ノウハウ  共有) ・公開範囲はPublic(誰でも)  Private(組織内)を指定可能 誰もがプロジェクトに貢献 ・自分一人で始めることも、  組織のメンバーで始める  ことも、増減も自由 ・プロジェクトメンバー数に  上限はありません →アカウント共有のような  バッドノウハウ不要 ・OSSコミュニティには  毎月400,000クレジットを  無償付与 https://circleci.com/ja/open- source/ 無制限ユーザー 設定を社内共有 セキュアなCI/CD https://youtu.be/T9mr3LudDdQ
  16. 31 3. チームでの開発生産性を高める セキュリティ認証 ・SOC 2 Type II 準拠 ・FedRAMP

    Tailored 認証 CircleCIの各種セキュリティに 関して https://circleci.com/ja/security/ Orb - 再利用可能な部品化 ・CircleCIでのCI/CDの定義は  コンフィグにYAML言語で  記述 ・コンフィグの一部分を切り  出し、他コンフィグで部品  と して使用可能(ノウハウ  共有) ・公開範囲はPublic(誰でも)  Private(組織内)を指定可能 誰もがプロジェクトに貢献 ・自分一人で始めることも、  組織のメンバーで始める  ことも、増減も自由 ・プロジェクトメンバー数に  上限はありません →アカウント共有のような  バッドノウハウ不要 ・OSSコミュニティには  毎月400,000クレジットを  無償付与 https://circleci.com/ja/open- source/ 無制限ユーザー 設定を社内共有 セキュアなCI/CD
  17. 32 クラウドまたは専用環境のどちらかを選択可能 クラウド 開発者/ ユーザー VCS (GitHub.com または Bitbucket Cloud)

    データベース ビルドの
 フリート キャッシュ & 
 アーティファクト サーバー 顧客が管理するネットワーク内に 顧客専用のCircleCIをセットアップ 開発者/ ユーザー VCS (GitHub.com または GitHub Enterprise Server) データベース ビルドの フリート キャッシュ & アーティファ クト インスタンスのセットアップ、 セキュリティ、メンテナンスはすべて CircleCIが実施