Loading presentation...

Present Remotely

Send the link below via email or IM

Copy

Present to your audience

Start remote presentation

  • Invited audience members will follow you as you navigate and present
  • People invited to a presentation do not need a Prezi account
  • This link expires 10 minutes after you close the presentation
  • A maximum of 30 users can follow your presentation
  • Learn more about this feature in our knowledge base article

Do you really want to delete this prezi?

Neither you, nor the coeditors you shared it with will be able to recover it again.

DeleteCancel

Make your likes visible on Facebook?

Connect your Facebook account to Prezi and let your likes appear on your timeline.
You can change this under Settings & Account at any time.

No, thanks

継続的デリバリー読書会で学んだ事、そして実践からわかった事

No description
by

厚輝 神谷

on 19 November 2013

Comments (0)

Please log in to add your comment.

Report abuse

Transcript of 継続的デリバリー読書会で学んだ事、そして実践からわかった事

(@kami_teru)
継続的デリバリー
読書会で学んだ事、
そして実践して
わかった事

継続的デリバリー
読書会で学んだ事、
そして実践して
わかった事

神谷厚輝
twitter: @kami_teru
facebook: /teru.k.smile
これから話すこと。
そのまえに...Myコンテキスト
①「継続的デリバリー」

②読書会での解釈

③『で、こうした』の話

④私(カミヤ)の解釈

謝辞
このプレゼンテーションの画像素材の一部は
以下のサイトの公開作品を利用させていただきました。
産業-工業-製造業 フリーイラスト素材
http://industry-illustration.com/
受託開発屋さんで
技術リーダー的
立ち位置。

メーカーさんのプロジェクトで
「アプリ基盤」請負中。

コレ私・・・?→
『 ア プ リ 基 盤 』
名はともかく。
プロジェクトを円滑に進める
ために業務屋さんとインフラ
屋さんの架け橋になりつつ、
システム全体を美しく保つ為
に結成されたチームの事です。

目指すは
システムアーキテクト。

第1章

ソフトウェアデリバリー
の問題

第2章

構成管理

第3章

継続的
インテグレーション

第4章

テスト戦略を実装する

第5章

デプロイメント
パイプラインの解剖学

第6章

ビルド・デプロイメント
スクリプト

第7章

コミットステージ

第8章

自動受け入れテスト

第9章

非機能要件をテストする

第10章

アプリケーションを
デプロイ・リリースする

第11章

基盤と環境を管理する

第12章

データを管理する

第13章

コンポーネントや
依存関係を管理する

第14章

高度なバージョン管理

第15章

継続的デリバリーを
管理する

そもそもなぜ
継続的デリバリーの
実践を考え始めたのか
きっかけのお話
◆ソフトウェアを手作業でデプロイする
もっとうまくやれる方法を探して...
◆開発が終わってから疑似本番環境にデプロイする
◆本番環境について手作業で構成管理を行う
リリースによくある
アンチパターン
(P40-P47)
◆あの人が居ないから配備できないですー
◆自分の環境では動いてたんですが...
◆手で差し替えてるから、
 1から再配備なんてできない!
もうやめよう
そんなこと!!
ソフトウェアの生成に関連する成果物をひとつ残らずバージョン管理の下に置かなければならないのだ。
構成管理の基本
ひとつ残らず
すべてバージョン管理に
保存せよ
(P71)
ひとつ残らず!!
ひとつ残らず???
◆ソースコード
◆外部ライブラリ(コンパイル用)
◆ビルドスクリプト
◆統合ビルドスクリプト
◆外部ライブラリ(実行用)
◆各種設定ファイル(web.xmlとか)
◆帳票定義体
SVNに登録!!
ひとつ残らず!!
◆ソースコード
◆外部ライブラリ(コンパイル用)
◆ビルドスクリプト
◆統合ビルドスクリプト
◆外部ライブラリ(実行用)
◆環境毎のプロパティファイル
◆帳票定義体
trunk/
package-fixes/
package-build/
◆Frameworkライブラリ
◆各種設定ファイル(web.xmlとか)
1.バージョン管理
始める前に必要なもの
継続的インテグレーションを始められるようにする上で、必要なものが三つある。
(P97-P98)
2.自動ビルド
3.チームの合意
◆ビルドが壊れているときはチェックインするな
基本的なプラクティス
ここに挙げるプラクティスは
継続的インテグレーションを
機能させる上で必須のものである。
(P107-P113)
他にもあったけど、上記3つは話のPoint!!
◆コミットする前に、常にローカルで
 コミットテストを実行せよ。
 あるいは代わりにCIサーバーにやってもらえ。
◆テスト駆動開発
◆コンパイルが通らない時(当然ですねー)
「ビルドが壊れているとき」の定義
私は、他人に迷惑がかかる時のことだと思ってる。
下の2つもとても重要だと思うのです。

作り手の思い通りに動作しない

(@kami_teru)

クリーンな環境でコンパイルが通らない

◆ユニットテストをきっちり書いておく
作り手の思い通りに動作することの保証
作り手の書いたコードが
思い通りに動作している
ことを保証するには。
・・・であると理解しているのです。
◆テスト駆動開発はそれを実現するためのベストな手段
◆なのでテスト駆動開発は継続的インテグレーションの必須プラクティス
◆機械が自動的に行う。これが繰り返し
 成功していることによって得られる信頼は絶大。
クリーンな環境でコンパイルが通る保証
おれおれ環境は信用しない。
信用できる環境においてコンパイルが通ることを保証するには。
と、いうわけで →
◆これを実現してくれるのがCIサーバー。
◆なので代わりにCIサーバーにやってもらうことは継続的インテグレーションの必須プラクティス
チェックイン
自動ビルド
自動ユニットテスト
成否はフィードバック
壊れていないモノだけが
チェックインされた
バージョン管理
SVN
git push!!
1.ユニットテスト
開発プロセスをサポートする技術視点のテスト
このカテゴリーに当てはまるものには3種類ある。
2.コンポーネントテスト
3.デプロイメントテスト
(P133-P134)
ユニットテスト
◆ファイルアクセス禁止!
非常に高速に実行でき、変更によって既存の機能が壊れていないかということについてのフィードバックを素早く受け取ることができるのだ。
(P133)
◆データベースアクセス禁止!!
◆そのためにモックを利用。
非常に高速に実行できるためにやったこと。
コンポーネントテスト
コンポーネントテストで合目的性を担保!(自動化できる範囲に限る) 
◆ユニットテストはコーディングの手法。
テスト駆動で作るユニットテストは合目的性を担保するテストではないですよね。
(@kami_teru)
◆機能全体を通して目的に合った結果を得られるかという観点で不十分。
◆データベースやファイルアクセスも行う。
私の考え。
◆コンポーネントテストは0件、1件、N件、ブレイク、境界値、といった切り口でテストを書く。
デプロイメントテスト
詳しくは後述。
アプリケーションが正しくインストールされ、正しく設定され、必要なサービスと接続できて、レスポンスが戻ってくることを確認するのだ。
(P134)
関連キーワード:スモークテスト
デプロイメントパイプラインとは何か?
抽象的に言えば、(中略)ソフトウェアをバージョン管理から取り出してユーザーの手に渡すまでのプロセスを自動化して表現したものだ。
(P153)
バージョン
コントロール
コミット
ステージ
受け入れテスト
ステージ
手作業
受け入れテスト
・キャパシティ
ステージ
リリース
ステージ
(本番)
コンパイル
ユニットテスト
分析
バイナリのビルド
バイナリデプロイ
環境設定
デプロイメントテスト
自動受け入れテスト
バイナリデプロイ
環境設定
デプロイメントテスト
(手作業)UAT
自動性能テスト

バイナリデプロイ
環境設定
デプロイメントテスト
継続的インテグレーション
デプロイメントパイプライン
チェックイン
継続的デリバリーを構成するステージ:
◆バイナリをビルドするのは1回限りとせよ
デプロイメントパイプラインのプラクティス
このアプローチによる恩恵を受けるためには、いくつかのプラクティスに従わなければならない。
(P159-P166)
他にもあったけど、上記3つは話のPoint!!
◆あらゆる環境に対して同じやり方でデプロイせよ
◆デプロイメントをスモークテストせよ
Why?
もう一つの大事なお話
何があっても、デプロイするときと
違う方法でバックアウトを行ったり、インクリメンタルなデプロイメントやロールバックを行ったりしては
ならない。
(P179)
詳細は後述。
デプロイ済みの旧バージョンを保持するか、ひとつ前の動くとわかっているバージョンからデプロイし直すか、(中略)このどちらかにしよう。
Why?
ビルド・デプロイメントスクリプトいろいろ
Make,Ant,Maven,MSBuild,Rake...
これらに代表されるようなビルドツールはビルド・デプロイメントスクリプトで利用可能な技術です。
(@kami_teru)
Script力重要!私はAnt使いました。
バージョン
コントロール
コミット
ステージ
受け入れテスト
ステージ
手作業
受け入れテスト
・キャパシティ
ステージ
リリース
ステージ
(本番)
コンパイル
ユニットテスト
分析
バイナリのビルド
バイナリデプロイ
環境設定
デプロイメントテスト
自動受け入れテスト
バイナリデプロイ
環境設定
デプロイメントテスト
(手作業)UAT
自動性能テスト

バイナリデプロイ
環境設定
デプロイメントテスト
継続的インテグレーション
デプロイメントパイプライン
チェックイン
スクリプトが必要な個所:
◆デプロイメントパイプラインのステージ それぞれに対してスクリプトを書け
ビルドスクリプトとデプロイメントスクリプトの原則とプラクティス
一般的な原則と
プラクティスを紹介する
(P200-P206)
他にもあったけど、上記3つはお気に入り!!
◆アプリケーションをデプロイするのに
 適切なテクノロジーを使え
Why?
Script!
Script!
Script!
Script!
◆すべての環境にデプロイするのに、
 同じスクリプトを使え
コミットステージで集中すべきこと
コミットステージの主な目的は、デプロイ可能な成果物を作ることであると同時に、早め早めに失敗させて、その理由をチームに伝えることでもある。
(P223)
コミットステージの実行は5分以内で終わるのが
理想であるし、10分以上かかってはならない。
バージョン
コントロール
コミット
ステージ
受け入れテスト
ステージ
手作業
受け入れテスト
・キャパシティ
ステージ
リリース
ステージ
(本番)
コンパイル
ユニットテスト
分析
バイナリのビルド
バイナリデプロイ
環境設定
デプロイメントテスト
自動受け入れテスト
バイナリデプロイ
環境設定
デプロイメントテスト
(手作業)UAT
自動性能テスト

バイナリデプロイ
環境設定
デプロイメントテスト
継続的インテグレーション
デプロイメントパイプライン
チェックイン
継続的デリバリーを構成するステージ:
◆ユーザーインターフェースを避けよ
コミットテストスイートの原則とプラクティス
素早く実行できるコミットテストを設計することは、簡単ではないこともある。いくつか戦略がある。
(P230)
テスト戦略「ユニットテスト」の自動実行
⇒「コミットテスト」の第一歩。
◆データベースを避けよ
ここ!
(P221)
UIは人間の時間間隔に合わせて動くように設計されている
実行するのに極端に時間がかかる
コミットステージの結果
コミットステージのアウトプットは、どこかに格納しておいて、パイプラインの後のステージで再利用できるようにする必要がある。
(P227)
バージョン
コントロール
コミット
ステージ
受け入れテスト
ステージ
手作業
受け入れテスト
・キャパシティ
ステージ
リリース
ステージ
(本番)
コンパイル
ユニットテスト
分析
バイナリのビルド
バイナリデプロイ
環境設定
デプロイメントテスト
自動受け入れテスト
バイナリデプロイ
環境設定
デプロイメントテスト
(手作業)UAT
自動性能テスト

バイナリデプロイ
環境設定
デプロイメントテスト
継続的インテグレーション
デプロイメントパイプライン
チェックイン
(P228 「図7-2 成果物リポジトリの役割」を説明用に書き換えています)
成果物
自動受け入れテストがなぜ必要か?
自動受け入れテストをユーザー視点から見たシステムのふるまいを保証するテストとして用いれば、リグレッションによる問題に対する計り知れない防御策となる。
(P279)
テスト戦略「コンポーネントテスト」の自動実行
⇒「自動受け入れテスト」の第一歩。
バージョン
コントロール
コミット
ステージ
受け入れテスト
ステージ
手作業
受け入れテスト
・キャパシティ
ステージ
リリース
ステージ
(本番)
コンパイル
ユニットテスト
分析
バイナリのビルド
バイナリデプロイ
環境設定
デプロイメントテスト
自動受け入れテスト
バイナリデプロイ
環境設定
デプロイメントテスト
(手作業)UAT
自動性能テスト

バイナリデプロイ
環境設定
デプロイメントテスト
継続的インテグレーション
デプロイメントパイプライン
チェックイン
継続的デリバリーを構成するステージ:
ここ!
非機能要件で自動化できること
非機能要件が重要なのは、それがソフトウェアプロジェクトのデリバリーに関する重大なリスクとなるからである。(中略)
非機能要件の中でも特に、キャパシティとスループットそしてパフォーマンスに重点を置く。
(P281)
バージョン
コントロール
コミット
ステージ
受け入れテスト
ステージ
手作業
受け入れテスト
・キャパシティ
ステージ
リリース
ステージ
(本番)
コンパイル
ユニットテスト
分析
バイナリのビルド
バイナリデプロイ
環境設定
デプロイメントテスト
自動受け入れテスト
バイナリデプロイ
環境設定
デプロイメントテスト
(手作業)UAT
自動性能テスト

バイナリデプロイ
環境設定
デプロイメントテスト
継続的インテグレーション
デプロイメントパイプライン
チェックイン
継続的デリバリーを構成するステージ:
ここ!
キャパシティテスト自動化のうまい作戦
キャパシティテストは壊れやすく複雑
になりがちで、ソフトウェアにほんの少し変更が加わるだけで簡単に動かなくなってしまう(中略)
うまい作戦
のひとつとしては、
既存の受け入れテストからいくつかピックアップ
してそれをキャパシティテスト用に書き換えるという方法がある。
(P295)
コンポーネントテストの一部を流用し自動実行
⇒「キャパシティテスト」実現の近道。
デプロイとリリースの違い
ソフトウェアを本番環境にリリース
するのと、テスト環境へデプロイするのとではわけが違う。
(P307)
デプロイメントとリリースの主な違いは
ロールバックの方法である。
バージョン
コントロール
コミット
ステージ
受け入れテスト
ステージ
手作業
受け入れテスト
・キャパシティ
ステージ
リリース
ステージ
(本番)
コンパイル
ユニットテスト
分析
バイナリのビルド
バイナリデプロイ
環境設定
デプロイメントテスト
自動受け入れテスト
バイナリデプロイ
環境設定
デプロイメントテスト
(手作業)UAT
自動性能テスト

バイナリデプロイ
環境設定
デプロイメントテスト
継続的インテグレーション
デプロイメントパイプライン
チェックイン
継続的デリバリーを構成するステージ:
ここ!
1.直近の正常動作するバージョンの再デプロイよる
 ロールバック
ロールバックに関するヒント
万一問題が発生した場合にデプロイメントをロールバックできるようにしておくことが極めて重要だ。
(P317)
ロールバックについてもスクリプトによる自動化を行い、
開発時から何度も利用することで信頼性を高めておきましょう。
2.古いファイルは削除せず、移動せよ
直近のバージョンの再デプロイは所要時間のわかっている作業であり、よりリスクが低くなる。
新たなバージョンのデプロイメントや旧バージョンへのロールバックは、単にシンボリックリンクが指す先を変更するだけの作業となる。
なのでPointだけ...
ここは・・・省略!
ここは危険だ。足を踏み入れると
時間が足りなくなる。
(@kami_teru)
環境をどう調達するかは押さえておくべきPoint!!
すべてのステージ環境は
仮想化技術上で動作
しており、
いつでも
初期イメージからデプロイ直前の状態に復元
することができます。
ここもPointだけ...
ここも・・・省略!
ここは危険だ。足を踏み入れると
…以下略(笑
(@kami_teru)
データベースのロールバックは難しい問題です。
◆データベースの初期作成はスクリプトで行っており、
 スクリプトもバージョン管理を実施。
◆変更も全てスクリプトで。もちろんバージョン管理。
◆リリースのロールバック時、DBは戻さなくても
 よいように、修正方法で配慮している。
継続的
インテグレーション
のお話

継続的
インテグレーション
のお話

継続的
インテグレーション
のお話

継続的デリバリー
のお話

デプロイメント
パイプライン
のお話

デプロイメント
パイプライン
のお話

デプロイメント
パイプライン
のお話

デプロイメント
パイプライン
のお話

デプロイメント
パイプライン
のお話

デプロイメント
パイプライン
のお話

デプロイメント
パイプライン
のお話

デプロイメント
パイプライン
のお話

継続的デリバリー
のお話

継続的
インテグレーション
のお話

継続的デリバリー
のお話

1.
コンポーネント

ライブラリ
依存関係について考える
2.
ビルド時の依存関係

実行時の依存関係
(P416)
コンポーネント

ライブラリ
の区別
◆ライブラリとは、ソフトウェアパッケージの中でも、 自分たちのチームでは制御しようのないものを指す。
 (中略)通常はめったに更新されることがない。
(P416)
◆コンポーネントとは、(中略)開発するのは
 自分たちのチームか自組織内の別のチームである。
 (中略)通常は頻繁に更新される。
Point!!
ライブラリはめったに更新されない
ビルド時の依存関係

実行時の依存関係
の区別
デプロイメントパイプラインでは

実際にデプロイするアプリケーション
以外にも
さまざまなソフトウェアを
使う
ことになる。
(中略)テストフレームワーク、そして
ビルドスクリプティングフレームワーク
などである。
(P416)
Point!!
ライブラリは少なくとも
ビルド時用と実行時用といった
複数管理が必要である。
依存地獄に陥らないためのシンプルな解決策
ライブラリをバージョン管理システムに
チェックインするのが最もシンプルな解決策であり、
小規模なプロジェクトならこれでうまくいくだろう。build、test、そしてrunという3つのサブディレクトリ
を作ることをお勧めする。
(P419)
私はこんな感じ。
◆ソースコード
◆外部ライブラリ(コンパイル用)
◆ビルドスクリプト
◆統合ビルドスクリプト
◆外部ライブラリ(実行用)
◆環境毎のプロパティファイル
◆帳票定義体
trunk/
package-fixes/
package-build/
◆各種設定ファイル(web.xmlとか)
build,test
(Antで参照を区別)
run
コンポーネントの依存関係はどうする?
コンポーネント間の関係をうまくさばけなければ、そのコンポーネントを継続的インテグレーションに組み込んで使うのが難しくなる。
実にシンプルであり、驚くほどスケールする方法は、アプリケーション全体を扱うひとつのパイプラインを用意することだ。(中略)
システム全体をひとまとめにしたビルドをお勧めする

インテグレーションパイプラインの定義
インテグレーションパイプラインとはシステムを構成する各コンポーネントをまとめた
リポジトリ
を作るための
仕組みである(とする)。
(@kami_teru)
バージョン
コントロール
(リポジトリ)
コミット
ステージ
受け入れテスト
ステージ
手作業
受け入れテスト
・キャパシティ
ステージ
リリース
ステージ
(本番)
コンパイル
ユニットテスト
分析
バイナリのビルド
バイナリデプロイ
環境設定
デプロイメントテスト
自動受け入れテスト
バイナリデプロイ
環境設定
デプロイメントテスト
(手作業)UAT
自動性能テスト

バイナリデプロイ
環境設定
デプロイメントテスト
継続的インテグレーション
デプロイメントパイプライン
チェックイン
継続的デリバリーを構成するステージのおさらい:
ここ!
Point!!
(P421)
◆ライブラリはすべてバージョン管理へ投入。
◆コンポーネントもすべて同一のバージョン管理へ投入し、システム全体としてフルビルドを実施。
→「インテグレーションパイプライン」の構築!
インテグレーションパイプライン
インテグレーションパイプライン
のイメージ
バージョン
コントロール
(リポジトリ)
コミット
ステージ
手作業
開発チーム
動作確認
ステージ
手作業
受け入れテスト
・キャパシティ
ステージ
リリース
ステージ
(本番)
コンパイル
バイナリのビルド
バイナリデプロイ
環境設定
デプロイメントテスト
手動動作確認
バイナリデプロイ
環境設定
デプロイメントテスト
(手作業)UAT
(手作業)性能テスト

バイナリデプロイ
環境設定
デプロイメントテスト
デプロイメントパイプライン(システム全体)
インテグレーションパイプライン(コンポーネントA)
git push
Git
バージョン
コントロール
(リポジトリ)
インテグレーションパイプライン(コンポーネントB)
git push
Git
SVN
SVN
コンパイル
ユニットテスト
コンポーネントテスト
最新ライブラリ取得
最新コンポーネント取得
差分コンポーネント登録
継続的インテグレーションの最も重要なプラクティスは、全員が少なくとも一日一度はメインラインにチェックインするということだ。
ブランチの利用と継続的インテグレーション
チーム内のメンバーがそれぞれ別のブランチやストリームで作業をしているということは、明らかに継続的インテグレーションを行っていないということだ。
開発をメインラインで行っていなければならない。ブランチを作ってそこで作業を進め、作業が完了したときにそれをマージする(中略)方法はあくまで次善の策ととらえている。
(P457)
ブランチとマージに対する意見をもうすこし
◆たとえば、新たなフィーチャの開発を始めるときには
 毎回ブランチを作るようにする。これは「早期ブランチ」
 の一例である。(中略)単に
大変なマージ作業を先送り
して
 いるにすぎない。
◆ブランチの作成をできるだけ控え、リリースごとに
 ひとつずつ程度にする。これは「遅延ブランチ」の
 一例である。(中略)
マージを定期的にやること

 忘れてはならない。
(P457)
Point!!
とにかく
メインライン(trunk)こそが信頼できる絶対の最新
であるように
しなさいということだと理解。
(P457)
(P411)
ブランチ否定!?
やはり苦言を呈している…!?
最善のブランチ戦略のヒント
より理解しやすいブランチ方針は、寿命の長い
ブランチをリリース時にだけ作るというものだ。
(リリースブランチ戦略)このモデルでは、
新しい作業は常にtrunkにコミットされる。
(P458)
で、私のブランチ戦略がこれ↓
trunk/
branches/
(任意の名前)/
tags/
開発者動作確認ステージ/
UATステージ/
リリースステージ/

tags/release/
…常に最初にコミットされる場所。
…実験したいとき、trunkから派生させてよい場所。
 コミット可。ただしtrunkへのマージは認めない。
…各ステージに配備するブランチ・
 リビジョンのタグを切る場所。
 trunk、branchesいずれからも可。
 必ずDelete&Copyで作成する。
 マージは禁止。
…リリースステージのtagの履歴保管場所。
私のブランチ戦略(基本概念)
trunk/
branches/
(任意の名前)/
tags/
開発者動作確認ステージ/
UATステージ/
リリースステージ/

tags/release/
…常に最初にコミットされる場所。
…実験したいとき、trunkから派生させてよい場所。
 コミット可。ただしtrunkへのマージは認めない。
…各ステージに配備するブランチ・
 リビジョンのタグを切る場所。
 trunk、branchesいずれからも可。
 必ずDelete&Copyで作成する。
 マージは禁止。
…リリースステージのtagの履歴保管場所。
Point!!
◆どんな修正であれ、メインライン(trunk)に入れられないような修正は
 すべきでない。たいてい、修正の単位を見直すことで回避可能なはずだ。
◆リリースステージのtagをbranchesから作り始めると危険信号。
◆各ステージのtagは、開発者動作確認、UAT、リリースの順に同じ
 元ブランチ・リビジョンを参照したものが設定されていくはずだ。
※実際はUATステージが「障害系」「要望系」「出荷確認用」に分かれて
いたりしてもうちょっと複雑ですが、この基本概念でやりくり出来ています。
もしよければ...
ここは・・・今日の範囲外!
勉強会の趣旨が異なってくるので
省略します。
(@kami_teru)
書籍「継続的デリバリー」は本当に勉強になる一冊です。
◆構成管理やリリース管理の成熟期モデル等の記載があり
 とても面白いと思います。よければ買って読んでみて
 ください。
◆私にはお金は一銭も入りませんのでご安心を(笑
さて、では・・・
「継続的デリバリー」
の章立てに沿って
お話していきます。

あと、Jenkinsに関して。
ツールは使う目的が大切。
Jenkinsを探せ!!
バージョン
コントロール
(リポジトリ)
コミット
ステージ
手作業
開発チーム
動作確認
ステージ
手作業
受け入れテスト
・キャパシティ
ステージ
リリース
ステージ
(本番)
コンパイル
バイナリのビルド
バイナリデプロイ
環境設定
デプロイメントテスト
手動動作確認
バイナリデプロイ
環境設定
デプロイメントテスト
(手作業)UAT
(手作業)性能テスト

デプロイメントパイプライン(システム全体)
インテグレーションパイプライン(コンポーネントA)
git push
Git
バージョン
コントロール
(リポジトリ)
インテグレーションパイプライン(コンポーネントB)
git push
Git
SVN
SVN
コンパイル
ユニットテスト
コンポーネントテスト
最新ライブラリ取得
最新コンポーネント取得
差分コンポーネント登録
例えば・・・

書籍「継続的デリバリー」の章の流れに沿って考えよう!!
にて始まり・・・
と来て・・・
となる。ここまでが、
継続的
インテグレーション!!
特に重要となるのは次の二種類の区別だ。
ひとつはコンポーネントとライブラリの
区別、もうひとつはビルド時の依存関係
と実行時の依存関係の区別である。
デプロイメントパイプラインは継続的インテグレーションを拡張したものであり、その狙いは
ソフトウェアを常にリリース可能な状態にしておく
ことだ。
(P411)
みなさん、どうですか?
私は...
これ大事!!
(@kami_teru)
(@kami_teru)
技術視点のテストは3種類ある!!
メモリ上だけで素早く実行!
こんな感じ!!
継続的デリバリーを構成するステージ:
(P307)
違いは?
フェーズを分けて考えることが大切。
(@kami_teru)
(@kami_teru)
ここまでが、テスト戦略のお話。
のお話。
という、構成管理のお話。
という、デプロイメントパイプラインのお話。
という、スクリプトのお話。
という、コミットステージのお話。
という、受け入れテストステージのお話。
という、キャパシティステージのお話。
という、リリースステージのお話。
という、依存関係を解決する「インテグレーションパイプライン」のお話。
という、リリースを意識したバージョン管理戦略のお話。
git push
Git
かみ砕いておさらい。フェーズその1
コンポーネント作成フェーズ!!
インテグレーションパイプライン(コンポーネントA)
コーディング
手動ユニットテスト

コンポーネントの
バージョン管理

“メインのバージョン管理から切り離すと
 プログラマに自由が生まれる。“

SVN
かみ砕いておさらい。フェーズその2
プロダクト(製品)作成フェーズ!!
インテグレーションパイプライン(コンポーネントA)
プロダクトの
バージョン管理

“プロダクトとの適合性検査は信頼できる
 クリーンな環境で自動的に行う。“

Git
自動ビルド
コミットテスト
コンポーネントテスト

自動コミット
かみ砕いておさらい。フェーズその3
コミットステージ!!
デプロイメントパイプライン(プロダクト)
“実行可能でどの環境にもデプロイ可能な
 成果物を作成する。“

SVN
自動ビルド
(バイナリ作成)

プロダクト生成
(バイナリ成果物)

ジョブ1
ジョブ2
かみ砕いておさらい。フェーズその5
受け入れテストステージ!!
デプロイメントパイプライン(プロダクト)
“誰でもワンクリックでいつでも最新の
 検証環境をユーザーに公開できる。“

ワンクリックデプロイ
ユーザー受け入れ
検証環境

ジョブ1
ジョブ2
プロダクト
かみ砕いておさらい。フェーズその4
開発者動作確認ステージ!!
デプロイメントパイプライン(プロダクト)
“いつでも最新のコードを擬似本番環境で
 動作確認することができる。“

定時デプロイ
開発者
動作確認環境

ジョブ1
ジョブ2
プロダクト
かみ砕いておさらい。フェーズその6
リリースステージ!!
デプロイメントパイプライン(プロダクト)
“日時をセットしておけば夜間に自動で
 デプロイ&トップ画面の起動を確認。“

スケジュールデプロイ
本番環境
ジョブ1
ジョブ2
プロダクト
“万が一のときはワンクリックで
 ロールバック。“

まとめ
Jenkinsおじさんにとって
働き甲斐のある現場を
作ってあげてください。

バイナリデプロイ
環境設定
デプロイメントテスト
次は「CI」
継続的インテグレーション
のお話です。
最初は
構成管理のお話から
入ります。
いよいよ
デプロイメントパイプライン
のお話に入っていきます。
ふぅ。。。
まだまだ!
さぁ難題、
依存関係へ!!
いよいよ最後!
バージョン管理のお話!!
始まりは・・・自動化。
スクリプトを書くこと!!

次に・・・本当に必要になったら、
Jenkinsおじさんを呼んであげよう

すると皆さんにとっても
働き甲斐のある、楽しい
現場が創造できるような
気がするのです。

以上!
ご静聴ありがとうございました。

皆さんの現場に活きる
ヒントがあれば!

長いです!
頑張って行きましょー!!
Full transcript