【CICD2021】デプロイメントパイプラインの原理原則を再確認する / Confirm Deployment Pipeline Principle

Transcript

1. デプロイメントパイプラインの原理原則を再確認する
   #CICD2021 #CICD2021_B
   髙市 智章 (Tomoaki Takaichi)
   Sep, 3, 2021 CI/CD Conference 2021 by CloudNative Days
   

   View Slide

2. 自己紹介
   @Takaichi00
   tomoaki.takaichi.5
   ・髙市 智章（タカイチ トモアキ）
   ・Java でのシステム開発
   ・CI / CD
   ・Container / k8s
   ・アジャイル開発実践
   共著: クリーンなコードへの
   SonarQube即効活用術
   http://u0u0.net/RSvx
   

   View Slide

3. ❏ なぜ CI / CD /デプロイメントパイプラインが必要なのか
   ❏ デプロイメントパイプライントについて
   ❏ 全体の流れ・実施するテストのテスト戦略・プラクティス
   ❏ 具体的なツールの利用方法、詳細な方法論というよりかは、デ
   プロイメントパイプラインでどういったことを意識して実行す
   べきかという点に着目
   ❏ 主に開発者の方を対象として想定しているが、プロダクトの開
   発に関わっている全ての方に対しても参考になれば幸い
   本日お話すること
   

   View Slide

4. CI / CD の必要性
   

   View Slide

5. ❏ 「LeanとDevOpsの科学」では、組織のパフォーマンス
   (収益性 / 市場専有率 / 生産性) は、「ソフトウェアデリバ
   リのパフォーマンス」が予測要因の一つとされている
   なぜ CI / CD を行う必要があるか
   出典: https://img.ips.co.jp/ij/18/1118101029/1118101029-520x.jpg 出典: https://d2l930y2yx77uc.cloudfront.net/production/uploads/images/17728222/picture_pc_7ad9d39bff46bb8813d1c7c8812fa5c9.png
   

   View Slide

6. ❏ 「ソフトウェアデリバリのパフォーマンス」を統計的に優位な
   形で改善できる24のケイパビリティの中に、「継続的インテグ
   レーション (CI) の実装」「継続的デリバリ (CD) の実践」が含
   まれている
   ❏ 組織のパフォーマンス(収益性 / 市場専有率 / 生産性)を向上さ
   せるために、CI / CD の実践は効果的である
   なぜ CI / CD を行う必要があるか
   組織のパフォーマンス
   CI / CD の実践
   向上
   

   View Slide

7. ❏ CI / CD を実践していないプロジェクトでは以下のような
   問題が往々にして起こりがち
   ❏ 何日も main ブランチにマージされずに機能開発が並行して
   行われ、リリース間際にマージ作業。しかしコンフリクトが
   多発し、マージしてもシステムが動作しないで遅延。
   ❏ リリース期限ギリギリに本番環境にデプロイ。しかし本番環
   境特有の設定値が考慮されておらず、外部システムと連携で
   きなかったり、パフォーマンスに問題が生じて遅延。
   CI / CD を実践しないとどうなるか
   

   View Slide

8. ❏ 継続的にコードをマージし、CI を実践することで常に動作する
   ソフトウェアを維持する
   ❏ トランクベース開発と組み合わせて実施することでより効果を発揮する
   ❏ 継続的にデプロイを行い、リリースによるリスクを早期に発見
   し対処する
   ❏ CI / CD を含めた、ソフトウェアの変更をバージョン管理シス
   テムに反映してからユーザーの手に渡すまでのプロセスをデプ
   ロイメントパイプラインと呼ぶ
   CI / CD のメリットは自動化だけではない
   

   View Slide

9. デプロイメントパイプラインの流れ
   

   View Slide

10. ❏ 「継続的デリバリー」の本では、デプロイメントパイプライン
    はいくつかのステージに分割されると記載されている
    ❏ ステージが進むにつれてリリースの自信が増し、環境がどんど
    ん本番に近づく一方、フィードバックは遅くなる
    デプロイメントパイプラインのステージ
    コミットステージ 受け入れステージ
    ユーザー受け入れ
    テスト
    キャパシティス
    テージ
    本番
    リリースに対する自信が増す・本番に環境が近くなる
    フィードバックは遅くなっていく
    

    View Slide

11. コミットステージ
    

    View Slide

12. ❏ コミットステージは、開発者が変更をバージョン管理シス
    テムに反映したタイミングで、最初に実行されるステージ
    ❏ 本番環境にデプロイするにはふさわしくないビルドを排除
    し、そもそもアプリケーションが壊れていないかというこ
    とを素早く知ることが目的
    コミットステージの概要
    バージョンコ
    ントロール
    コミットステージ 成果物
    リポジトリ
    開発者
    チェックイン 実行
    バイナリ
    レポート
    メタデータ
    

    View Slide

13. ❏ コミットステージでは以下のようなことを実施する
    コミットステージの内容
    1. 「コミットステージテスト」を実行する
    2. ソースコードの解析を行い、健全性をチェックする
    3. ビルドを実行する
    4. すべて問題なければ、生成されたリリース候補となる
    生成バイナリをアップロードする
    

    View Slide

14. ❏ 素早く実行できるように最適化されたテスト一式のこと
    ❏ ほとんどはユニットテストになる (xUnit 系)
    ❏ ユニットテスト以外のテストも少し選び出し、このス
    テージに含める (コンポーネントテストなど)
    ❏ コミットステージが通れば、アプリケーションが実際に動
    くのだと強い自信を持って言えるようにする
    コミットステージテスト
    

    View Slide

15. ❏ SonarQube などの静的解析ツールを実行し、コードカバ
    レッジ、Bug の恐れがあるコード、循環的複雑度などの統
    計情報を計測する
    ❏ 閾値を超えた場合はパイプラインを失敗させるといったこ
    とも考える
    ソースコードの解析
    項目 失敗させる設定例
    コードカバレッジ 70%未満
    Bugs の深刻度 (Severity) が
    Major 以上の項目
    1個以上
    コードの重複率 5%以上
    

    View Slide

16. ❏ 利用している商用ソフトウェアや OSS に脆弱性がないか
    を検査し、脆弱性があるものの利用を検知したらパイプラ
    インを失敗させる
    ❏ SourceClear のようなツールを利用する
    脆弱性チェック
    

    View Slide

17. ❏ コミットステージのすべてのステップが成功したときのみ、今
    後の受け入れステージや本番環境で利用するバイナリを成果物
    リポジトリ (Artifactory など) にアップロードする
    ❏ リリース候補となるバイナリを生成するのはコミットステージ
    の最後ただ一度きりにする
    ❏ デプロイ環境ごとにビルドはしない
    ❏ バイナリの再生成の際に何らかの変更が紛れ込んでしまうという
    リスク
    ❏ 再コンパイルに時間がかかりフィードバックが遅くなる
    リリース候補となるバイナリを生成する
    

    View Slide

18. ❏ CI はツールでなくプラクティスである。以下のような規律
    をチームで守ることで CI は実現される
    コミットステージのプラクティス
    1. 定期的に main ブランチにチェックインをする (最低でも1日2回)
    2. ビルドが壊れているときはチェックインしない
    3. コミットテストが通るまで次の作業を始めない
    a. 変更の記憶があるうちに素早くエラーを修正したい
    4. テストが失敗してもビルドは続ける
    a. テスト以外にも失敗要因はあるかもしれない
    5. 5分以内で終わるようにする (10分以上かかってはいけない)
    

    View Slide

19. 受け入れステージ
    

    View Slide

20. ❏ コミットステージで生成されたバイナリを擬似本番環境で
    実行させ、顧客の期待する価値をシステムがデリバリーで
    きていることを検証する
    受け入れステージの概要
    成果物
    リポジトリ
    受け入れステージ
    バイナリ
    成果物
    リポジトリ
    コミットステージ
    実行 レポート
    環境設定
    アプリ設定
    疑似本番環境用にデプロイするための設定
    バイナリ
    

    View Slide

21. ❏ コミットステージテストでは検証できないような、ビジネ
    ス視点での検証を本番とほぼ同じように動いているアプリ
    ケーションに対して行うことが目的
    受け入れステージの目的
    1. ユーザーの求める価値を提供しているか?
    2. 環境や設定ファイルに起因する問題はないか?
    3. 新しい変更によって既存のふるまいにバグが生じてい
    ないか?
    

    View Slide

22. ❏ 受け入れステージのテストは、受け入れ基準に基づき、エン
    ドユーザーにとって価値があるテストでなければならない
    ❏ Cucumber のような Garkin 記法という自然言語を用いてテ
    ストケースを記載できるツールを利用することもある
    受け入れステージのテスト
    

    View Slide

23. 1. 受け入れステージが失敗したら即座にチーム全体で修正する
    2. 自動受け入れテストは自分たちの開発環境で実行できるようにする
    a. 失敗した場合開発者のマシンで再現できなければならない
    3. 外部システムとすべて統合された環境で実行しない
    a. テストダブルを利用し、外部システムのふるまいはこちらで定義できように
    4. 受け入れテストは実行可能な仕様として機能するよう、ビジネスの
    言葉(ユビキタス言語)で表現する
    5. 本番環境と同じプロセスでデプロイを行う
    a. 自動デプロイメントのテストという意味合いもあるため
    受け入れステージのプラクティス
    

    View Slide

24. コミットステージと受け入れス
    テージの例
    

    View Slide

25. Kubernetes で実行されるアプリケーション の場合
    GitHub
    コミットテスト
    ソースコード解析
    脆弱性チェック
    ビルド/バイナリ生成
    Artifactory
    自動
    デプロイ
    kubernetes
    (疑似本番環境)
    自動受け入れテ
    スト
    テストの
    セット
    アップ
    DB
    (疑似本番環境)
    疑似外部システム
    ← 外部システムをスタブに切り替える
    テーブル再作成
    データ投入
    

    View Slide

26. コミットステージ・受け入れステージ
    テスト戦略
    

    View Slide

27. ❏ コミットステージ / 受け入れステージで実施するテストは
    どのように設計すればいいだろうか?
    どのようにテストを設計するか?
    コミットステージ 受け入れステージ
    ● 素早く実行できる
    ● そもそもアプリケーションは起動
    するか?
    ● 開発者視点のテスト
    ● 疑似本番環境で実行する
    ● 機能的な価値を満たしているか?
    ● 顧客視点のテスト
    

    View Slide

28. ❏ 「実践アジャイルテスト」では、アジャイルテストの4象
    限 / テストピラミッドを用いてソフトウェアにおけるテス
    トにはどのような種類があり、どう自動化すると良いかが
    説明されている
    アジャイルテストの4象限 / テストピラミッド
    出典: https://notta55.hatenablog.com/entry/2015/05/03/161631
    … EtoE, SystemTest (ST)
    … IntegrationTest (IT)
    と呼ばれることも
    

    View Slide

29. ❏ コミットステージでは主に Q1, 単体テスト/コンポーネントテストを
    実施する
    ❏ xUnit 系のテストで、クラスや関数に対してテストを実施することが
    多い (JUnit, PHPUnit など)
    ❏ 境界値試験など多くのテストケースが発生するテストはなるべくコ
    ミットステージで実施する
    コミットステージで実施するテスト
    出典: https://notta55.hatenablog.com/entry/2015/05/03/161631
    

    View Slide

30. ❏ 受け入れステージでは主に Q2, Q3, API レイヤー, GUI に対してのテ
    ストを実施する
    ❏ これらのテストは実行に時間がかかり、特に GUI のテストは少しの変
    更で壊れやすいため、単体テストほど厚くテストをしない
    ❏ 境界値試験のようなテストはあまり実施しないようにする
    受け入れステージで実施するテスト
    出典: https://notta55.hatenablog.com/entry/2015/05/03/161631
    

    View Slide

31. ❏ 近年コンピューターリソースが向上し、GUI を含むシステ
    ムテストや DB アクセスのコストが低下したことで生まれ
    た考え方
    テストアワーグラス (砂時計)
    ユニットテスト
    システムテスト
    インテグレーションテスト
    ❏ システムテストが少ないため、「なぜその機能が
    必要なのか」を忘れてしまう
    ❏ インテグレーションテストがあっても、今意味が
    ある機能なのかがわからないためメンテナンスコ
    ストが高くなってしまう
    テストピラミッドの欠点:
    

    View Slide

32. ❏ GUI テストは一般的に時間がかかるが、並列実行などで工夫す
    れば時間を短縮することができる
    ❏ 例えばメルカリ様では、Selenium Grid をベースに作られた
    Zalenium と Kubernetes を組み合わせることで、従来では1時
    間かかっていた GUI テストを 6~7 分で実施することに成功
    GUI テストの実行時間を短くする取り組み
    「メルカリWeb版のUIテスト自動化で目指している
    世界と、そのために作った Selenium
    Grid・Zalenium 環境 on Azure Kubernetes
    Service(AKS)」
    (https://engineering.mercari.com/blog/entry/2019
    -04-16-060000/)
    

    View Slide

33. ❏ 一般的なテストピラミッドの考え方は持ちつつも、システ
    ムの特徴にあったテスト戦略を考える
    ❏ 例) GUI を持たないアプリケーションでは、EtoE 試験を厚
    くしテストアワーグラスのような構造をとる
    ❏ 例) GUI テストが高速に実行できる基盤、ナレッジがある
    ので、GUI テストを厚くしテストアワーグラスのような構
    造をとる
    システムの特徴によってテスト戦略は変わる
    

    View Slide

34. テスト戦略の具体例をを考える
    ※発表者の見解であり、正解ではありません
    

    View Slide

35. ❏ SpringBoot、Thymeleaf を用いてサーバーサイドレンダ
    リングで簡単な GUI を提供し、画面操作を通じて DB の値
    を操作する管理システムの場合
    例: 簡単な GUI をもつ Java (SpringBoot) の管理システム
    DB
    サーバーサイドレンダリング
    

    View Slide

36. 例: 簡単な GUI をもつ Java (SpringBoot) の管理システム
    .Class
    コミットステージ
    .Class
    .Class
    .Class
    .Class
    Test
    MockMVC
    受け入れステージ
    ユニットテスト
    ※ MockMVC … アプリケーションサーバ上にデプ
    ロイすることなくSpring MVC の動作を再現できる
    Cucumber を使い自然言語でテストケース
    を記載
    Selenide を使って 自動 GUI テストを実行
    コンポーネントテスト
    (クラスを結合させて動作検証する)
    

    View Slide

37. ❏ それぞれのテストの割合はテストピラミッドの考え方に近
    づける
    例: 簡単な GUI をもつ Java (SpringBoot) の管理システム
    ユニットテスト
    (コミットステージ)
    コンポーネントテスト
    (コミットステージ)
    自動 GUI 受け入れテスト
    (受け入れステージ)
    

    View Slide

38. ❏ REST API を提供する複数の SpringBoot アプリケーショ
    ンからなるシステムの場合
    例: 複数の REST API からなるシステム
    DB
    REST API
    REST API
    App A App B
    

    View Slide

39. 例: 複数の REST API からなるシステム
    .Class
    コミットステージ
    .Class
    .Class
    .Class
    .Class
    Test
    受け入れステージ
    ユニットテスト
    API ごとの受け入れテスト
    App A
    App B
    (スタブ)
    App B DB
    API を結合させた受け入れテスト
    App A App B DB
    

    View Slide

40. ❏ それぞれのテストの割合はテストピラミッドの考え方に近
    づける
    例: 複数の REST API からなるシステム
    ユニットテスト
    (コミットステージ)
    API ごとの受け入れテスト
    (受け入れステージ)
    API を結合させた受け入れテスト
    (受け入れステージ)
    

    View Slide

41. ❏ Spring Boot CLI を用いて CLI アプリケーションを作成する
    例: CLI アプリケーション
    CLI
    .Class
    コミットステージ
    .Class
    .Class
    .Class
    .Class
    Test
    ユニットテスト
    受け入れステージ
    自動受け入れテスト
    受け入れ基準となるテストケースを元に、
    実際に CLI を実行して動作を検証する
    

    View Slide

42. ❏ CLI アプリケーションであり、自動受け入れテストのコス
    トテストの割合は低くなるため、それぞれのテストの割合
    はテストアワーグラスの考え方に近づける
    例: 複数の REST API からなるシステム
    ユニットテスト
    (コミットステージ)
    自動受け入れテスト
    (受け入れステージ)
    

    View Slide

43. テスト戦略の具体例をを考える
    ※発表者の見解であり、正解ではありません
    

    View Slide

44. キャパシティステージ
    

    View Slide

45. ❏ 受け入れステージの後、もしくは受け入れステージやユーザー受け入
    れテストと並列で実行するステージ
    ❏ ある変更がシステムのキャパシティに対して影響を及ぼしているかど
    うかを確認する
    ❏ キャパシティ: 一定の負荷がかかった状態で、個々のリクエストを許容範
    囲内のレスポンスでさばききれる最大スループット
    キャパシティステージの概要
    コミットス
    テージ
    受け入れス
    テージ
    ユーザー受け入
    れテスト
    キャパシティス
    テージ
    本番
    リリースに対する自信が増す・本番に環境が近くなる
    フィードバックは遅くなっていく
    

    View Slide

46. ❏ 非機能要件の扱いは以下のようになりがち
    ❏ 開発初期からあまり気を払わず、ある程度時間が経過したタ
    イミングで問題が発覚する
    ❏ 機能要件に比べて軽視されがちであり、問題がリリース終盤ま
    で発覚しない
    ❏ 過剰に非機能要件を意識してしまい、作り込みすぎてしまう
    ❏ 高速化のための可読性の低いトリッキーなコードが生まれてし
    まう (しかし本当に非機能要件を達成するために必要なコード
    かわからず、無駄なコストとなるかも)
    非機能要件の扱い
    

    View Slide

47. キャパシティステージの目的
    ❏ 開発初期にどの非機能要件が重要なのかを見つけ、計測す
    る方法を探し、可能であればデプロイメントパイプライン
    に組み込む
    ❏ キャパシティが低下していた場合、対象となる変更を特定できる
    ようにする
    ❏ パフォーマンスが要求されるシステムの場合、キャパシティ要件
    を満たせていない場合はパイプラインを失敗させる
    ❏ 本番環境でしか発生しないような不具合の事前検知、アプ
    リケーションや環境の設定値のチューニングの実施
    

    View Slide

48. ❏ 実際にありえるシナリオをテストする
    ❏ 既存の受け入れテストからいくつかピックアップ
    ❏ 個々のテストで成功したとみなせる条件を定義し、システムに負
    荷をかけた状態で閾値を満たせるかどうかを確認する
    ❏ 可能な限り、本番環境を再現したテスト環境を用意する
    ❏ 本番環境の再現が難しい場合は、等倍構成で実現できないか考える
    ❏ テストが成功となる閾値を事前に決めておき、テストが通
    るたびに閾値を微調整する
    キャパシティテストのプラクティス
    

    View Slide

49. デプロイ・リリース
    

    View Slide

50. ❏ 各疑似本番環境や本番環境に対し、アプリケーションや設
    定を反映し、必要であればユーザーへ公開する
    ❏ 各環境のデプロイ、ロールバックなどは、対象のバージョ
    ンを指定してボタンを押すだけで実行できるようにする
    デプロイ・リリースの概要
    コミットス
    テージ
    受け入れス
    テージ
    ユーザー受け入
    れテスト
    キャパシティス
    テージ
    本番
    ロールバック
    デプロイ
    

    View Slide

51. ❏ リリース戦略を初期に決定し、最初のリリースに向けて
    徐々にブラッシュアップする
    ❏ システム設計、ハードウェア環境の構成の決定
    ❏ 技術選定、各環境の決定、SLA やキャパシティの決定、リリース
    方式の決定
    ❏ これらを機能要件・非機能要件を決定する材料とする
    デプロイ・リリースのプラクティス
    ⇒ 受け入れステージやキャパシティステージなど、デプロイ
    メントパイプラインを構築する材料とする
    

    View Slide

52. ❏ 本番環境のデプロイメントは、他の環境のデプロイメント
    と同じ手順で実施する
    ❏ 各ステージで実施する疑似本番環境へのデプロイは本番環境への
    デプロイのテストでもある
    ❏ デプロイメントが正しく実施されたかどうかをスモークテ
    ストで確かめる
    ❏ 外部接続先など、本番の設定情報が正しく反映されており、アプ
    リケーションは動作する状態か?
    デプロイ・リリースのプラクティス
    

    View Slide

53. ❏ 障害などが発生しても本番環境を直接修正しない
    ❏ 障害対応を本番環境で実施してしまうと、二次・三次障害の原因
    になる
    ❏ 本番環境だけ違う状態となり、他の環境で検証できたプロセスが
    本番環境で再現しない
    ❏ 障害が発生しても素早くロールバックできる機構を作る
    ❏ ブルーグリーン・デプロイメントやカナリアリリース
    を取り入れることで実現可能
    ❏ 取り入れる必要があるかどうかも含めて判断
    ゼロダウンタイムリリース・ロールバック
    

    View Slide

54. ❏ 変更をできるだけ早く本番環境に投入することで、個々のリ
    リースのリスクを軽減することを目的とするのが継続的デプロ
    イメント
    ❏ 「本番環境への自動デプロイメント」をデプロイメントパイプラインの最
    終ステップに追加する
    ❏ アプリケーション全体を網羅した自動テストが必要
    ❏ 自動化され、繰り返し実行可能な状態にする
    ❏ 実際にはテストが通過する度に本番環境にリリースすることは
    なくても、やろうと思えばいつでもできるという状態を目指す
    継続的デプロイメント
    

    View Slide

55. デプロイメントパイプラインを
    活用する
    

    View Slide

56. デプロイメントパイプラインを実装するタイミング
    ❏ デプロイメントパイプラインのプロセスは、プロジェクトの
    最初のうちに整備したほうが、イテレーションを何度か行っ
    たあとに整備するのに比べて遥かにコストが低い
    ❏ プロジェクトの初期からデプロイメントパイプラインが整備されているこ
    とで、自動テストや自動受け入れテストが前提となる開発になり、結果よ
    い設計で開発が進み保守性が上がる
    ❏ イテレーション0 のような準備期間で、動くスケルトンをもとにデプロイ
    メントパイプラインを実装するのが理想
    ❏ プロジェクトの途中に導入する場合は、最も一般的で価値が
    高く、重要なユースケースから徐々に導入する
    

    View Slide

57. CI / CD はツールではなくプラクティス
    ❏ デプロイメントパイプラインを構築し、そこで様々なツールが
    駆使されていても CI / CD は実現されない
    ● ブランチを分けて開発者ごとに並行開発。イテレーションの最後にな
    らないと main ブランチにマージされず、イテレーションの最初はデ
    プロイメントパイプラインは実行されていない。イテレーションの最
    後はマージによるコンフリクトを修正するので精一杯。
    イテレーション
    開始
    イテレーション
    終了
    main branch
    コンフリクト
    地獄
    例...
    

    View Slide

58. CI / CD はツールではなくプラクティス
    ● コードの変更が main ブランチに加わるたびに SonarQube による
    コード解析が実行される。しかし開発者は機能開発に追われ、
    SonarQube を活用したアクションは何も取っていない。結果テストの
    カバレッジは2-30%, バグの恐れのあるコードがどんどん積み重なっ
    ていく。
    カバレッジ: 25%
    Bugs: 125件
    とにかく次イテ
    レーションのデモ
    ができるように機
    能開発優先だ！
    

    View Slide

59. CI / CD はツールではなくプラクティス
    ● 厳しいスケジュールの中で全ての機能要件を満たすため、リリースの
    ための作業はさておいて機能開発を優先して実施。イテレーションご
    とに擬似本番環境にデプロイしてデモは実施しているものの、それ以
    外は何もできていない。
    コミットステージ 受け入れステージ
    ユーザー受け入れ
    テスト
    キャパシティス
    テージ
    本番
    

    View Slide

60. CI / CD はツールではなくプラクティス
    ❏ そして以下のようなケースが訪れてしまうかもしれない
    ● リリースも間近になり、いざ性能試験を実施すると SLA を満たせない
    ことが判明。何が原因なのか、特定に時間がかかる。
    ● QA チームに指摘を受け、SonarQube を確認してみるとコード品質に
    問題があり、満足なテストも実施されていないためバグがあるかどう
    かもわからない
    ● なんとか修正を実施し、本番環境にデプロイ&リリース。しかし本番環
    境特有の設定値が考慮されておらず、アプリケーションはエラー頻
    発。緊急メンテナンスを実施し、ユーザー影響が出てしまう。
    

    View Slide

61. 炎上スプリント
    ❏ 機能開発以外のコストは忘れがちで、リリース前になって初めてリ
    リースコストの重大さに気づく。機能開発を進めていれば直感的には
    進捗が出ていると錯覚してしまう。
    ❏ 例: スクラムでのリリーススプリント (別名: 炎上スプリント)
    ● リスクと透明性の欠如
    ● 遅延と柔軟性の欠如
    出典: https://less.works/img/framework/undone-work/causing-risk-and-delay.png
    

    View Slide

62. プラクティスを理解して実践する
    ❏ 不確実なものを先延ばしにしてしまうという人間の本能を
    理解する
    ❏ デプロイメントパイプラインを早めに構築し、プラクティ
    スを実施することでリリースのリスクを徐々に下げていく
    ❏ 開発者だけでなく、ビジネスサイドも含めたプロダクトに
    関わる全ての人が CI / CD というプラクティスを理解する
    ことでより良いプロダクト開発ができるのでは
    

    View Slide

63. さいごに
    

    View Slide

64. ❏ 今回の発表ではデプロイメントパイプラインに関するプラ
    クティスと自分が経験した具体的な方法論についてご紹介
    した
    ❏ 今後はセキュリティテストをどうデプロイメントパイプラ
    インに組み込むか (DevSecOps) などにも挑戦したい
    ❏ 皆様が携わっている業務に少しでもお役に立てれば幸い
    さいごに
    

    View Slide

65. 継続的デリバリー
    参考書籍
    実践アジャイルテスト LeanとDevOpsの科学
    実践テスト駆動開発
    テスト駆動開発
    出典: https://img.ips.co.jp/ij/18/1118101029/1118101029-520x.jpg
    出典: https://images-na.ssl-images-amazon.com/images/I/51TkJaY4jPL._SX400_BO1,204,203,200_.jpg 出典: https://m.media-amazon.com/images/I/51v3XabFauL._SX260_.jpg
    出典: https://images-na.ssl-images-amazon.com/images/I/51hsd-b1RTL._SX350_BO1,204,203,200_.jpg 出典: https://images-na.ssl-images-amazon.com/images/I/61UOZrEZR6L._SX398_BO1,204,203,200_.jpg
    エンジニアリング組織論への招待
    出典: https://images-na.ssl-images-amazon.com/images/I/51zMvVL4MeL._SX351_BO1,204,203,200_.jpg
    

    View Slide

66. ご清聴ありがとうございました
    

    View Slide