Weitere ähnliche Inhalte Ähnlich wie ワンクリックデプロイ101 #ocdeploy (20) Kürzlich hochgeladen (10) ワンクリックデプロイ101 #ocdeploy8. No
Silver
Bullet
http://bit.ly/vj0b0v
14. 迅速な
意思決定
が必要
http://bit.ly/pccwAN
21. 継続的な
イノベーション
の創発
http://bit.ly/nLACes
24. プロセス プロダクト
イノベーション イノベーション
http://bit.ly/qpjFXr http://bit.ly/ornfUo
26. コンウェの法則
“Organizations which design
systems are constrained to
produce designs which are
copies of the communication
structures of these
organizations.”
http://bit.ly/oIUrUI
30. 経営
Lean 者
企業活動自体の全体最適化
Scrum
マ
ネー
価値あるものから継続的に ジャ
製品を届ける
XP チー
技術面を高める ム
31. 企業での価値創造
継続的デリバリ
Adaptability /
継続的
デプロ
Agility
継続的
ンテグレーション
繰り返し型の
開発
Strategic Impact
33. 継続的デリバリ
http://bit.ly/tFrqbz
ユーザーとプロジェクトチームの間に
固いフィードバックループを作る
34. 継続的デリバリ
http://bit.ly/uLQaml
継続的なフィードバックプロセスは、
競争優位性やムダの削減につながる
35. 継続的デリバリの8原則
ソフトウェアのリ
リースやデプロイ
のプロセスは繰り
返し可能であり信
頼性が高い必要が
ある。
44. ど
の
再断
現面
可で
能も
か
?
http://bit.ly/uVQu5I
48. Scrumとの関連性
• 多くの大規模組織は、ソフトウェアのデプロイ
メントメソッドが貧弱であり、それ故にソフト
ウェアを世に送り出すことが困難な状況にある。
• Scrumは妨害事項リスト等を使うことで、妨害事
項を明らかはできるが、Scrum自体ではそれを解
決できず、Scrumそれ自体はどのようにそれを解
決するかの指針も持ち合わせていない
50. Doneの定義
• チームとして定めた「出荷可能な製品」を作成
するために実施しなければいけないことの一覧。
• 例えば、コードを書く、ユニットテストする、
統合テストをする、リリースノートを書く
• ストーリーでのDoneの定義、スプリント単位
でのDoneの定義、リリース単位でのDoneの
定義をすることを推奨。
• Doneの定義はチームの成熟度や時間に
よって変わっていくが、Doneの定義
なくしてのScrumはあり得ない。
56. けデもテ
なプのス
いロをト
イ目し
しをて
て瞑い
はっな
いてい
http://bit.ly/rAOG9h
57. 清水の舞台から
飛び降りない
http://bit.ly/tnB8i0
60. ゕジャルでの品質の作りこみ
Scrumの場合
24時間
スプリント
2~4週間
スプリントゴール
返品
スプリント
出荷可能な製品の
Return
キャンセル バックログ 積み上げ
Gift wrap
クーポン
Cancel
ギフト包装 クーポン 単体テスト、結合テスト、
受け入れテストがスプリン
プロダクトバックログ ト単位(もしくはリリース単
位)で行われる.
63. テストの4象限
ビジネス面(ビジネス的品質)
【自動と手動】 【手動】※1
機能テスト 探索的テスト
ストーリーテスト シナリオテスト
プロトタイプ ユーザビリティテスト
シミュレーション ユーザー受入テスト
アルファ版、ベータ版
チ 製
ー 第2象限 第3象限 品
ム を
を 【自動化】 【ツール】 批
支 評
援 単体テスト パフォーマンステスト
コンポーネントテスト 負荷テスト
セキュリティテスト
第1象限 第4象限
技術面(技術的品質)
※1 ATDD等では自動化
64. テストの4象限
第1象限 チームを支援する技術面のテスト
テスト駆動開発などアジャイル開発の中心。
第2象限 チームを支援するビジネス面のテスト
顧客の視点からのハイレベルの機能テストなど。
第3象限 製品を批評するビジネス面のテスト
ユーザー受入テスト、探索的テストなど。
第4象限 技術面のテストを使った製品の批評
パフォーマンステスト、セキュリティテストなど。
「アジャイルテスト ―高品質を追求するアジャイルチームにおけるテストの視点―」増田聡氏
http://codezine.jp/devsumi/2010/report/07/ より引用
66. ツール・手法のマッピング(例)
ビジネス面(ビジネス的品質)
【自動と手動】 【手動】
機能テスト 探索的テスト
Selenium
ストーリーテスト シナリオテスト
Cucumber
プロトタイプ ユーザビリティテスト
Rspec
シミュレーション ユーザー受入テスト
FitNess …
アルファ版、ベータ版
チ 製
ー CI推奨 第2象限 一部CI可能 第3象限 品
ム を
を 【自動化】 【ツール】 批
支 評
援 単体テスト パフォーマンステスト
Jmeter
コンポーネントテスト
TDD 負荷テスト
WebScarab
xUnit セキュリティテスト
RatProxy
PMD, CPD …
ValGrind …
CI必須 第1象限 CI推奨 第4象限
技術面(技術的品質)
67. テスト自動化の進め方
プロダクトバックログ
レガシーコードにおい
スプリント て、製品コードの開発
バックログ
をとめて自動化のみへ
投資するのは現実的に
難しいので、投資割合
テスト自動化バックログ
をきめて、予めバック
ログに組み込むことが
望ましい
68. 問題修正にかかる時間
フェーズ 修正までの時間
要求や設計 5分
コードやユニットテスト 15分
結合テストやシステムテスト 1時間
ベータテスト 2時間
リリース後 1日
70. 継続的インテグ
レーションの導入
と利用促進の7ス
テップ
http://bit.ly/soiCFy
73. 夜間ビルド+
コミット時の
ユニットテスト
http://bit.ly/s3W9aF
75. テストに対する信
頼性と依存性の確
立
http://bit.ly/rOloeO
76. 自動化された受け
入れテスト+デプ
ロイ自動化
http://bit.ly/sP6BvN
78. CIサーバの構築
• プロジェクト初期の段階でコードがなくても構
築する
• コードのメトリクスや静的解析は初期から継続
的に実施する方が効果がある
• 常にグリーン(Jenkinsなら青)の状態を保ち、エ
ラーがある状態に慣れない
• 常にグリーンに保つにはアトミックな単位での
作業、マイグレーションとの連携、チームのコ
ミットに対する態度が欠かせない
80. CIゕンチパターン
• 頻繁にSCMにコミットしない
• テストコードを書かない
• テストコードと製品コードを同時にコミットしない
• 定時ビルドのみでコミットビルドがない・夜間ビルドしかない
• 帰り際にコミットしてそのままCIの結果を見ずに帰る
• CIでテストを通すために手作業の準備が必要
• メインラインのみで大きなブランチをCI対象にしていない
• 様々な種類のテストをまとめて行っている
• ビルドの失敗に気付かない
• ビルドに失敗しても放置している
81. CIゕンチパターン
• ビルドの失敗に気づいても、修正コード以外のコードをコミットす
る
• 何も変更していないのにビルドが落ちたり落ちなかったりする
• 頻繁にビルドが失敗しているので、失敗するのが普通だと思う
• CIからの通知メッセージが大量すぎる
• CIが落ちても何も通知しない
• CIサーバのリソースが貧弱
• ビルドが肥大化して結果が出るまでに時間がかかる
• 本番環境やステージング環境と大幅に環境が異なる
• コードの静的解析をCIで行わずに人手で行う
• CIサーバがおかしくなったときに直せる人がいない
• ずっとCIでのチェック内容が変わらない、プロセスが変わらない
86. 既存のゕプローチの問題
http://bit.ly/vbtqZc
sqlスクリプトフゔルは管理が煩雑
sqlスクリプトは自動実行に向かない
ロールバックやデータ移行の考慮もしづらい
複数のsqlスクリプトの実行順序の制御が難しい
87. 問題の例
SQLの実行順序によって状態が変わってしまう
1.sql 1→2の順に実行すると….
alter table users add
column lastlogin
datetime after name;
2.sql
alter table users add
column disabled
2→1の順に実行すると….
boolean default false
after name;
89. データベースの変更管理
$ ls -1
前後関係は、フゔル
1301223401_addchangelogs.php
1313445291_addinformation.php 先頭の数字の大小で判
1317489252_addpriorities.php 断される。
1318776293_addprojects.php (規約)
1318889397_addremainingtimes.php
1320243212_addresolutions.php
1321049290_addsprints.php
1321509396_addschemamigrations.php
1322392147_fix_project_invalid_default_value.php
1322446269_add_action_name_to_log.php
1322993218_addstories.php
1323001299_addstorycomments.php
1323449303_addusers.php
1324059101_addtasks.php
1325101301_addteammembers.php
1326548301_addteams.php
1327491204_addwiki.php
91. マグレーション実行
コマンド1つで最新のバージョンに更新したり、
特定のバージョンに戻すことができる
# 最新のバージョンへ更新
$ php doctrine_cli.php migrate
# 指定したバージョンへ更新
$ php doctrine_cli.php migrate 29
マグレーションフゔルをソースコードとしてバージョ
ン管理し、CIのビルド定義の中にマグレーションコマン
ドを組み込むことで、自動的にDBの状態を連動させる
96. ミドルや設定ンストールの自動化
この自動化に
よって後はア
プリケーショ
ンをデプロイ
すればすぐ動
作する状態に
する
http://bit.ly/v30Zl7
100. Vagrantのンストールと起動
$ sudo gem install vagrant
$ sudo vagrant box add lucid32
http://files.vagrantup.com/lucid32.box
$ sudo vagrant init
$ sudo vagrant up
わずか4ステップで、仮想イン
スタンスが起動する!!
101. Vagrantフゔルでの設定
Vagrantファイルで、ベース
ボックス名やVirtualBoxの
GUI表示の有無、インスタン
ス名、メモリ容量、自動実行
するChefのRecipeなどを指
定できる
102. Vagrantのプラグンでの拡張
SaharaによるSandbox機能の導入
$ sudo git clone https://github.com/jedi4ever/sahara.git
$ cd sahara
$ sudo rake build
$ cd pkg
$ sudo gem install ./sahara-0.0.7.gem
Sandbox機能を使うことで、ミドルウェアの
バージョンアップの検証や、構成の変更の検
証を気軽に行えるようになる。
103. Sandboxモード
■sandboxモードに入る(仮想マシンを再起動しても有効)
sudo vagrant sandbox on
■sandboxを開始時点にロールバックする
sudo vagrant sandbox rollback
■sandboxモードの終了(commitしていないものは消える)
sudo vagrant sandbox off
■sandboxの内容を恒久的に反映
sudo vagrant sandbox commit
■現在sandboxモードかどうかを確認する
sudo vagrant sandbox status
105. Chefとは?
• Ruby製のシステム管理ツール
• 出来ること
– OSのパッケージのインストールや管理
– OSの設定やミドルウェアの設定
– サービスの起動・停止
– クーロンの設定
• 特徴
– Rubyでジョブや設定を記述する
– Chef自体はクライアント/サーバモデル
– Chef-soloを使えばローカル単体で動作
– Recipeが多数公開されている
112. http://bit.ly/u27Oiz
プロジェクトのあ
いだ、ずっとデプ
ロイスクリプトを
使うことで、プロ
セスがテストされ
続ける
開発環境・本番環
境問わず、同じ方
法でデプロイする
113. デプロイが失敗した場
合にロールバックでき
るようにする
http://bit.ly/vFzaU9
114. デプロイが途中で失敗
した場合、その先を手
動でやらない
http://bit.ly/w34bFM
117. capコマンド
cap deploy # Deploys your project.
cap deploy:check # Test deployment dependencies.
cap deploy:cleanup # Clean up old releases.
cap deploy:pending # Displays the commits since your last deploy.
cap deploy:pending:diff # Displays the `diff' since your last deploy.
cap deploy:rollback # Rolls back to a previous version and restarts.
cap deploy:rollback:code # Rolls back to the previously deployed version.
cap deploy:setup # Prepares one or more servers for deployment.
cap deploy:symlink # Updates the symlink to the most recently deployed ...
cap deploy:update # Copies your project and updates the symlink.
cap deploy:update_code # Copies your project to the remote servers.
cap deploy:upload # Copy files to the currently deployed version.
cap deploy:web:disable # Present a maintenance page to visitors.
cap deploy:web:enable # Makes the application web-accessible again.
cap develop # Set the target stage to `develop'.
cap invoke # Invoke a single command on the remote servers.
cap multistage:prepare # Stub out the staging config files.
cap production # Set the target stage to `production'.
cap shell # Begin an interactive Capistrano session.