Enviar pesquisa
Carregar
継続的デリバリー読書会 第 5 章 デプロイメントパイプラインの解剖学
•
7 gostaram
•
3,622 visualizações
Takuma SHIRAISHI
Seguir
Tecnologia
Denunciar
Compartilhar
Denunciar
Compartilhar
1 de 32
Baixar agora
Baixar para ler offline
Recomendados
継続的デリバリー読書会 第 7 章 コミットステージ
継続的デリバリー読書会 第 7 章 コミットステージ
Yasutomo Arai
デプロイメントパイプラインって何?
デプロイメントパイプラインって何?
ke-m kamekoopa
継続的デリバリー読書会資料 #1
継続的デリバリー読書会資料 #1
Yusuke HIDESHIMA
Cibc lecture imagire
Cibc lecture imagire
Takashi Imagire
【勉強会】パターンによるソフトウェア構成管理
【勉強会】パターンによるソフトウェア構成管理
zuisener .
ビジネス的に高価値なアジャイルテスト
ビジネス的に高価値なアジャイルテスト
Tsutomu Chikuba
JenkinsとjMeterで負荷テストの自動化
JenkinsとjMeterで負荷テストの自動化
Satoshi Akama
ITS fidel
ITS fidel
Fidel Softech P. Ltd
Recomendados
継続的デリバリー読書会 第 7 章 コミットステージ
継続的デリバリー読書会 第 7 章 コミットステージ
Yasutomo Arai
デプロイメントパイプラインって何?
デプロイメントパイプラインって何?
ke-m kamekoopa
継続的デリバリー読書会資料 #1
継続的デリバリー読書会資料 #1
Yusuke HIDESHIMA
Cibc lecture imagire
Cibc lecture imagire
Takashi Imagire
【勉強会】パターンによるソフトウェア構成管理
【勉強会】パターンによるソフトウェア構成管理
zuisener .
ビジネス的に高価値なアジャイルテスト
ビジネス的に高価値なアジャイルテスト
Tsutomu Chikuba
JenkinsとjMeterで負荷テストの自動化
JenkinsとjMeterで負荷テストの自動化
Satoshi Akama
ITS fidel
ITS fidel
Fidel Softech P. Ltd
PHP agile test tips
PHP agile test tips
Tsutomu Chikuba
nGrinder3 : だれもが簡単にできる性能テスト
nGrinder3 : だれもが簡単にできる性能テスト
JunHo Yoon
Automationtestssf beta
Automationtestssf beta
ryuji koyama
負荷対策しておもったことまとめ~JMeterでSocket.IOもいけるでよ~
負荷対策しておもったことまとめ~JMeterでSocket.IOもいけるでよ~
johgus johgus
テスト勉強会よしおか100311 1
テスト勉強会よしおか100311 1
Hiro Yoshioka
アジャイルテストを、壮絶に、考える。
アジャイルテストを、壮絶に、考える。
Dai FUJIHARA
【17-B-6】RIAの性能テストとアプリケーション品質向上のための管理手法
【17-B-6】RIAの性能テストとアプリケーション品質向上のための管理手法
Developers Summit
Software Test Basic
Software Test Basic
Akinari Tsugo
ソフトウェアテスト入門
ソフトウェアテスト入門
iKenji
GUI自動テストの保守性を高めるには
GUI自動テストの保守性を高めるには
Nozomi Ito
アジャイル×テスト開発を考える
アジャイル×テスト開発を考える
yasuohosotani
Automationtestssf beta2 architectureskill
Automationtestssf beta2 architectureskill
ryuji koyama
SGT2013 技術トークス「アジャイルテスティング」
SGT2013 技術トークス「アジャイルテスティング」
yasuohosotani
ハイパフォーマンスSeleniumテスト@サイボウズ
ハイパフォーマンスSeleniumテスト@サイボウズ
Jumpei Miyata
JaSST16tokyo tm_koyama
JaSST16tokyo tm_koyama
ryuji koyama
テスト環境まるごとAwsにのっけてみた
テスト環境まるごとAwsにのっけてみた
Kazuaki Fujikura
Jmeter20120421
Jmeter20120421
hatakyo
アジャイル開発におけるシステムテストの自動化
アジャイル開発におけるシステムテストの自動化
Toru Koido
キーワード駆動によるシステムテストの自動化について 2015
キーワード駆動によるシステムテストの自動化について 2015
Toru Koido
アジャイルテスト -高品質を追求するアジャイルチームにおけるテストの視点-
アジャイルテスト -高品質を追求するアジャイルチームにおけるテストの視点-
Satoshi Masuda
「継続的デリバリー」読書会 第3章 継続的デリバリー
「継続的デリバリー」読書会 第3章 継続的デリバリー
Norikazu Hiraki
ワンクリックデプロイ101 #ocdeploy
ワンクリックデプロイ101 #ocdeploy
Ryutaro YOSHIBA
Mais conteúdo relacionado
Mais procurados
PHP agile test tips
PHP agile test tips
Tsutomu Chikuba
nGrinder3 : だれもが簡単にできる性能テスト
nGrinder3 : だれもが簡単にできる性能テスト
JunHo Yoon
Automationtestssf beta
Automationtestssf beta
ryuji koyama
負荷対策しておもったことまとめ~JMeterでSocket.IOもいけるでよ~
負荷対策しておもったことまとめ~JMeterでSocket.IOもいけるでよ~
johgus johgus
テスト勉強会よしおか100311 1
テスト勉強会よしおか100311 1
Hiro Yoshioka
アジャイルテストを、壮絶に、考える。
アジャイルテストを、壮絶に、考える。
Dai FUJIHARA
【17-B-6】RIAの性能テストとアプリケーション品質向上のための管理手法
【17-B-6】RIAの性能テストとアプリケーション品質向上のための管理手法
Developers Summit
Software Test Basic
Software Test Basic
Akinari Tsugo
ソフトウェアテスト入門
ソフトウェアテスト入門
iKenji
GUI自動テストの保守性を高めるには
GUI自動テストの保守性を高めるには
Nozomi Ito
アジャイル×テスト開発を考える
アジャイル×テスト開発を考える
yasuohosotani
Automationtestssf beta2 architectureskill
Automationtestssf beta2 architectureskill
ryuji koyama
SGT2013 技術トークス「アジャイルテスティング」
SGT2013 技術トークス「アジャイルテスティング」
yasuohosotani
ハイパフォーマンスSeleniumテスト@サイボウズ
ハイパフォーマンスSeleniumテスト@サイボウズ
Jumpei Miyata
JaSST16tokyo tm_koyama
JaSST16tokyo tm_koyama
ryuji koyama
テスト環境まるごとAwsにのっけてみた
テスト環境まるごとAwsにのっけてみた
Kazuaki Fujikura
Jmeter20120421
Jmeter20120421
hatakyo
アジャイル開発におけるシステムテストの自動化
アジャイル開発におけるシステムテストの自動化
Toru Koido
キーワード駆動によるシステムテストの自動化について 2015
キーワード駆動によるシステムテストの自動化について 2015
Toru Koido
アジャイルテスト -高品質を追求するアジャイルチームにおけるテストの視点-
アジャイルテスト -高品質を追求するアジャイルチームにおけるテストの視点-
Satoshi Masuda
Mais procurados
(20)
PHP agile test tips
PHP agile test tips
nGrinder3 : だれもが簡単にできる性能テスト
nGrinder3 : だれもが簡単にできる性能テスト
Automationtestssf beta
Automationtestssf beta
負荷対策しておもったことまとめ~JMeterでSocket.IOもいけるでよ~
負荷対策しておもったことまとめ~JMeterでSocket.IOもいけるでよ~
テスト勉強会よしおか100311 1
テスト勉強会よしおか100311 1
アジャイルテストを、壮絶に、考える。
アジャイルテストを、壮絶に、考える。
【17-B-6】RIAの性能テストとアプリケーション品質向上のための管理手法
【17-B-6】RIAの性能テストとアプリケーション品質向上のための管理手法
Software Test Basic
Software Test Basic
ソフトウェアテスト入門
ソフトウェアテスト入門
GUI自動テストの保守性を高めるには
GUI自動テストの保守性を高めるには
アジャイル×テスト開発を考える
アジャイル×テスト開発を考える
Automationtestssf beta2 architectureskill
Automationtestssf beta2 architectureskill
SGT2013 技術トークス「アジャイルテスティング」
SGT2013 技術トークス「アジャイルテスティング」
ハイパフォーマンスSeleniumテスト@サイボウズ
ハイパフォーマンスSeleniumテスト@サイボウズ
JaSST16tokyo tm_koyama
JaSST16tokyo tm_koyama
テスト環境まるごとAwsにのっけてみた
テスト環境まるごとAwsにのっけてみた
Jmeter20120421
Jmeter20120421
アジャイル開発におけるシステムテストの自動化
アジャイル開発におけるシステムテストの自動化
キーワード駆動によるシステムテストの自動化について 2015
キーワード駆動によるシステムテストの自動化について 2015
アジャイルテスト -高品質を追求するアジャイルチームにおけるテストの視点-
アジャイルテスト -高品質を追求するアジャイルチームにおけるテストの視点-
Semelhante a 継続的デリバリー読書会 第 5 章 デプロイメントパイプラインの解剖学
「継続的デリバリー」読書会 第3章 継続的デリバリー
「継続的デリバリー」読書会 第3章 継続的デリバリー
Norikazu Hiraki
ワンクリックデプロイ101 #ocdeploy
ワンクリックデプロイ101 #ocdeploy
Ryutaro YOSHIBA
Continuous delivery chapter4
Continuous delivery chapter4
favril1
Gamedevenvstudy1
Gamedevenvstudy1
Takashi Kokawa
20160720 aws development-tools-and_hybrid_cdp
20160720 aws development-tools-and_hybrid_cdp
Yukitaka Ohmura
BDD Frameworkで回帰テストの自動実行を実現する方法
BDD Frameworkで回帰テストの自動実行を実現する方法
潤司 渡部
大規模ソフトウェア開発とテストの経験について
大規模ソフトウェア開発とテストの経験について
Rakuten Group, Inc.
Continuous delivery-9
Continuous delivery-9
LagerKorone
Terraformを活用した自動化デモ_F5-NGINX_Community-20200805
Terraformを活用した自動化デモ_F5-NGINX_Community-20200805
shinyatsukasaki
Awsで実現するseleniumテスト高速術
Awsで実現するseleniumテスト高速術
finoue
TDDBC osaka 2012/06/02
TDDBC osaka 2012/06/02
Hiro Yoshioka
云推送技术实现与敏捷开发
云推送技术实现与敏捷开发
kaerseng
TotalViewを使ったFOCUSスパコンでのデバッグ体験 2016
TotalViewを使ったFOCUSスパコンでのデバッグ体験 2016
RWSJapan
Provisioning & Deploy on AWS
Provisioning & Deploy on AWS
Amazon Web Services Japan
ぼくのかんがえた iOSテスト戦略
ぼくのかんがえた iOSテスト戦略
Naoki Umehara
Agile japan2010 rakuten様プレゼン資料
Agile japan2010 rakuten様プレゼン資料
Akiko Kosaka
OpenShift Ansbile 活用法 アプリケーションライフサイクルからみる導入効果
OpenShift Ansbile 活用法 アプリケーションライフサイクルからみる導入効果
Hideaki Tokida
ビルドプロセスとCI #STAC2014
ビルドプロセスとCI #STAC2014
Koji Hasegawa
HP_almqc_concepts20150701
HP_almqc_concepts20150701
Tsuyoshi Yumoto
企業におけるSpring@日本springユーザー会20090624
企業におけるSpring@日本springユーザー会20090624
Yusuke Suzuki
Semelhante a 継続的デリバリー読書会 第 5 章 デプロイメントパイプラインの解剖学
(20)
「継続的デリバリー」読書会 第3章 継続的デリバリー
「継続的デリバリー」読書会 第3章 継続的デリバリー
ワンクリックデプロイ101 #ocdeploy
ワンクリックデプロイ101 #ocdeploy
Continuous delivery chapter4
Continuous delivery chapter4
Gamedevenvstudy1
Gamedevenvstudy1
20160720 aws development-tools-and_hybrid_cdp
20160720 aws development-tools-and_hybrid_cdp
BDD Frameworkで回帰テストの自動実行を実現する方法
BDD Frameworkで回帰テストの自動実行を実現する方法
大規模ソフトウェア開発とテストの経験について
大規模ソフトウェア開発とテストの経験について
Continuous delivery-9
Continuous delivery-9
Terraformを活用した自動化デモ_F5-NGINX_Community-20200805
Terraformを活用した自動化デモ_F5-NGINX_Community-20200805
Awsで実現するseleniumテスト高速術
Awsで実現するseleniumテスト高速術
TDDBC osaka 2012/06/02
TDDBC osaka 2012/06/02
云推送技术实现与敏捷开发
云推送技术实现与敏捷开发
TotalViewを使ったFOCUSスパコンでのデバッグ体験 2016
TotalViewを使ったFOCUSスパコンでのデバッグ体験 2016
Provisioning & Deploy on AWS
Provisioning & Deploy on AWS
ぼくのかんがえた iOSテスト戦略
ぼくのかんがえた iOSテスト戦略
Agile japan2010 rakuten様プレゼン資料
Agile japan2010 rakuten様プレゼン資料
OpenShift Ansbile 活用法 アプリケーションライフサイクルからみる導入効果
OpenShift Ansbile 活用法 アプリケーションライフサイクルからみる導入効果
ビルドプロセスとCI #STAC2014
ビルドプロセスとCI #STAC2014
HP_almqc_concepts20150701
HP_almqc_concepts20150701
企業におけるSpring@日本springユーザー会20090624
企業におけるSpring@日本springユーザー会20090624
Último
クラウドネイティブなサーバー仮想化基盤 - OpenShift Virtualization.pdf
クラウドネイティブなサーバー仮想化基盤 - OpenShift Virtualization.pdf
FumieNakayama
モーダル間の変換後の一致性とジャンル表を用いた解釈可能性の考察 ~Text-to-MusicとText-To-ImageかつImage-to-Music...
モーダル間の変換後の一致性とジャンル表を用いた解釈可能性の考察 ~Text-to-MusicとText-To-ImageかつImage-to-Music...
博三 太田
AWS の OpenShift サービス (ROSA) を使った OpenShift Virtualizationの始め方.pdf
AWS の OpenShift サービス (ROSA) を使った OpenShift Virtualizationの始め方.pdf
FumieNakayama
NewSQLの可用性構成パターン(OCHaCafe Season 8 #4 発表資料)
NewSQLの可用性構成パターン(OCHaCafe Season 8 #4 発表資料)
NTT DATA Technology & Innovation
CTO, VPoE, テックリードなどリーダーポジションに登用したくなるのはどんな人材か?
CTO, VPoE, テックリードなどリーダーポジションに登用したくなるのはどんな人材か?
akihisamiyanaga1
業務で生成AIを活用したい人のための生成AI入門講座(社外公開版:キンドリルジャパン社内勉強会:2024年4月発表)
業務で生成AIを活用したい人のための生成AI入門講座(社外公開版:キンドリルジャパン社内勉強会:2024年4月発表)
Hiroshi Tomioka
自分史上一番早い2024振り返り〜コロナ後、仕事は通常ペースに戻ったか〜 by IoT fullstack engineer
自分史上一番早い2024振り返り〜コロナ後、仕事は通常ペースに戻ったか〜 by IoT fullstack engineer
Yuki Kikuchi
デジタル・フォレンジックの最新動向(2024年4月27日情洛会総会特別講演スライド)
デジタル・フォレンジックの最新動向(2024年4月27日情洛会総会特別講演スライド)
UEHARA, Tetsutaro
Último
(8)
クラウドネイティブなサーバー仮想化基盤 - OpenShift Virtualization.pdf
クラウドネイティブなサーバー仮想化基盤 - OpenShift Virtualization.pdf
モーダル間の変換後の一致性とジャンル表を用いた解釈可能性の考察 ~Text-to-MusicとText-To-ImageかつImage-to-Music...
モーダル間の変換後の一致性とジャンル表を用いた解釈可能性の考察 ~Text-to-MusicとText-To-ImageかつImage-to-Music...
AWS の OpenShift サービス (ROSA) を使った OpenShift Virtualizationの始め方.pdf
AWS の OpenShift サービス (ROSA) を使った OpenShift Virtualizationの始め方.pdf
NewSQLの可用性構成パターン(OCHaCafe Season 8 #4 発表資料)
NewSQLの可用性構成パターン(OCHaCafe Season 8 #4 発表資料)
CTO, VPoE, テックリードなどリーダーポジションに登用したくなるのはどんな人材か?
CTO, VPoE, テックリードなどリーダーポジションに登用したくなるのはどんな人材か?
業務で生成AIを活用したい人のための生成AI入門講座(社外公開版:キンドリルジャパン社内勉強会:2024年4月発表)
業務で生成AIを活用したい人のための生成AI入門講座(社外公開版:キンドリルジャパン社内勉強会:2024年4月発表)
自分史上一番早い2024振り返り〜コロナ後、仕事は通常ペースに戻ったか〜 by IoT fullstack engineer
自分史上一番早い2024振り返り〜コロナ後、仕事は通常ペースに戻ったか〜 by IoT fullstack engineer
デジタル・フォレンジックの最新動向(2024年4月27日情洛会総会特別講演スライド)
デジタル・フォレンジックの最新動向(2024年4月27日情洛会総会特別講演スライド)
継続的デリバリー読書会 第 5 章 デプロイメントパイプラインの解剖学
1.
継続的デリバリー読書会 第 5
章 デプロイメントパイプラインの解剖学 2012-‐08-‐28 2012-‐09-‐14 大崎的デリバリー @ts7i
2.
5.1 導入 • CI
の採用により生産性と品質が向上する • しかし CI だけでは十分ではない – CI は開発チームにフォーカス – その後のプロセス: テストとリリース • ここで問題が起きるとデプロイできない • 全体論的なエンドツーエンドのアプローチを採用して解決 – ビルド・デプロイ・テスト・リリースを自動化 – 最終的にできあがるのは「プルシステム」 • テストチームと運用チーム: ボタンを押すだけでデプロイ • 開発者とマネージャ: ビルドの進捗や問題が見える • デプロイメントパイプラインには一般的なパターンがある
3.
5.2 デプロイメント
パイプラインとは何か? #1 • 概要 – 「ソフトウェアをバージョン管理から取り出してユーザの手に渡すまでのプロ セスを自動化して表現したもの」 – ビルド → テスト → デプロイメント – さまざまなステージ、多くのメンバ、複数のチーム • バリューストリーム – 顧客の頭の中のフィーチャを引き出してその手に渡すまでのプロセス – 詳しくは『リーン開発の本質』を参照 – 本書で議論するのはバリューストリームの一部 (開発 → リリース) • 変更がデプロイメントパイプラインを通り抜ける – バージョンコントロール、ビルド & ユニットテスト、自動受け入れテスト、ユー ザ受け入れテスト、リリース – 不適切なビルドを早期のうちに排除する • リグレッションバグを避ける – リリースが反復の容易な「普通の」イベントになる • 最悪の場合も簡単に切り戻し可能
4.
5.2 デプロイメント
パイプラインとは何か? #2 • ステージ – コミットステージ • 技術レベルで検証する • コンパイル、ユニットテスト、コード解析 – 自動受け入れテストステージ • 機能および非機能レベルで検証する – 手動テストステージ • ユーザビリティと要件への適合度を検証する • 探索的テスト環境、インテグレーション環境、UAT 環境 – リリースステージ • システムをユーザにデリバリーする • 対象: パッケージ、ステージング環境、本番環境、…
5.
5.2.1 基本的なデプロイメント
パイプライン • P158 図 5-‐4 • 第一ステージ: コミットステージ – ユニットテスト、バイナリ生成、成果物リポジトリへ格納 – 並列実行可 • 第二ステージ: 自動受け入れテスト – コミットステージより時間がかかる (1-‐2 時間) – 並列実行可 • その後分岐: UAT、キャパシティテスト、本番 – 各チームが自分でデプロイできるよう自動化 • 目的はできる限り素早くフィードバックを受け取ること – CI サーバでパイプラインのどこまで通ったか確認
6.
5.3 デプロイメントパイプラインの
プラクティス • 各ステージについてより詳細に見る前に
7.
5.3.1 バイナリをビルドするのは
1 回限りとせよ • リコンパイルの問題 – 時間がかかる – バイナリの生成とリリースとの間に変更が紛れ込むリスク が発生する • 例: コンパイラのバージョン、依存ライブラリのバージョン、… • バイナリはコミットステージで 1 回ビルドすればいい – 派生物なのでバージョン管理には入れない – CI サーバが管理してくれる • 各環境に対して単一のバイナリで対応する – そうでなければビルドシステムが不必要に複雑になる
8.
5.3.2 あらゆる環境に対して
同じやり方でデプロイせよ • リリースのリスク低減 – 本番リリース実施までにデプロイメントプロセスが数百回 テストできる • 設定を分ける方法 – 環境ごとに別々のプロパティファイル準備する • バージョン管理対象 – その他 LDAP やデータベース + ESCAPE など • 詳しくは P79 を参照 • もしうまくいかなかった場合は以下のいずれがが原因 – アプリケーションに含まれる環境や固有のファイルの設定 – アプリケーションが依存しているやサービスの問題 – 環境の設定
9.
5.3.3 デプロイメントを
スモークテストせよ • (補足) スモークテストの定義 – hEp://www.atmarkit.co.jp/aig/04biz/smoketest.html • デプロイ時にアプリケーション稼働を確認するスモー クテストを自動スクリプトで実行 • シンプルなもので可 – アプリケーションを起動 → メイン画面に期待通りの内容 が表示されていることを確認 • アプリケーションが依存しているサービスが全て稼働 していることを確認 – データベース、メッセージバス、外部サービス • ユニットテストスイートの次に書くべき重要なテスト – アプリケーション起動しない場合の原因を診断できる
10.
5.3.4 本番のコピーに
デプロイせよ • テストと CI を本番環境にできるだけ似せた環境で行う 必要がある • 構成管理的に同一性を保証すべき項目 – 基盤 (ネットワークトポロジー、ファイアウォール設定、…) – OS 設定 (パッチ含む) – アプリケーションスタック – アプリケーションのデータ • 詳しくは 12 章 を参照 • プラクティスやツール – ディスクイメージング、仮想化 – Puppet、Install Shield (+ バージョン管理) • 詳しくは 11 章を参照
11.
5.3.5 各変更は直ちにパイプライン全
体を通り抜けなければならない • CI 以前: プロセスの各部分をバラバラにスケ ジューリング – hourly ビルド、daily 受け入れテスト、weekly キャパシ ティテスト、… • デプロイメントパイプライン: 各ステージ成功をト リガに次のステージ – CI サーバのスケジューリング機能重要 • ビルドとユニットテストの全てに対して自動受け入れテスト を実行するわけではない • ただし完全に自動化されたステージのみ – 手動テストなどは対象外
12.
5.3.6 パイプラインのどの部分であっても、
失敗したらラインを止めよ • 素早く反復可能で信頼できるリリースを達成 するために最も重要なプロセス – コードのチェックイン → ビルド成功とテスト通過を チームが確認すること – デプロイメントが失敗したら責任はチーム全体で 持つ
13.
5.4 コミットステージ • 5
分以内が理想 • ステップ – コンパイル – コミットテスト一式 – 後続ステージ向けバイナリ生成 – コード解析実行 • カバレッジ、重複コード、複雑度、結合度、警告数、 コードスタイル – 後続ステージ向け成果物生成
14.
5.4.1 コミットステージの
ベストプラクティス • 開発者はコミットステージが完了するのを待 つ – コミットステージさえ終われば以降のステージは 待つ必要なし • 「デプロイメントパイプライン」用語由来 – CPU のパイプライン命令並列実行 – 新しいフィーチャの開発と並行して実行
15.
5.5 自動受け入れテスト
という関門 • ユニットテストだけでは検出できない問題が ある – ユニットテストは開発者視点 • 受け入れテストステージの検証 – 顧客の期待する価値をシステムがデリバリーでき ていること – 受け入れ基準を満たしていること
16.
5.5.1 自動受け入れテストの
ベストプラクティス • 本番環境を想定 – 本番環境が複雑もしくは効果な場合はスケールダウン版の環境を使 う – 外部サービスはテストダブルで代替する • 詳しくは第 8 章 – 本番環境が複数ある場合はビルドグリッドを使う • クライアントアプリケーションなど • 受け入れテストはチーム全体のもの – プロダクションコードとテストスイートの保守チームを分けるべきでは ない • 受け入れテストはビジネスの言葉で表現されるべき – 実装の詳細に依存しない • バッドプラクティスに従うとコストの増大により自動化を断念するこ とに
17.
5.6 後に続くテストステージ • 多くの場合は手動テストを行う場合が望ましい
– 自動デプロイメントに進むことも可能だが • 各種環境へのデプロイ – 他システム統合テスト環境、キャパシティテスト環境、 探索的テスト環境、ステージング環境、本番環境、… – パイプラインの一環として各環境へのデプロイを管理 • テスターが任意のビルドを任意の環境へデプロイできる
18.
5.6.1 手動テスト • 受け入れ基準が満たされていることを手作業で
証明 – リグレッションテストではない • 人間のほうが優れている種類のテストに集中 – 探索的テスト – ユーザビリティテスト – 各プラットフォームでのルックアンドフィールの確認 – システム障害発生時の異常系テスト • 自動受け入れテストによってテスターが自由に 使える時間を作る
19.
5.6.2 非機能のテスト • 非機能要件
– キャパシティ、セキュリティ、SLA、… • 非機能要件のテストは自動化可能 – 詳しくは第 9 章 • 即時失敗 OR 人が判断 – 多くの場合は人が判断したほうが良い
20.
5.7 リリースに備える • 本番環境リリースのビジネスリスク
– 作業時の深刻な問題発生 – 切り戻し計画の不備 • デプロイメントパイプラインによる対応 – 全員でリリース計画 – 自動化でミスの影響を最小化 – 擬似本番環境でプロセスやテクノロジーを繰り返しデバッ グ – バックアウトできるようにしておく – 設定とデータ移行を更新と切り戻しのプロセスに組み込 む • 詳しくは第 10 章
21.
5.7.1 デプロイメントと
リリースを自動化する • デプロイメントのコントロールを妨げる制約 – 運用環境を完全にコントロールすることができない • クライアントアプリなど • → 対象環境の代表的なサンプルを用意して緩和 – 恩恵以上にコストがかかると見なされがち • → 本来は逆 • 本番環境の変更は自動化されたプロセスのみに限定すべ き – 詳しくは第 11 章 • 本番環境を管理するプロセスは他の環境にも使うべき • リリースプロセスの完成度が高まるとリスクが確実に低く なる – デプロイの繰り返しによる裏付け
22.
5.7.2 変更をバックアウトする • リリース失敗のリスクをバックアウト戦略で緩和する •
最善の戦略 – ひとつ前のバージョンをリリースの間も使えるようにしてお く • 詳しくは第 10 章 • データ移行の問題については第 12 章 • 次善の戦略 – 以前の適切なバージョンをデプロイし直す • まずい戦略 – デプロイ時と違う方法でのバックアウト – インクリメンタルなデプロイメントやロールバック
23.
5.7.3 成功を積み重ねる • 本番デプロイまでに以下が実現
– コンパイルできる – 開発者の期待通りに動く ← ユニットテスト – アナリストやユーザの期待通りに動く ← 受け入れテ スト – 環境の設定が適切に管理されている ← 本番と同様 のテスト – コンポーネントが揃っている ← デプロイ可能 – 本番に正常にデプロイ可能 ← 以前のステージでの デプロイ実績 – 手作業での操作が不要 ← 各環境でのデプロイ繰り 返し
24.
5.8 デプロイメントパイプラインを
実装する • インクリメンタルなアプローチ – バリューストリームをモデル化して、動くスケルト ンを作成する – ビルドとデプロイプロセスを自動化する – ユニットテストとコード解析を自動化する – 受け入れテストを自動化する – リリースを自動化する
25.
5.8.1 バリューストリームをモデリングし、
動くスケルトンを作成する • バリューストリームマップを書く – チェックインからリリースまで • CI プロセスとリリース管理ツールをモデル化 する • 実際に動かす – 新規プロジェクトの場合は「動くスケルトン」を作る • 最もシンプルな形式でコミットステージから受け入れテ ストステージまで通す • イテレーション 0 で実施する
26.
5.8.2 ビルドとデプロイメント
プロセスを自動化する • ビルド – ソースコードからバイナリ (多義的) を生成 – 誰かがチェックインするたびに CI サーバによって実 行 – バイナリの格納場所には CI サーバ経由でアクセス • デプロイメント – デプロイ先環境構築 – パッケージング – インストールと設定の自動化 – デプロイ結果検証の自動化 – 1 ボタンデプロイ化
27.
5.8.3 ユニットテストと
コード解析を自動化する • コミットステージ全体を実装 – チェックインのたびに、ユニットテスト、コード解析、… を実行 • ユニットテスト – 高速に実行 • 静的解析ツール – コーディングスタイル、コードカバレッジ、サイクロマ チック複雑度、結合度 • アプリケーションの複雑化に従って肥大化 – 並列実行で対応可能
28.
5.8.4 受け入れテストを
自動化する • テスト環境にデプロイするのに使ったスクリプトを再利 用する • 加えてスモークテスト後に受け入れテストフレーム ワークを起動する – 結果レポートを集積して分析する • 受け入れテストの分類 – 機能テスト – 非機能テスト • キャパシティ、スケーリング、… • 詳しくは第 9 章 • 少なくとも 1-‐2 項目はプロジェクトの初期に自動化す べき
29.
5.8.5 パイプラインを進化させる • プロジェクトの複雑化
→ バリューストリームの進化 – コンポーネント • 各コンポーネントのミニパイプライン → 組み合わせパイプライン • 詳しくは 13 章 – ブランチ • 詳しくは 14 章 • パイプライン構築のポイント – パイプライン全体を一度に実装する必要はない – プロセスのタイムスタンプと進捗を記録する – パイプライン自体を継続的に改善していく
30.
5.9 メトリクス • フィードバックを改善する方法
– サイクルを短くし、結果を見えるようにする – Informa^on Radiators • 何を計測すべきなのか – ホーソン効果: 計測対象がチームのふるまいに影響を与える – サイクルタイムが最も重要 – ToC を使って改善 • 制約条件 = ボトルネックを特定する • ボトルネック箇所のスループットを最大化する • 他のプロセスを制約に従属させる • 制約の限界を上げる • 最初に戻る – その他のメトリクス例 • カバレッジ、コードベースの特徴、欠陥数、ベロシティ、コミット数、ビルド数、ビルド失敗 数、ビルド時間、… • Panop^code による可視化の例 – チェックイン → レポート生成 → 内部 Web サイトで公開
31.
5.10 まとめ • デプロイメントパイプラインの目的
– 関係者全員にビルドの進捗を見えるようにすること • リリースプロセスのどこが非効率なのかがわか る – プロセスの最適化に取り組める • 基盤や規律の整備が必要 – 構成管理、自動スクリプト、自動テスト、… – 変更リリース手法の縛り • 詳しくは第 15 章
32.
感想 • 序盤にデプロイメントパイプラインの全体像が簡潔にまとまっている
– 使えそうな図いくつかあり • 重要かつ軽視されがちなプラクティス – バイナリをビルドするのは 1 回限りとせよ – あらゆる環境に対して同じやり方でデプロイせよ – デプロイメントをスモークテストせよ • 受け入れテストに関する記述は 8 章で具体的なコードを見てから読み返 すとわかりやすくなるはず • TODO: メトリクスに関する良い本を探す • サイクルタイム最重要を共通認識にできるか – そもそもたった数行修正してのリリースに数日のリードタイムがあることを問 題だと感じていない開発者が多そう • 残念ながら相変わらずクドい – 同じ章内ですら繰り返しが多い
Baixar agora