ワンクリックデプロイ101 #ocdeploy

29,292 views
29,227 views

Published on

2011年12月20日に実施したワンクリックデプロイ勉強会の資料です。
http://www.ryuzee.com/

Published in: Technology
2 Comments
83 Likes
Statistics
Notes
  • full image
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here
  • blessing_11111@yahoo.com

    My name is Blessing
    i am a young lady with a kind and open heart,
    I enjoy my life,but life can't be complete if you don't have a person to share it
    with. blessing_11111@yahoo.com

    Hoping To Hear From You
    Yours Blessing
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here
No Downloads
Views
Total views
29,292
On SlideShare
0
From Embeds
0
Number of Embeds
22
Actions
Shares
0
Downloads
201
Comments
2
Likes
83
Embeds 0
No embeds

No notes for slide

ワンクリックデプロイ101 #ocdeploy

  1. 1. ワンクリックデプロ゗ 101http://bit.ly/vHXFbO
  2. 2. 吉羽龍太郎ゕジャ゗ルコーチhttp://www.ryuzee.com/
  3. 3. Special Thanks @katzchang @tomohn 凄腕プログラマー 凄腕エバンジェリスト
  4. 4. え?マジでマジで?
  5. 5. 会場調査• 全員起立してください• ユニットテストを書いていない方は着席• 結合テストを自動化していない方は着席• 継続的インテグレーションサーバを使っていな い方は着席• デプロイを自動化していない方は着席• 環境構築を自動化していない方は着席 最後まで起立されている方は 帰って大丈夫ですw
  6. 6. 一日にしてならずhttp://bit.ly/vPmiFJ
  7. 7. No Silver Bullethttp://bit.ly/vj0b0v
  8. 8. http://bit.ly/sygcE9自分たちのプロセスは自分たちで進化させるしかない!
  9. 9. 1.ビジネスをとりまく環境の変化
  10. 10. IT投資は業務効率化から戦略実現へ
  11. 11. 以前の競争http://bit.ly/rioQDZ
  12. 12. 現在の競争 競争の速度の変化
  13. 13. 迅速な 意思決定 が必要http://bit.ly/pccwAN
  14. 14. 意思決定をもとに素早く具現化する必要 http://bit.ly/r1ziWL
  15. 15. ビジネスモデルの賞味期限が短縮
  16. 16. 変化への対応“事前に綿密” にたてた計画を“長期間遵守” して大丈夫なのか?
  17. 17. 変化への対応“変化が起こる” ことを前提に“頻繁に軌道修正” することが必要http://bit.ly/oX9ImQ
  18. 18. 変化に対応できなければマーケットから見捨てられる
  19. 19. 価値がなくなれば滅びるhttp://bit.ly/qJg8EX
  20. 20. 継続的な イノベーション の創発http://bit.ly/nLACes
  21. 21. “イノベーションは「知」の創造プロセスであり、知の創造は単に理論だけではなく、実践を通して知識を磨き、知恵にするものである”“企業の優れた業績は研究開発投資の増加に要因があるのではなく、組織のイノベーション・プロセスの質による”野中郁次郎氏の発言要旨
  22. 22. http://www.slideshare.net/InnovationSprint2011/2011-6794551
  23. 23. プロセス プロダクトイノベーション イノベーションhttp://bit.ly/qpjFXr http://bit.ly/ornfUo
  24. 24. マインドイノベーション http://bit.ly/nrDcZf
  25. 25. コンウェ゗の法則 “Organizations which design systems are constrained to produce designs which are copies of the communication structures of these organizations.”http://bit.ly/oIUrUI
  26. 26. 2.継続的デリバリ
  27. 27. 毎日何回も本番環境にデプロイできているか?顧客に頻繁に価値を届けられているか?
  28. 28. ワンクリックでデプロイできたとしても、リリースの意思決定に時間がかかったら無意味! http://bit.ly/rZyM3H
  29. 29. 経営 Lean 者企業活動自体の全体最適化 Scrum マ ネー価値あるものから継続的に ジャ 製品を届ける XP チー 技術面を高める ム
  30. 30. 企業での価値創造 継続的デリバリAdaptability / 継続的 デプロ゗Agility 継続的 ゗ンテグレーション 繰り返し型の 開発 Strategic Impact
  31. 31. 継続的デリバリとは何か?“継続的デリバリとはリリースのスケジュールをIT部門が握るのではなく、ビジネス部門が握るということだ。継続的デリバリを実装するということは、全体のライフサイクルを通じて常にソフトウェアが本番環境にリリース可能であるということを意味する。すなわちどのビルドもボタン一発で、完全に自動化されたリリースプロセスを通じて、秒とか分の時間で利用者にリリース可能である、ということだ。” Jez Humble
  32. 32. 継続的デリバリ http://bit.ly/tFrqbzユーザーとプロジェクトチームの間に固いフィードバックループを作る
  33. 33. 継続的デリバリ http://bit.ly/uLQaml継続的なフィードバックプロセスは、競争優位性やムダの削減につながる
  34. 34. 継続的デリバリの8原則 ソフトウェアのリ リースやデプロイ のプロセスは繰り 返し可能であり信 頼性が高い必要が ある。
  35. 35. 継続的デリバリの8原則 全てを自動化 する
  36. 36. 継続的デリバリの8原則 難解なことや苦 痛なことを繰り 返し行い自動化 の方法を考える
  37. 37. 継続的デリバリの8原則 全てをソース コード管理シス テムで管理する
  38. 38. 継続的デリバリの8原則 完了は「リリー スされたこと」 を意味する
  39. 39. 継続的デリバリの8原則 品質を作りこむ
  40. 40. 継続的デリバリの8原則 すべての人にリ リースプロセス に対しての責任 がある
  41. 41. 継続的デリバリの8原則 継続的に改善 する
  42. 42. 継続的デリバリの4プラクテゖスバイナリは一度だけビルドするすべての環境にデプロイするのに 完全に同一のメカニズムを使うデプロイメントでスモークテスト を実施する何か問題が起こったらラインを止 める
  43. 43. ど の 再断 現面 可で 能も か ?http://bit.ly/uVQu5I
  44. 44. リリースした際に、前のバージョンに即座に戻せるか?これはコードだけでなくデータベース等も含むhttp://bit.ly/tgbmyr
  45. 45. Convention OverConfiguration
  46. 46. Scrumとの関連性• 多くの大規模組織は、ソフトウェアのデプロイ メントメソッドが貧弱であり、それ故にソフト ウェアを世に送り出すことが困難な状況にある。• Scrumは妨害事項リスト等を使うことで、妨害事 項を明らかはできるが、Scrum自体ではそれを解 決できず、Scrumそれ自体はどのようにそれを解 決するかの指針も持ち合わせていない
  47. 47. Doneの定義何ができたら完了なのかを決める
  48. 48. Doneの定義• チームとして定めた「出荷可能な製品」を作成 するために実施しなければいけないことの一覧。• 例えば、コードを書く、ユニットテストする、 統合テストをする、リリースノートを書く• ストーリーでのDoneの定義、スプリント単位 でのDoneの定義、リリース単位でのDoneの 定義をすることを推奨。• Doneの定義はチームの成熟度や時間に よって変わっていくが、Doneの定義 なくしてのScrumはあり得ない。
  49. 49. 3.バージョン管理
  50. 50. ソースコードのバージョン管理• いわずもがな。全ての起点はここにある• コードの共同所有の原則への理解• このソースコードは本番環境または開発環境な どで同じように動作しなければならない• テストを書く習慣、コミット前に他のテストも 含めて通してからコミットする習慣
  51. 51. 設定フゔ゗ルのバージョン管理• 環境によって異なる設定値(接続先データベー ス情報など)が書かれた設定ファイルもバー ジョン管理する• 開発環境用、ステージング環境用、本番環境用 などに分けて定義し、容易に切り替え可能にす る• 本番環境に配置する際に、アプリケーションの 各所を書き換えなければ動作しないという状況 は避ける
  52. 52. バージョン管理は開発者のしつけ http://bit.ly/utD8aA
  53. 53. 4.テスト自動化
  54. 54. けデもテ なプのス いロをト イ目し しをて て瞑い はっな いていhttp://bit.ly/rAOG9h
  55. 55. 清水の舞台から 飛び降りないhttp://bit.ly/tnB8i0
  56. 56. http://bit.ly/shZMnKデプロイするたびに人手で全体をテストするのは無理
  57. 57. ITアーキテクト「機能テストの自動化について考える」より引用http://www.itarchitect.jp/print/?menu3=24601テスト自動化の損益分岐点は相当早期にある感覚
  58. 58. ゕジャ゗ルでの品質の作りこみScrumの場合 24時間 スプリント 2~4週間 スプリントゴール 返品 スプリント 出荷可能な製品の Return キャンセル バックログ 積み上げ Gift wrap クーポン Cancel ギフト包装 クーポン 単体テスト、結合テスト、 受け入れテストがスプリンプロダクトバックログ ト単位(もしくはリリース単 位)で行われる.
  59. 59. ゕジャ゗ルでの品質の作りこみスプリント終了時には「テスト」が完了.スプリントレビューで顧客のビジネス要件への適合性も確認できるhttp://www.flickr.com/photos/kakutani/2761992149/
  60. 60. ゕジャ゗ルでの品質の作りこみScrumではフレームワークの定義のみで、テスト自動化については触れられていない.しかしゕジャ゗ル開発においてはテスト自動化は必須 小規模リリースのたびに 手動でテストするとスプ リント後半になるにつれ てテストコストが膨らむ自動化しないとソフトウェア規模に応じて、テスト工数の占める割合が増加していく(=価値への投資が減少)
  61. 61. テストの4象限 ビジネス面(ビジネス的品質) 【自動と手動】 【手動】※1 機能テスト 探索的テスト ストーリーテスト シナリオテスト プロトタイプ ユーザビリティテスト シミュレーション ユーザー受入テスト アルファ版、ベータ版 チ 製 ー 第2象限 第3象限 品 ム を を 【自動化】 【ツール】 批 支 評 援 単体テスト パフォーマンステスト コンポーネントテスト 負荷テスト セキュリティテスト 第1象限 第4象限 技術面(技術的品質)※1 ATDD等では自動化
  62. 62. テストの4象限 第1象限 チームを支援する技術面のテスト テスト駆動開発などアジャイル開発の中心。 第2象限 チームを支援するビジネス面のテスト 顧客の視点からのハイレベルの機能テストなど。 第3象限 製品を批評するビジネス面のテスト ユーザー受入テスト、探索的テストなど。 第4象限 技術面のテストを使った製品の批評 パフォーマンステスト、セキュリティテストなど。「アジャイルテスト ―高品質を追求するアジャイルチームにおけるテストの視点―」増田聡氏http://codezine.jp/devsumi/2010/report/07/ より引用
  63. 63. 自動化されたテストの要件自動化されたテストは以下の条件を満たしている必要がある。繰り返し可能 (Repeatable)何回でも繰り返し実行できること。また実行ごとに結果が変わらないこと独立性 (Independent)環境や外部のコンポーネントに依存しないことテストケースの実行順序に依存しないこと自己検証 (Self validation)テストが成功したか、失敗したかはプログラムが判断する。(人手で判断しない)簡単実行 (Easy)テストの準備に大量の時間や人手がかかるようにしない
  64. 64. ツール・手法のマッピング(例) ビジネス面(ビジネス的品質) 【自動と手動】 【手動】 機能テスト 探索的テスト Selenium ストーリーテスト シナリオテスト Cucumber プロトタイプ ユーザビリティテスト Rspec シミュレーション ユーザー受入テスト FitNess … アルファ版、ベータ版 チ 製 ー CI推奨 第2象限 一部CI可能 第3象限 品 ム を を 【自動化】 【ツール】 批 支 評 援 単体テスト パフォーマンステスト Jmeter コンポーネントテスト TDD 負荷テスト WebScarab xUnit セキュリティテスト RatProxy PMD, CPD … ValGrind … CI必須 第1象限 CI推奨 第4象限 技術面(技術的品質)
  65. 65. テスト自動化の進め方プロダクトバックログ レガシーコードにおい スプリント て、製品コードの開発 バックログ をとめて自動化のみへ 投資するのは現実的に 難しいので、投資割合テスト自動化バックログ をきめて、予めバック ログに組み込むことが 望ましい
  66. 66. 問題修正にかかる時間フェーズ 修正までの時間要求や設計 5分コードやユニットテスト 15分結合テストやシステムテスト 1時間ベータテスト 2時間リリース後 1日
  67. 67. 5.継続的インテグレーション
  68. 68. 継続的インテグ レーションの導入 と利用促進の7ス テップhttp://bit.ly/soiCFy
  69. 69. http://bit.ly/rVAW90ビルドサーバを用意する
  70. 70. 夜間ビルドを行う http://bit.ly/rubXiA
  71. 71. 夜間ビルド+ コミット時の ユニットテストhttp://bit.ly/s3W9aF
  72. 72. メトリクスの取得http://bit.ly/rYN42H
  73. 73. テストに対する信 頼性と依存性の確 立http://bit.ly/rOloeO
  74. 74. 自動化された受け 入れテスト+デプ ロイ自動化http://bit.ly/sP6BvN
  75. 75. 継続的なデプロイhttp://bit.ly/uc3x59
  76. 76. CIサーバの構築• プロジェクト初期の段階でコードがなくても構 築する• コードのメトリクスや静的解析は初期から継続 的に実施する方が効果がある• 常にグリーン(Jenkinsなら青)の状態を保ち、エ ラーがある状態に慣れない• 常にグリーンに保つにはアトミックな単位での 作業、マイグレーションとの連携、チームのコ ミットに対する態度が欠かせない
  77. 77. Jenkinsでの例
  78. 78. CIゕンチパターン• 頻繁にSCMにコミットしない• テストコードを書かない• テストコードと製品コードを同時にコミットしない• 定時ビルドのみでコミットビルドがない・夜間ビルドしかない• 帰り際にコミットしてそのままCIの結果を見ずに帰る• CIでテストを通すために手作業の準備が必要• メインラインのみで大きなブランチをCI対象にしていない• 様々な種類のテストをまとめて行っている• ビルドの失敗に気付かない• ビルドに失敗しても放置している
  79. 79. CIゕンチパターン• ビルドの失敗に気づいても、修正コード以外のコードをコミットす る• 何も変更していないのにビルドが落ちたり落ちなかったりする• 頻繁にビルドが失敗しているので、失敗するのが普通だと思う• CIからの通知メッセージが大量すぎる• CIが落ちても何も通知しない• CIサーバのリソースが貧弱• ビルドが肥大化して結果が出るまでに時間がかかる• 本番環境やステージング環境と大幅に環境が異なる• コードの静的解析をCIで行わずに人手で行う• CIサーバがおかしくなったときに直せる人がいない• ずっとCIでのチェック内容が変わらない、プロセスが変わらない
  80. 80. 第1象限での自動評価プロジェクトの特性や要員構成等に応じて決めるテスト件数と結果(単体、結合) PMD警告件数Checkstyle警告件数 カバレージ
  81. 81. チーム活動の評価コード行数 コミット時間ゕクテゖビテゖ
  82. 82. 6.マイグレーションの利用
  83. 83. DBスキーマのバージョン管理データベースのスキーマの状態とリリースの状態を関連付けることによって再現可能にする
  84. 84. 既存のゕプローチの問題 http://bit.ly/vbtqZc sqlスクリプトフゔ゗ルは管理が煩雑 sqlスクリプトは自動実行に向かない ロールバックやデータ移行の考慮もしづらい 複数のsqlスクリプトの実行順序の制御が難しい
  85. 85. 問題の例 SQLの実行順序によって状態が変わってしまう1.sql 1→2の順に実行すると….alter table users addcolumn lastlogindatetime after name;2.sqlalter table users addcolumn disabled 2→1の順に実行すると….boolean default falseafter name;
  86. 86. マ゗グレーション(PHPの場合)
  87. 87. データベースの変更管理$ ls -1 前後関係は、フゔ゗ル1301223401_addchangelogs.php1313445291_addinformation.php 先頭の数字の大小で判1317489252_addpriorities.php 断される。1318776293_addprojects.php (規約)1318889397_addremainingtimes.php1320243212_addresolutions.php1321049290_addsprints.php1321509396_addschemamigrations.php1322392147_fix_project_invalid_default_value.php1322446269_add_action_name_to_log.php1322993218_addstories.php1323001299_addstorycomments.php1323449303_addusers.php1324059101_addtasks.php1325101301_addteammembers.php1326548301_addteams.php1327491204_addwiki.php
  88. 88. マ゗グレーションの状態mysql>mysql>mysql>mysql>mysql> select * from migration_version;+---------+| version | 現在30個目のマ゗グレー+---------+ ションフゔ゗ルまで登録| 30 | 済であることを指す+---------+1 row in set (0.08 sec)mysql>mysql>
  89. 89. マ゗グレーション実行 コマンド1つで最新のバージョンに更新したり、 特定のバージョンに戻すことができる# 最新のバージョンへ更新$ php doctrine_cli.php migrate# 指定したバージョンへ更新$ php doctrine_cli.php migrate 29マ゗グレーションフゔ゗ルをソースコードとしてバージョン管理し、CIのビルド定義の中にマ゗グレーションコマン ドを組み込むことで、自動的にDBの状態を連動させる
  90. 90. オープンソースのマイグレーションツールは色々ある!
  91. 91. 7.環境構築自動化
  92. 92. なぜ環境構築の自動化が必要?そもそも時間がかかる数が増えれば単純作業の繰り返し人手による単純作業はミスを誘発ミスした場合でも検知する仕掛けが本番障 害しかない手順書がメンテナンスされないことがある手順書の手順の妥当性の評価が難しい手順の逆転により状態が変わりうる
  93. 93. ミドルや設定゗ンストールの自動化 いつでも クリーンな 動作環境を作れ るようにするhttp://bit.ly/vMHRjL
  94. 94. ミドルや設定゗ンストールの自動化 この自動化に よって後はア プリケーショ ンをデプロイ すればすぐ動 作する状態に するhttp://bit.ly/v30Zl7
  95. 95. ミドルや設定゗ンストールの自動化 http://bit.ly/ttwsmT 本番環境と開発環境の各種 バージョンをあわせる
  96. 96. ミドルや設定゗ンストールの自動化ミドルウェアのバージョンをあげる場合も、この自動化機構を使って行う
  97. 97. 仮想化と自動化(Vagrant)
  98. 98. Vagrantの゗ンストールと起動$ sudo gem install vagrant$ sudo vagrant box add lucid32http://files.vagrantup.com/lucid32.box$ sudo vagrant init$ sudo vagrant upわずか4ステップで、仮想インスタンスが起動する!!
  99. 99. Vagrantフゔ゗ルでの設定 Vagrantファイルで、ベース ボックス名やVirtualBoxの GUI表示の有無、インスタン ス名、メモリ容量、自動実行 するChefのRecipeなどを指 定できる
  100. 100. 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.gemSandbox機能を使うことで、ミドルウェアのバージョンアップの検証や、構成の変更の検証を気軽に行えるようになる。
  101. 101. 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
  102. 102. Chef/Chef-solo
  103. 103. Chefとは? • Ruby製のシステム管理ツール • 出来ること – OSのパッケージのインストールや管理 – OSの設定やミドルウェアの設定 – サービスの起動・停止 – クーロンの設定 • 特徴 – Rubyでジョブや設定を記述する – Chef自体はクライアント/サーバモデル – Chef-soloを使えばローカル単体で動作 – Recipeが多数公開されている
  104. 104. バージョンを指定してパッケージをインストールすることも可能
  105. 105. Cookbook (37signals)
  106. 106. Cookbook(opscode)
  107. 107. その他の選択肢としてPuppet等
  108. 108. 8.デプロイ自動化
  109. 109. http://bit.ly/vd1Ninプロジェクト最初に、(デプロイするものがなくても)デプロイを 自動化する
  110. 110. http://bit.ly/u27Oiz プロジェクトのあ いだ、ずっとデプ ロイスクリプトを 使うことで、プロ セスがテストされ 続ける 開発環境・本番環 境問わず、同じ方 法でデプロイする
  111. 111. デプロイが失敗した場 合にロールバックでき るようにするhttp://bit.ly/vFzaU9
  112. 112. デプロイが途中で失敗 した場合、その先を手 動でやらないhttp://bit.ly/w34bFM
  113. 113. CapistranoRailsゕプリのデプロ゗に利用されることが多いが、もちろんそれ以外にも利用可能。SSHで接続し、サーバに対して色々な操作を行うことが出来る。
  114. 114. 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.
  115. 115. Webistrano
  116. 116. 9.テクニック
  117. 117. ビルド(デプロ゗)パ゗プラ゗ン
  118. 118. ビルド(デプロ゗)パ゗プラ゗ン• SCMへのコミットをトリガーにする• 開発者のリズムを維持するために、最初にユ ニットテストや一部のスモークテストを行い素 早く開発者にフィードバックする• 時間のかかる結合テストや受け入れテストは、 前工程が正常だった場合のみに行う• これによってムダな時間を使わないようにする• ユーザビリティテストや探索的テストのうち自 動化できないものもプロセスとしてはパイプラ イン上に定義• 最後にデプロイできれば、デプロイパイプライ ン
  119. 119. 10.デモ
  120. 120. デモ• Vagrant+Chef-soloによる環境構築• Doctrineによる簡単マイグレーション• Capistrano・Webisitanoによるワンクリックデ プロイ• Jenkins + Capistranoによるデプロイメントパ イプライン

×