ワンクリックデプロイ101

2011年12月のワンクリックデプロイ勉強会のスライドです。
詳細はhttp://www.ryuzee.com/

Transcript

1. ワンクリックデプロイ  101 http://bit.ly/vHXFbO
2. 吉羽龍太郎 アジャイルコーチ http://www.ryuzee.com/
4. Special  Thanks @katzchang 凄腕プログラマー @tomohn 凄腕エバンジェリスト
5. え？マジでマジで？
6. 会場調査 •  全員起⽴立立してください •  ユニットテストを書いていない⽅方は着席 •  結合テストを⾃自動化していない⽅方は着席 •  継続的インテグレーションサーバを使っていな い⽅方は着席 •  デプロイを⾃自動化していない⽅方は着席 •  環境構築を⾃自動化していない⽅方は着席 最後まで起立されている方は 帰って大丈夫ですｗ
7. http://bit.ly/vPmiFJ 一日にしてならず
8. http://bit.ly/vj0b0v NNoo SSiillvveerr BBuulllleett† 
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. XP 技術⾯面を⾼高める Scrum 価値あるものから継続的に 製品を届ける Lean 企業活動⾃自体の全体最適化 チーム マネー ジャ 経営者
31. 繰り返し型の 開発 継続的 インテグレーション 継続的 デプロイ 継続的デリバリ 企業での価値創造 Strategic  Impact Adaptability  /   Agility
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の場合 Cancel Gift  wrap Return スプリント 2~∼4週間 返品 スプリントゴール スプリント バックログ 出荷可能な製品の 積み上げ プロダクトバックログ クーポン ギフト包装 クーポン キャンセル 24時間 単体テスト、結合テスト、 受け⼊入れテストがスプリン ト単位(もしくはリリース単 位)で⾏行行われる.
61. アジャイルでの品質の作りこみ スプリント終了了時には「テスト」が完了了.スプリントレ ビューで顧客のビジネス要件への適合性も確認できる http://www.flickr.com/photos/kakutani/2761992149/
62. アジャイルでの品質の作りこみ Scrumではフレームワークの定義のみで、テスト⾃自 動化については触れられていない.しかしアジャイル 開発においてはテスト⾃自動化は必須 ⼩小規模リリースのたびに⼿手 動でテストするとスプリン ト後半になるにつれてテス トコストが膨らむ ⾃自動化しないとソフトウェア規模に応じて、テスト⼯工数の占め る割合が増加していく（＝価値への投資が減少）
63. 【⾃自動と⼿手動】 機能テスト ストーリーテスト プロトタイプ シミュレーション 【⼿手動】※1 探索索的テスト シナリオテスト ユーザビリティテスト ユーザー受⼊入テスト アルファ版、ベータ版 【⾃自動化】 単体テスト コンポーネントテスト 【ツール】 パフォーマンステスト 負荷テスト セキュリティテスト 第１象限 第２象限 第３象限 第４象限 技術⾯面（技術的品質） ビジネス⾯面（ビジネス的品質） チ ー ム を ⽀支 援 製 品 を 批 評 テストの4象限 ※1  ATDD等では⾃自動化
64. 第1象限 　チームを⽀支援する技術⾯面のテスト テスト駆動開発などアジャイル開発の中⼼心。 第2象限 　チームを⽀支援するビジネス⾯面のテスト 顧客の視点からのハイレベルの機能テストなど。 第3象限 　製品を批評するビジネス⾯面のテスト ユーザー受⼊入テスト、探索索的テストなど。 第4象限 　技術⾯面のテストを使った製品の批評 パフォーマンステスト、セキュリティテストなど。 テストの4象限 「アジャイルテスト  ―⾼高品質を追求するアジャイルチームにおけるテストの視点―」増⽥田聡⽒氏 http://codezine.jp/devsumi/2010/report/07/ 　より引⽤用
65. ⾃自動化されたテストの要件 ⾃自動化されたテストは以下の条件を満たしている必要がある。 繰り返し可能  (Repeatable) 何回でも繰り返し実⾏行行できること。また実⾏行行ごとに結果が変わらないこと 独⽴立立性  (Independent) 環境や外部のコンポーネントに依存しないこと テストケースの実⾏行行順序に依存しないこと ⾃自⼰己検証  (Self  validation) テストが成功したか、失敗したかはプログラムが判断する。 （⼈人⼿手で判断しない） 簡単実⾏行行  (Easy) テストの準備に⼤大量量の時間や⼈人⼿手がかかるようにしない
66. 【⾃自動と⼿手動】 機能テスト ストーリーテスト プロトタイプ シミュレーション 【⼿手動】 探索索的テスト シナリオテスト ユーザビリティテスト ユーザー受⼊入テスト アルファ版、ベータ版 【⾃自動化】 単体テスト コンポーネントテスト 【ツール】 パフォーマンステスト 負荷テスト セキュリティテスト 第１象限 第２象限 第３象限 第４象限 技術⾯面（技術的品質） ビジネス⾯面（ビジネス的品質） チ ー ム を ⽀支 援 製 品 を 批 評 ツール・⼿手法のマッピング(例例) TDD xUnit PMD,  CPD  … Jmeter WebScarab RatProxy ValGrind  … Selenium Cucumber Rspec FitNess  … CI推奨 CI推奨 CI必須 ⼀一部CI可能
67. テスト⾃自動化の進め⽅方 プロダクトバックログ テスト⾃自動化バックログ スプリント バックログ レガシーコードにおい て、製品コードの開発 をとめて自動化のみへ 投資するのは現実的に 難しいので、投資割合 をきめて、予めバック ログに組み込むことが 望ましい
68. 問題修正にかかる時間 フェーズ 修正までの時間 要求や設計 5分 コードやユニットテスト 15分 結合テストやシステムテスト 1時間 ベータテスト 2時間 リリース後 1⽇日
69. ５．継続的 インテグレーション
70. http://bit.ly/soiCFy 継続的インテグ レーションの導入� と利用促進の７ス テップ
71. 1 ビルドサーバを 用意する http://bit.ly/rVAW90
72. http://bit.ly/rubXiA 2 夜間ビルドを 行う
73. 3 夜間ビルド＋ コミット時の ユニットテスト http://bit.ly/s3W9aF
74. 4 メトリクスの取得 http://bit.ly/rYN42H
75. 5 テストに対する信 頼性と依存性の確 立 http://bit.ly/rOloeO
76. http://bit.ly/sP6BvN 6 自動化された受け 入�れテスト＋デプ ロイ自動化
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. 既存のアプローチの問題 ü  sqlスクリプトファイルは管理理が煩雑 ü  sqlスクリプトは⾃自動実⾏行行に向かない ü  ロールバックやデータ移⾏行行の考慮もしづらい ü  複数のsqlスクリプトの実⾏行行順序の制御が難しい http://bit.ly/vbtqZc
87. 問題の例例 SQLの実⾏行行順序によって状態が変わってしまう alter  table  users  add   column  lastlogin   datetime  after  name; alter  table  users  add   column  disabled   boolean  default  false   after  name; 1.sql 2.sql 1→2の順に実⾏行行すると…. 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; +---------+ | version | +---------+ | 30 | +---------+ 1 row in set (0.08 sec) mysql> mysql> 現在30個⽬目のマイグレー ションファイルまで登録 済であることを指す
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                               #  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.
118. Webistrano
119. ９．テクニック
120. ビルド(デプロイ)パイプライン
121. ビルド(デプロイ)パイプライン •  SCMへのコミットをトリガーにする •  開発者のリズムを維持するために、最初にユ ニットテストや⼀一部のスモークテストを⾏行行い素 早く開発者にフィードバックする •  時間のかかる結合テストや受け⼊入れテストは、 前⼯工程が正常だった場合のみに⾏行行う •  これによってムダな時間を使わないようにする •  ユーザビリティテストや探索索的テストのうち⾃自 動化できないものもプロセスとしてはパイプラ イン上に定義 •  最後にデプロイできれば、デプロイパイプライ ン
122. １０．デモ
123. デモ •  Vagrant＋Chef-‐‑‒soloによる環境構築 •  Doctrineによる簡単マイグレーション •  Capistrano・Webisitanoによるワンクリックデ プロイ •  Jenkins  +  Capistranoによるデプロイメントパ イプライン