1. ワンクリックデプロイ 101 http://bit.ly/vHXFbO
2. 吉羽龍太郎 アジャイルコーチ http://www.ryuzee.com/
4. Special Thanks @katzchang 凄腕プログラマー @tomohn 凄腕エバンジェリスト
6. 会場調査 全員起⽴立立してください ユニットテストを書いていない⽅方は着席 結合テストを⾃自動化していない⽅方は着席 継続的インテグレーションサーバを使っていな い⽅方は着席 • デプロイを⾃自動化していない⽅方は着席 • 環境構築を⾃自動化していない⽅方は着席 • • • • 最後まで起立されている方は 帰って大丈夫ですｗ
7. 一日にしてならず http://bit.ly/vPmiFJ
8. NNoo SSiillvveerr BBuulllleett† http://bit.ly/vj0b0v
9. 自分たちのプロセス は自分たちで進化さ せるしかない！ http://bit.ly/sygcE9
12. 以前の競争 http://bit.ly/rioQDZ
14. 迅速な 意思決定 が必要 http://bit.ly/pccwAN
15. 意思決定をもと に素早く 具現化する必要 http://bit.ly/r1ziWL
17. 変化への対応 “事前に綿密” にたてた計画を “長期間遵守” して大丈夫なのか？
18. 変化への対応 “変化が起こる” ことを前提に “頻繁に軌道修正” することが必要 http://bit.ly/oX9ImQ
19. 変化に対応できなけれ ばマーケットから 見捨てられる
20. 価値がなくなれば滅びる http://bit.ly/qJg8EX
21. 継続的な イノベーション の創発 http://bit.ly/nLACes
22. “イノベーションは「知」の創造プロセ スであり、知の創造は単に理論だけでは なく、実践を通して知識を磨き、知恵に するものである” “企業の優れた業績は研究開発投資の増 加に要因があるのではなく、組織の イノベーション・プロセスの質による” 野中郁次郎氏の発言要旨
23. http://www.slideshare.net/InnovationSprint2011/2011-‐‑‒6794551
24. プロセス プロダクト イノベーション イノベーション http://bit.ly/qpjFXr http://bit.ly/ornfUo
25. マインド イノベーション http://bit.ly/nrDcZf
26. コンウェイの法則 “OOrrggaanniizzaattiioonnss wwhhiicchh ddeessiiggnn ssyysstteemmss aarree ccoonnssttrraaiinneedd ttoo pprroodduuccee ddeessiiggnnss wwhhiicchh aarree ccooppiieess ooff tthhee ccoommmmuunniiccaattiioonn ssttrruuccttuurreess ooff tthheessee oorrggaanniizzaattiioonnss..” http://bit.ly/oIUrUI
28. 毎日何回も本番環境にデプロイで きているか？ 顧客に頻繁に価値を届けられてい るか？
29. ワンクリックでデプロイできたと しても、リリースの意思決定に時 間がかかったら無意味！ http://bit.ly/rZyM3H
30. Lean 経営者 Scrum マネー ジャ XP チーム 企業活動⾃自体の全体最適化 価値あるものから継続的に 製品を届ける 技術⾯面を⾼高める
31. 企業での価値創造 Adaptability / Agility 継続的デリバリ 継続的 デプロイ 継続的 インテグレーション 繰り返し型の 開発 Strategic Impact
32. 継続的デリバリとは何か？ “継続的デリバリとはリリースのスケジュー ルをIITT部門が握るのではなく、ビジネス部門 が握るということだ。継続的デリバリを実装す るということは、全体のライフサイクルを通じ て常にソフトウェアが本番環境にリリース可能 であるということを意味する。すなわちどのビ ルドもボタン一発で、完全に自動化されたリ リースプロセスを通じて、秒とか分の時間で利 用者にリリース可能である、ということ だ。” JJeezz HHuummbbllee
33. 継続的デリバリ http://bit.ly/tFrqbz ユーザーとプロジェクトチームの間に 固いフィードバックループを作る
34. 継続的デリバリ http://bit.ly/uLQaml 継続的なフィードバックプロセスは、 競争優位性やムダの削減につながる
35. 継続的デリバリの8原則 ソフトウェアのリ リースやデプロイ のプロセスは繰り 返し可能であり信 頼性が高い必要が ある。 1
36. 継続的デリバリの8原則 2 全てを自動化 する
37. 継続的デリバリの8原則 3 難解なことや苦 痛なことを繰り 返し行い自動化 の方法を考える
38. 継続的デリバリの8原則 4 全てをソース コード管理シス テムで管理する
39. 継続的デリバリの8原則 5 完了は「リリー スされたこと」 を意味する
40. 継続的デリバリの8原則 6 品質を作りこむ
41. 継続的デリバリの8原則 7 すべての人にリ リースプロセス に対しての責任 がある
42. 継続的デリバリの8原則 8 継続的に改�善 する
43. 継続的デリバリの4プラクティス l バイナリは一度だけビルドする l すべての環境にデプロイするのに 完全に同一のメカニズムを使う l デプロイメントでスモークテスト を実施する l 何か問題が起こったらラインを止 める
44. ど の 再断 現面 可で 能も か ？ http://bit.ly/uVQu5I
45. リリースした際に、前のバージョンに即座 に戻せるか？これはコードだけでなくデー タベース等も含む http://bit.ly/tgbmyr
47. Convention Over Configuration
48. Scrumとの関連性 • 多くの大規模組織は、ソフトウェアのデプロイ メントメソッドが貧弱であり、それ故にソフト ウェアを世に送り出すことが困難な状況にある。 • SSccrruummは妨害事項リスト等を使うことで、妨害 事項を明らかはできるが、SSccrruumm自体ではそれ を解決できず、SSccrruummそれ自体はどのようにそ れを解決するかの指針も持ち合わせていない
49. Doneの定義 何ができたら 完了了なのかを 決める
50. Doneの定義 • チームとして定めた「出荷可能な製品」を作成 するために実施しなければいけないことの⼀一覧。 • 例例えば、コードを書く、ユニットテストする、 統合テストをする、リリースノートを書く • ストーリーでのDoneの定義、スプリント単位 でのDoneの定義、リリース単位でのDoneの 定義をすることを推奨。 • Doneの定義はチームの成熟度度や時間に よって変わっていくが、Doneの定義 なくしてのScrumはあり得ない。
52. ソースコードのバージョン管理理 • いわずもがな。全ての起点はここにある • コードの共同所有の原則への理理解 • このソースコードは本番環境または開発環境な どで同じように動作しなければならない • テストを書く習慣、コミット前に他のテストも 含めて通してからコミットする習慣
53. 設定ファイルのバージョン管理理 • 環境によって異異なる設定値（接続先データベー ス情報など）が書かれた設定ファイルもバー ジョン管理理する • 開発環境⽤用、ステージング環境⽤用、本番環境⽤用 などに分けて定義し、容易易に切切り替え可能にす る • 本番環境に配置する際に、アプリケーションの 各所を書き換えなければ動作しないという状況 は避ける
54. バージョン管理は 開発者のしつけ http://bit.ly/utD8aA
56. けデもテ なプのス いロをト イ目し しをて て瞑い はっな いてい http://bit.ly/rAOG9h
57. 清水の舞台から 飛び降りない http://bit.ly/tnB8i0
58. http://bit.ly/shZMnK デプロイするたびに人手 で全体をテストするのは 無理
59. ITアーキテクト「機能テストの⾃自動化について考える」 より引⽤用 http://www.itarchitect.jp/print/?menu3=24601 テスト自動化の損益分岐点 は相当早期にある感覚
60. アジャイルでの品質の作りこみ Scrumの場合 24時間 スプリント 2~∼4週間 スプリントゴール 返品 スプリント バックログ キャンセル Return クーポン Gift wrap ギフト包装 Cancel クーポン プロダクトバックログ 出荷可能な製品の 積み上げ 単体テスト、結合テスト、 受け⼊入れテストがスプリン ト単位(もしくはリリース単 位)で⾏行行われる.
61. アジャイルでの品質の作りこみ スプリント終了了時には「テスト」が完了了.スプリントレ ビューで顧客のビジネス要件への適合性も確認できる http://www.flickr.com/photos/kakutani/2761992149/
62. アジャイルでの品質の作りこみ Scrumではフレームワークの定義のみで、テスト⾃自 動化については触れられていない.しかしアジャイル 開発においてはテスト⾃自動化は必須 ⼩小規模リリースのたびに⼿手 動でテストするとスプリン ト後半になるにつれてテス トコストが膨らむ ⾃自動化しないとソフトウェア規模に応じて、テスト⼯工数の占め る割合が増加していく（＝価値への投資が減少）
63. テストの4象限 ビジネス⾯面（ビジネス的品質） 【⾃自動と⼿手動】 【⼿手動】※1 機能テスト ストーリーテスト プロトタイプ シミュレーション 探索索的テスト シナリオテスト ユーザビリティテスト ユーザー受⼊入テスト アルファ版、ベータ版 ー チ 第２象限 ム を ⽀支 【⾃自動化】 援 単体テスト コンポーネントテスト 第３象限 【ツール】 パフォーマンステスト 負荷テスト セキュリティテスト 第１象限 技術⾯面（技術的品質） ※1 ATDD等では⾃自動化 第４象限 製 品 を 批 評
64. テストの4象限 第1象限 チームを⽀支援する技術⾯面のテスト テスト駆動開発などアジャイル開発の中⼼心。 第2象限 チームを⽀支援するビジネス⾯面のテスト 顧客の視点からのハイレベルの機能テストなど。 第3象限 製品を批評するビジネス⾯面のテスト ユーザー受⼊入テスト、探索索的テストなど。 第4象限 技術⾯面のテストを使った製品の批評 パフォーマンステスト、セキュリティテストなど。 「アジャイルテスト ―⾼高品質を追求するアジャイルチームにおけるテストの視点―」増⽥田聡⽒氏 http://codezine.jp/devsumi/2010/report/07/ より引⽤用
65. ⾃自動化されたテストの要件 ⾃自動化されたテストは以下の条件を満たしている必要がある。 繰り返し可能 (Repeatable) 何回でも繰り返し実⾏行行できること。また実⾏行行ごとに結果が変わらないこと 独⽴立立性 (Independent) 環境や外部のコンポーネントに依存しないこと テストケースの実⾏行行順序に依存しないこと ⾃自⼰己検証 (Self validation) テストが成功したか、失敗したかはプログラムが判断する。 （⼈人⼿手で判断しない） 簡単実⾏行行 (Easy) テストの準備に⼤大量量の時間や⼈人⼿手がかかるようにしない
66. ツール・⼿手法のマッピング(例例) ビジネス⾯面（ビジネス的品質） 【⾃自動と⼿手動】 ー チ 機能テスト Selenium ストーリーテスト Cucumber プロトタイプ Rspec シミュレーション FitNess … CI推奨 第２象限 ム を ⽀支 【⾃自動化】 援 単体テスト コンポーネントテスト TDD xUnit PMD, CPD … CI必須 第１象限 【⼿手動】 探索索的テスト シナリオテスト ユーザビリティテスト ユーザー受⼊入テスト アルファ版、ベータ版 ⼀一部CI可能 第３象限 【ツール】 パフォーマンステスト Jmeter 負荷テスト WebScarab セキュリティテスト RatProxy ValGrind … CI推奨 技術⾯面（技術的品質） 第４象限 製 品 を 批 評
67. テスト⾃自動化バックログ プロダクトバックログ テスト⾃自動化の進め⽅方 スプリント バックログ レガシーコードにおい て、製品コードの開発 をとめて自動化のみへ 投資するのは現実的に 難しいので、投資割合 をきめて、予めバック ログに組み込むことが 望ましい
68. 問題修正にかかる時間 フェーズ 要求や設計 修正までの時間 5分 コードやユニットテスト 15分 結合テストやシステムテスト 1時間 ベータテスト 2時間 リリース後 1⽇日
70. 継続的インテグ レーションの導入� と利用促進の７ス テップ http://bit.ly/soiCFy
71. http://bit.ly/rVAW90 1 ビルドサーバを 用意する
72. 2 夜間ビルドを 行う http://bit.ly/rubXiA
73. 3 夜間ビルド＋ コミット時の ユニットテスト http://bit.ly/s3W9aF
74. 4 メトリクスの取得 http://bit.ly/rYN42H
75. 5 テストに対する信 頼性と依存性の確 立 http://bit.ly/rOloeO
76. 6 自動化された受け 入�れテスト＋デプ ロイ自動化 http://bit.ly/sP6BvN
77. 7 継続的なデプロイ http://bit.ly/uc3x59
78. CIサーバの構築 • プロジェクト初期の段階でコードがなくても構 築する • コードのメトリクスや静的解析は初期から継続 的に実施する⽅方が効果がある • 常にグリーン(Jenkinsなら⻘青)の状態を保ち、エ ラーがある状態に慣れない • 常にグリーンに保つにはアトミックな単位での 作業、マイグレーションとの連携、チームのコ ミットに対する態度度が⽋欠かせない
80. CIアンチパターン • • • • • • • • • • 頻繁にSCMにコミットしない テストコードを書かない テストコードと製品コードを同時にコミットしない 定時ビルドのみでコミットビルドがない・夜間ビルドしかない 帰り際にコミットしてそのままCIの結果を⾒見見ずに帰る CIでテストを通すために⼿手作業の準備が必要 メインラインのみで⼤大きなブランチをCI対象にしていない 様々な種類のテストをまとめて⾏行行っている ビルドの失敗に気付かない ビルドに失敗しても放置している
81. CIアンチパターン • ビルドの失敗に気づいても、修正コード以外のコードをコミットす る • 何も変更更していないのにビルドが落落ちたり落落ちなかったりする • 頻繁にビルドが失敗しているので、失敗するのが普通だと思う • CIからの通知メッセージが⼤大量量すぎる • CIが落落ちても何も通知しない • CIサーバのリソースが貧弱 • ビルドが肥⼤大化して結果が出るまでに時間がかかる • 本番環境やステージング環境と⼤大幅に環境が異異なる • コードの静的解析をCIで⾏行行わずに⼈人⼿手で⾏行行う • CIサーバがおかしくなったときに直せる⼈人がいない • ずっとCIでのチェック内容が変わらない、プロセスが変わらない
82. 第１象限での⾃自動評価 プロジェクトの特性や要員構成等に応じて決める テスト件数と結果(単体、結合) PMD警告件数 Checkstyle警告件数 カバレージ
83. チーム活動の評価 コード⾏行行数 アクティビティ コミット時間
85. DBスキーマのバージョン管理理 データベースのスキーマの状態とリリース の状態を関連付けることによって再現可能 にする
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 boolean default false after name; 2→1の順に実⾏行行すると….
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
90. マイグレーションの状態 mysql> mysql> mysql> mysql> mysql> select * from migration_version; +---------+ 現在30個⽬目のマイグレー | version | ションファイルまで登録 +---------+ 済であることを指す | 30 | +---------+ 1 row in set (0.08 sec) mysql> mysql>
91. マイグレーション実⾏行行 コマンド１つで最新のバージョンに更更新したり、 特定のバージョンに戻すことができる # 最新のバージョンへ更更新 $ php doctrine_̲cli.php migrate # 指定したバージョンへ更更新 $ php doctrine_̲cli.php migrate 29 マイグレーションファイルをソースコードとしてバージョ ン管理理し、CIのビルド定義の中にマイグレーションコマン ドを組み込むことで、⾃自動的にDBの状態を連動させる
92. オープンソースのマ イグレーションツー ルは色々ある！
94. なぜ環境構築の⾃自動化が必要？ ü そもそも時間がかかる ü 数が増えれば単純作業の繰り返し ü ⼈人⼿手による単純作業はミスを誘発 ü ミスした場合でも検知する仕掛けが本番障 害しかない ü ⼿手順書がメンテナンスされないことがある ü ⼿手順書の⼿手順の妥当性の評価が難しい ü ⼿手順の逆転により状態が変わりうる
95. ミドルや設定インストールの⾃自動化 いつでも クリーンな 動作環境を作れ るようにする http://bit.ly/vMHRjL
96. ミドルや設定インストールの⾃自動化 この自動化に よって後はア プリケーショ ンをデプロイ すればすぐ動 作する状態に する http://bit.ly/v30Zl7
97. ミドルや設定インストールの⾃自動化 http://bit.ly/ttwsmT 本番環境と開発環境の各種 バージョンをあわせる
98. ミドルや設定インストールの⾃自動化 ミドルウェアのバージョ ンをあげる場合も、この 自動化機構を使って行う
100. Vagrantのインストールと起動 $ sudo gem install vagrant $ sudo vagrant box add lucid32 h7p:// files.vagrantup.com/lucid32.box $ sudo vagrant init $ sudo vagrant up わずか４ステップで、仮想イン スタンスが起動する!!!!
101. Vagrantファイルでの設定 Vagrantファイルで、ベース ボックス名やVirtualBoxの GUI表⽰示の有無、インスタン ス名、メモリ容量量、⾃自動実⾏行行 するChefのRecipeなどを指 定できる
102. Vagrantのプラグインでの拡張 SaharaによるSandbox機能の導⼊入 $ sudo git clone h7ps://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が多数公開されている
106. バージョンを指定し てパッケージをイン ストールすることも 可能
107. Cookbook (37signals)
109. その他の選択肢としてPPuuppppeett等
111. http://bit.ly/vd1Nin プロジェクト最初に、 ((デプロイするものが なくても))デプロイを 自動化する
112. http://bit.ly/u27Oiz プロジェクトのあ いだ、ずっとデプ ロイスクリプトを 使うことで、プロ セスがテストされ 続ける 開発環境・本番環 境問わず、同じ方 法でデプロイする
113. デプロイが失敗した場 合にロールバックでき るようにする http://bit.ly/vFzaU9
114. デプロイが途中で失敗 した場合、その先を手 動でやらない http://bit.ly/w34bFM
115. Capistrano Railsアプリのデプロイに利利⽤用されることが多いが、もちろんそ れ以外にも利利⽤用可能。SSHで接続し、サーバに対して⾊色々な操作 を⾏行行うことが出来る。
117. capコマンド cap deploy cap deploy:check cap deploy:cleanup cap deploy:pending cap deploy:pending:diff cap deploy:rollback cap deploy:rollback:code cap deploy:setup cap deploy:symlink cap deploy:update cap deploy:update_̲code cap deploy:upload cap deploy:web:disable cap deploy:web:enable cap develop cap invoke cap multistage:prepare cap production cap shell # Deploys your project. # Test deployment dependencies. # Clean up old releases. # Displays the commits since your last deploy. # Displays the `̀diff' since your last deploy. # Rolls back to a previous version and restarts. # Rolls back to the previously deployed version. # Prepares one or more servers for deployment. # Updates the symlink to the most recently deployed ... # Copies your project and updates the symlink. # Copies your project to the remote servers. # Copy files to the currently deployed version. # Present a maintenance page to visitors. # Makes the application web-‐‑‒accessible again. # Set the target stage to `̀develop'. # Invoke a single command on the remote servers. # Stub out the staging config files. # Set the target stage to `̀production'. # Begin an interactive Capistrano session.
121. ビルド(デプロイ)パイプライン • SCMへのコミットをトリガーにする • 開発者のリズムを維持するために、最初にユ ニットテストや⼀一部のスモークテストを⾏行行い素 早く開発者にフィードバックする • 時間のかかる結合テストや受け⼊入れテストは、 前⼯工程が正常だった場合のみに⾏行行う • これによってムダな時間を使わないようにする • ユーザビリティテストや探索索的テストのうち⾃自 動化できないものもプロセスとしてはパイプラ イン上に定義 • 最後にデプロイできれば、デプロイパイプライ ン
123. デモ • Vagrant＋Chef-‐‑‒soloによる環境構築 • Doctrineによる簡単マイグレーション • Capistrano・Webisitanoによるワンクリックデ プロイ • Jenkins + Capistranoによるデプロイメントパ イプライン
