1. ワンクリックデプロイ  101 http://bit.ly/vHXFbO

2. 吉羽龍太郎 アジャイルコーチ http://www.ryuzee.com/

4. Special  Thanks @katzchang 凄腕プログラマー @tomohn 凄腕エバンジェリスト

5. え？マジでマジで？

6. 会場調査 全員起⽴立立してください ユニットテストを書いていない⽅方は着席 結合テストを⾃自動化していない⽅方は着席 継続的インテグレーションサーバを使っていな い⽅方は着席 •  デプロイを⾃自動化していない⽅方は着席 •  環境構築を⾃自動化していない⽅方は着席 •  •  •  •  最後まで起立されている方は 帰って大丈夫ですｗ

7. 一日にしてならず http://bit.ly/vPmiFJ

8. NNoo SSiillvveerr BBuulllleett†  http://bit.ly/vj0b0v

9. 自分たちのプロセス は自分たちで進化さ せるしかない！ http://bit.ly/sygcE9

10. １．ビジネスをとりまく 環境の変化

11. IITT投資は業務効率化 から戦略実現へ

12. 以前の競争 http://bit.ly/rioQDZ

13. 現在の競争 競争の速度の変化

14. 迅速な 意思決定 が必要 http://bit.ly/pccwAN

15. 意思決定をもと に素早く 具現化する必要 http://bit.ly/r1ziWL

16. ビジネスモデルの賞味期限が短縮

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

27. ２．継続的デリバリ

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

46. DRY

47. Convention Over Configuration

48. Scrumとの関連性 •  多くの大規模組織は、ソフトウェアのデプロイ メントメソッドが貧弱であり、それ故にソフト ウェアを世に送り出すことが困難な状況にある。 •  SSccrruummは妨害事項リスト等を使うことで、妨害 事項を明らかはできるが、SSccrruumm自体ではそれ を解決できず、SSccrruummそれ自体はどのようにそ れを解決するかの指針も持ち合わせていない

49. Doneの定義 何ができたら 完了了なのかを 決める

50. Doneの定義 •  チームとして定めた「出荷可能な製品」を作成 するために実施しなければいけないことの⼀一覧。 •  例例えば、コードを書く、ユニットテストする、 統合テストをする、リリースノートを書く •  ストーリーでのDoneの定義、スプリント単位 でのDoneの定義、リリース単位でのDoneの 定義をすることを推奨。 •  Doneの定義はチームの成熟度度や時間に よって変わっていくが、Doneの定義 なくしてのScrumはあり得ない。

51. ３．バージョン管理

52. ソースコードのバージョン管理理 •  いわずもがな。全ての起点はここにある •  コードの共同所有の原則への理理解 •  このソースコードは本番環境または開発環境な どで同じように動作しなければならない •  テストを書く習慣、コミット前に他のテストも 含めて通してからコミットする習慣

53. 設定ファイルのバージョン管理理 •  環境によって異異なる設定値（接続先データベー ス情報など）が書かれた設定ファイルもバー ジョン管理理する •  開発環境⽤用、ステージング環境⽤用、本番環境⽤用 などに分けて定義し、容易易に切切り替え可能にす る •  本番環境に配置する際に、アプリケーションの 各所を書き換えなければ動作しないという状況 は避ける

54. バージョン管理は 開発者のしつけ http://bit.ly/utD8aA

55. ４．テスト自動化

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⽇日

69. ５．継続的 インテグレーション

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なら⻘青)の状態を保ち、エ ラーがある状態に慣れない •  常にグリーンに保つにはアトミックな単位での 作業、マイグレーションとの連携、チームのコ ミットに対する態度度が⽋欠かせない

79. Jenkinsでの例例

80. CIアンチパターン •  •  •  •  •  •  •  •  •  •  頻繁にSCMにコミットしない テストコードを書かない テストコードと製品コードを同時にコミットしない 定時ビルドのみでコミットビルドがない・夜間ビルドしかない 帰り際にコミットしてそのままCIの結果を⾒見見ずに帰る CIでテストを通すために⼿手作業の準備が必要 メインラインのみで⼤大きなブランチをCI対象にしていない 様々な種類のテストをまとめて⾏行行っている ビルドの失敗に気付かない ビルドに失敗しても放置している

81. CIアンチパターン •  ビルドの失敗に気づいても、修正コード以外のコードをコミットす る •  何も変更更していないのにビルドが落落ちたり落落ちなかったりする •  頻繁にビルドが失敗しているので、失敗するのが普通だと思う •  CIからの通知メッセージが⼤大量量すぎる •  CIが落落ちても何も通知しない •  CIサーバのリソースが貧弱 •  ビルドが肥⼤大化して結果が出るまでに時間がかかる •  本番環境やステージング環境と⼤大幅に環境が異異なる •  コードの静的解析をCIで⾏行行わずに⼈人⼿手で⾏行行う •  CIサーバがおかしくなったときに直せる⼈人がいない •  ずっとCIでのチェック内容が変わらない、プロセスが変わらない

82. 第１象限での⾃自動評価 プロジェクトの特性や要員構成等に応じて決める テスト件数と結果(単体、結合) PMD警告件数 Checkstyle警告件数 カバレージ

83. チーム活動の評価 コード⾏行行数 アクティビティ コミット時間

84. 66．マイグレーションの 利用

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の順に実⾏行行すると….

88. マイグレーション(PHPの場合)

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. オープンソースのマ イグレーションツー ルは色々ある！

93. ７．環境構築自動化

94. なぜ環境構築の⾃自動化が必要？ ü そもそも時間がかかる ü 数が増えれば単純作業の繰り返し ü ⼈人⼿手による単純作業はミスを誘発 ü ミスした場合でも検知する仕掛けが本番障 害しかない ü ⼿手順書がメンテナンスされないことがある ü ⼿手順書の⼿手順の妥当性の評価が難しい ü ⼿手順の逆転により状態が変わりうる

95. ミドルや設定インストールの⾃自動化 いつでも クリーンな 動作環境を作れ るようにする http://bit.ly/vMHRjL

96. ミドルや設定インストールの⾃自動化 この自動化に よって後はア プリケーショ ンをデプロイ すればすぐ動 作する状態に する http://bit.ly/v30Zl7

97. ミドルや設定インストールの⾃自動化 http://bit.ly/ttwsmT 本番環境と開発環境の各種 バージョンをあわせる

98. ミドルや設定インストールの⾃自動化 ミドルウェアのバージョ ンをあげる場合も、この 自動化機構を使って行う

99. 仮想化と⾃自動化（Vagrant）

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

104. Chef/Chef-‐‑‒solo

105. Chefとは？ •  Ruby製のシステム管理理ツール •  出来ること –  OSのパッケージのインストールや管理理 –  OSの設定やミドルウェアの設定 –  サービスの起動・停⽌止 –  クーロンの設定 •  特徴 –  Rubyでジョブや設定を記述する –  Chef⾃自体はクライアント/サーバモデル –  Chef-‐‑‒soloを使えばローカル単体で動作 –  Recipeが多数公開されている

106. バージョンを指定し てパッケージをイン ストールすることも 可能

107. Cookbook  (37signals)

108. Cookbook(opscode)

109. その他の選択肢としてPPuuppppeett等

110. ８．デプロイ自動化

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.

118. Webistrano

119. ９．テクニック

120. ビルド(デプロイ)パイプライン

121. ビルド(デプロイ)パイプライン •  SCMへのコミットをトリガーにする •  開発者のリズムを維持するために、最初にユ ニットテストや⼀一部のスモークテストを⾏行行い素 早く開発者にフィードバックする •  時間のかかる結合テストや受け⼊入れテストは、 前⼯工程が正常だった場合のみに⾏行行う •  これによってムダな時間を使わないようにする •  ユーザビリティテストや探索索的テストのうち⾃自 動化できないものもプロセスとしてはパイプラ イン上に定義 •  最後にデプロイできれば、デプロイパイプライ ン

122. １０．デモ

123. デモ •  Vagrant＋Chef-‐‑‒soloによる環境構築 •  Doctrineによる簡単マイグレーション •  Capistrano・Webisitanoによるワンクリックデ プロイ •  Jenkins  +  Capistranoによるデプロイメントパ イプライン