20120721 chefの下準備 #devlove

11,169 views

Published on

2012年7月21日に行われた #devlove のセッション資料です。過去に行ったワンクリックデプロイ勉強会の中身と基本同じです。
その他関連する話はサイトのほうにいろいろ書いていますので、是非 http://www.ryuzee.com/ をご参照ください。不明点があれば@ryuzeeまで。

Published in: Technology
  • Be the first to comment

20120721 chefの下準備 #devlove

  1. 1. 2012/07/21  #devlove CChheeffの下準備 楽しいCCooookkiinnggの その前に!!!! アジャイルコーチ RRyyuuttaarroo YYOOSSHHIIBBAA
  2. 2. 吉羽 龍太郎 Ryutaro  YOSHIBA アジャイルコーチ Web: http://www.ryuzee.com     Twitter:  @ryuzee 認定スクラムプロフェッショナル 認定スクラムマスター 認定スクラムプロダクトオーナー Microsoft  MVP  for  Visual  Studio  ALM
  3. 3. Scrum  Boot  Camp
  4. 4. 2013/1/15-­‐16  at  Akihabara  UDX    Scrum  Regional  Gathering  Tokyo  2013   http://bit.ly/LtunLe
  5. 5. このセッションでは開発や運用における大きな方向�性の話をします。 その理解なくして、俺が楽だから○○使うぜ!とか開発チームの奴らは××だなぁ!とか環境構築チームが△△なせいだ!とか言うのは不毛の極み。
  6. 6. 会場調査•  全員起⽴立立してください•  ユニットテストを書いていない⽅方は着席•  結合テストを⾃自動化していない⽅方は着席•  継続的インテグレーションサーバを使っていな い⽅方は着席•  デプロイを⾃自動化していない⽅方は着席•  環境構築を⾃自動化していない⽅方は着席 最後まで起立されている方は 帰って大丈夫ですw
  7. 7. 一日にしてならず http://bit.ly/vPmiFJ
  8. 8. NNoo SSiillvveerr BBuulllleett†  http://bit.ly/vj0b0v
  9. 9. http://bit.ly/sygcE9自分たちのプロセスは自分たちで進化させるしかない!
  10. 10. 1.ビジネスをとりまく 環境の変化
  11. 11. IITT投資は業務効率化 から戦略実現へ
  12. 12. 以前の競争http://bit.ly/rioQDZ
  13. 13. 現在の競争 競争の速度の変化
  14. 14. 迅速な 意思決定 が必要 http://bit.ly/pccwAN
  15. 15. 意思決定をもとに素早く 具現化する必要 http://bit.ly/r1ziWL
  16. 16. ビジネスモデルの賞味期限が短縮
  17. 17. 変化への対応“事前に綿密” にたてた計画を “長期間遵守” して大丈夫なのか?
  18. 18. 変化への対応“変化が起こる” ことを前提に “頻繁に軌道修正” することが必要 http://bit.ly/oX9ImQ
  19. 19. 変化に対応できなければマーケットから 見捨てられる
  20. 20. 価値がなくなれば滅びるhttp://bit.ly/qJg8EX
  21. 21. マインド イノベーション http://bit.ly/nrDcZf
  22. 22. プロセス プロダクト イノベーション イノベーション http://bit.ly/qpjFXr http://bit.ly/ornfUo
  23. 23. 2.継続的デリバリ
  24. 24. 毎日何回も本番環境にデプロイできているか? 顧客に頻繁に価値を届けられているか?
  25. 25. ワンクリックでデプロイできたとしても、リリースの意思決定に時間がかかったら無意味! http://bit.ly/rZyM3H
  26. 26. 継続的デリバリー 継続的デリバリー 繰り返し型の 継続的 継続的 開発 インテグレーション デプロイ継続的デリバリーとは、ソフトウェア全体のライフサイクルを通じて常にソフトウェアが本番環境にリリース可能であるということを意味する。 すなわちどのビルドもボタン一発で、完全に自動化されたリリースプロセスを通じてリリースする。 それによってビジネス側がビジネス状況に応じてリリース判断できるようになる。
  27. 27. 継続的デリバリー 継続的デリバリー 繰り返し型の 継続的 継続的 開発 インテグレーション デプロイ Scrum Scrum+XP Lean u  要求に順位付け u  xUnit等による u  Just  in  Timeで u  タイムボックス テスト⾃自動化 顧客が必要なも による制御 u  テスト駆動開発 のを必要なとき u  検査と適⽤用によ u  コーディング規 に。 る継続的改善 約 u  サイクルタイム u  透明性の確保 u  ペアプロ等 を測定し改善す u  ⾃自⼰己組織型チー u  常時出荷可能な る。 ム 品質を保持 u  ビジネス活動そ u  技術的プラク u  主に技術的プラ のもの ティスの定義な クティスから構 u  全体最適 し 成される
  28. 28. 継続的デリバリ http://bit.ly/tFrqbzユーザーとプロジェクトチームの間に 固いフィードバックループを作る
  29. 29. 継続的デリバリ http://bit.ly/uLQaml継続的なフィードバックプロセスは、 競争優位性やムダの削減につながる
  30. 30. 継続的デリバリの8原則 ソフトウェアのリ1 リースやデプロイ のプロセスは繰り 返し可能であり信 頼性が高い必要が ある。
  31. 31. 継続的デリバリの8原則2 全てを自動化 する
  32. 32. 継続的デリバリの8原則3 難解なことや苦 痛なことを繰り 返し行い自動化 の方法を考える
  33. 33. 継続的デリバリの8原則4 全てをソース コード管理シス テムで管理する
  34. 34. 継続的デリバリの8原則5 完了は「リリー スされたこと」 を意味する
  35. 35. 継続的デリバリの8原則6 品質を作りこむ
  36. 36. 継続的デリバリの8原則7 すべての人にリ リースプロセス に対しての責任 がある
  37. 37. 継続的デリバリの8原則8 継続的に改�善 する
  38. 38. 継続的デリバリの4プラクティスl バイナリは一度だけビルドする l すべての環境にデプロイするのに 完全に同一のメカニズムを使う l デプロイメントでスモークテスト を実施する l 何か問題が起こったらラインを止 める
  39. 39.    ど の 再断 現面 可で 能も か ? http://bit.ly/uVQu5I
  40. 40. リリースした際に、前のバージョンに即座に戻せるか?これはコードだけでなくデータベース等も含む http://bit.ly/tgbmyr
  41. 41. DRY
  42. 42. Convention OverConfiguration
  43. 43. 3.バージョン管理
  44. 44. ソースコードのバージョン管理理•  いわずもがな。全ての起点はここにある•  コードの共同所有の原則への理理解•  このソースコードは本番環境または開発環境な どで同じように動作しなければならない•  テストを書く習慣、コミット前に他のテストも 含めて通してからコミットする習慣
  45. 45. 設定ファイルのバージョン管理理•  環境によって異異なる設定値(接続先データベー ス情報など)が書かれた設定ファイルもバー ジョン管理理する•  開発環境⽤用、ステージング環境⽤用、本番環境⽤用 などに分けて定義し、容易易に切切り替え可能にす る•  本番環境に配置する際に、アプリケーションの 各所を書き換えなければ動作しないという状況 は避ける
  46. 46. バージョン管理は 開発者のしつけ http://bit.ly/utD8aA
  47. 47. 4.テスト自動化
  48. 48. けデもテ なプのス いロをト イ目し しをて て瞑い はっな いていhttp://bit.ly/rAOG9h
  49. 49. 清水の舞台から 飛び降りない http://bit.ly/tnB8i0
  50. 50. http://bit.ly/shZMnKデプロイするたびに人手で全体をテストするのは無理
  51. 51. ITアーキテクト「機能テストの⾃自動化について考える」  より引⽤用http://www.itarchitect.jp/print/?menu3=24601テスト自動化の損益分岐点は相当早期にある感覚
  52. 52. アジャイルでの品質の作りこみScrumではフレームワークの定義のみで、テスト⾃自動化については触れられていない.しかしアジャイル開発においてはテスト⾃自動化は必須 ⼩小規模リリースのたびに⼿手 動でテストするとスプリン ト後半になるにつれてテス トコストが膨らむ⾃自動化しないとソフトウェア規模に応じて、テスト⼯工数の占める割合が増加していく(=価値への投資が減少)
  53. 53. テストの4象限 ビジネス⾯面(ビジネス的品質) 【⾃自動と⼿手動】 【⼿手動】※1 機能テスト 探索索的テスト ストーリーテスト シナリオテスト プロトタイプ ユーザビリティテスト シミュレーション ユーザー受⼊入テスト チ アルファ版、ベータ版 製 品 ー 第2象限 第3象限 ム を を 批 ⽀支 【⾃自動化】 【ツール】 評 援 単体テスト パフォーマンステスト コンポーネントテスト 負荷テスト セキュリティテスト 第1象限 第4象限 技術⾯面(技術的品質)※1  ATDD等では⾃自動化
  54. 54. テストの4象限 第1象限  チームを⽀支援する技術⾯面のテスト テスト駆動開発などアジャイル開発の中⼼心。 第2象限  チームを⽀支援するビジネス⾯面のテスト 顧客の視点からのハイレベルの機能テストなど。 第3象限  製品を批評するビジネス⾯面のテスト ユーザー受⼊入テスト、探索索的テストなど。 第4象限  技術⾯面のテストを使った製品の批評 パフォーマンステスト、セキュリティテストなど。「アジャイルテスト  ―⾼高品質を追求するアジャイルチームにおけるテストの視点―」増⽥田聡⽒氏http://codezine.jp/devsumi/2010/report/07/  より引⽤用
  55. 55. ツール・⼿手法のマッピング(例例) ビジネス⾯面(ビジネス的品質) 【⾃自動と⼿手動】 【⼿手動】 機能テスト 探索索的テスト Selenium ストーリーテスト シナリオテスト Cucumber プロトタイプ ユーザビリティテスト Rspec シミュレーション ユーザー受⼊入テスト FitNess  … チ アルファ版、ベータ版 製 品 ー CI推奨 第2象限 ⼀一部CI可能 第3象限 ム を を 批 ⽀支 【⾃自動化】 【ツール】 評 援 単体テスト パフォーマンステスト Jmeter コンポーネントテスト TDD 負荷テスト WebScarab xUnit セキュリティテスト RatProxy PMD,  CPD  … ValGrind  … CI必須 第1象限 CI推奨 第4象限 技術⾯面(技術的品質)
  56. 56. テスト⾃自動化の進め⽅方プロダクトバックログ レガシーコードにおい スプリント て、製品コードの開発 バックログ をとめて自動化のみへ 投資するのは現実的に 難しいので、投資割合テスト⾃自動化バックログ をきめて、予めバック ログに組み込むことが 望ましい
  57. 57. 問題修正にかかる時間フェーズ 修正までの時間要求や設計 5分コードやユニットテスト 15分結合テストやシステムテスト 1時間ベータテスト 2時間リリース後 1⽇日
  58. 58. 5.継続的 インテグレーション
  59. 59. 継続的インテグ レーションの導入� と利用促進の7ス テップ http://bit.ly/soiCFy
  60. 60. http://bit.ly/rVAW901 ビルドサーバを 用意する
  61. 61. 2 夜間ビルドを 行う http://bit.ly/rubXiA
  62. 62. 3 http://bit.ly/s3W9aF 夜間ビルド+ コミット時の ユニットテスト
  63. 63. 4 http://bit.ly/rYN42H メトリクスの取得
  64. 64. 5 http://bit.ly/rOloeO テストに対する信 頼性と依存性の確 立
  65. 65. 6 http://bit.ly/sP6BvN 自動化された受け 入�れテスト+デプ ロイ自動化
  66. 66. 7 http://bit.ly/uc3x59 継続的なデプロイ
  67. 67. CIサーバの構築•  プロジェクト初期の段階でコードがなくても構 築する•  コードのメトリクスや静的解析は初期から継続 的に実施する⽅方が効果がある•  常にグリーン(Jenkinsなら⻘青)の状態を保ち、エ ラーがある状態に慣れない•  常にグリーンに保つにはアトミックな単位での 作業、マイグレーションとの連携、チームのコ ミットに対する態度度が⽋欠かせない
  68. 68. Jenkinsでの例例
  69. 69. 第1象限での⾃自動評価プロジェクトの特性や要員構成等に応じて決めるテスト件数と結果(単体、結合) PMD警告件数Checkstyle警告件数 カバレージ
  70. 70. チーム活動の評価コード⾏行行数 コミット時間アクティビティ
  71. 71. 66.マイグレーションの利用
  72. 72. DBスキーマのバージョン管理理データベースのスキーマの状態とリリースの状態を関連付けることによって再現可能にする
  73. 73. 既存のアプローチの問題 http://bit.ly/vbtqZcü  sqlスクリプトファイルは管理理が煩雑ü  sqlスクリプトは⾃自動実⾏行行に向かないü  ロールバックやデータ移⾏行行の考慮もしづらいü  複数のsqlスクリプトの実⾏行行順序の制御が難しい
  74. 74. 問題の例例 SQLの実⾏行行順序によって状態が変わってしまう1.sql 1→2の順に実⾏行行すると….alter  table  users  add  column  lastlogin  datetime  after  name;2.sqlalter  table  users  add  column  disabled   2→1の順に実⾏行行すると….boolean  default  false  after  name;
  75. 75. マイグレーション(PHPの場合)
  76. 76. データベースの変更更管理理$  ls  -‐‑‒11301223401_̲addchangelogs.php 前後関係は、ファイル1313445291_̲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
  77. 77. マイグレーションの状態mysql> mysql> mysql> mysql> mysql> select * from migration_version; +---------+ | version | 現在30個⽬目のマイグレー+---------+ ションファイルまで登録| 30 | 済であることを指す+---------+ 1 row in set (0.08 sec) mysql> mysql>
  78. 78. マイグレーション実⾏行行 コマンド1つで最新のバージョンに更更新したり、 特定のバージョンに戻すことができる #  最新のバージョンへ更更新 $  php  doctrine_̲cli.php  migrate #  指定したバージョンへ更更新 $  php  doctrine_̲cli.php  migrate  29   マイグレーションファイルをソースコードとしてバージョ ン管理理し、CIのビルド定義の中にマイグレーションコマン ドを組み込むことで、⾃自動的にDBの状態を連動させる
  79. 79. オープンソースのマイグレーションツールは色々ある!
  80. 80. 7.環境構築自動化
  81. 81. なぜ環境構築の⾃自動化が必要?ü そもそも時間がかかるü 数が増えれば単純作業の繰り返しü ⼈人⼿手による単純作業はミスを誘発ü ミスした場合でも検知する仕掛けが本番障 害しかないü ⼿手順書がメンテナンスされないことがあるü ⼿手順書の⼿手順の妥当性の評価が難しいü ⼿手順の逆転により状態が変わりうる
  82. 82. ミドルや設定インストールの⾃自動化 いつでも クリーンな 動作環境を作れ るようにする http://bit.ly/vMHRjL
  83. 83. ミドルや設定インストールの⾃自動化 この自動化に よって後はア プリケーショ ンをデプロイ すればすぐ動 作する状態に する http://bit.ly/v30Zl7
  84. 84. ミドルや設定インストールの⾃自動化 http://bit.ly/ttwsmT 本番環境と開発環境の各種 バージョンをあわせる
  85. 85. ミドルや設定インストールの⾃自動化ミドルウェアのバージョンをあげる場合も、この自動化機構を使って行う
  86. 86. 仮想化と⾃自動化(Vagrant)
  87. 87. Vagrantのインストールと起動$  sudo  gem  install  vagrant  $  sudo  vagrant  box  add  lucid32  h<p://files.vagrantup.com/lucid32.box  $  sudo  vagrant  init  $  sudo  vagrant  up  わずか4ステップで、仮想インスタンスが起動する!!!!
  88. 88. Vagrantファイルでの設定 Vagrantファイルで、ベース ボックス名やVirtualBoxの GUI表⽰示の有無、インスタン ス名、メモリ容量量、⾃自動実⾏行行 するChefのRecipeなどを指 定できる
  89. 89. Vagrantのプラグインでの拡張 SaharaによるSandbox機能の導⼊入$  sudo  git  clone  h<ps://github.com/jedi4ever/sahara.git  $  cd  sahara  $  sudo  rake  build  $  cd  pkg  $  sudo  gem  install  ./sahara-­‐0.0.7.gem  Sandbox機能を使うことで、ミドルウェアのバージョンアップの検証や、構成の変更更の検証を気軽に⾏行行えるようになる。
  90. 90. 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
  91. 91. Chef/Chef-‐‑‒solo
  92. 92. Chefとは? •  Ruby製のシステム管理理ツール •  出来ること –  OSのパッケージのインストールや管理理 –  OSの設定やミドルウェアの設定 –  サービスの起動・停⽌止 –  クーロンの設定 •  特徴 –  Rubyでジョブや設定を記述する –  Chef⾃自体はクライアント/サーバモデル –  Chef-‐‑‒soloを使えばローカル単体で動作 –  Recipeが多数公開されている
  93. 93. 全体構成
  94. 94. バージョンを指定してパッケージをインストールすることも可能
  95. 95. Cookbook  (37signals)
  96. 96. Cookbook(opscode)
  97. 97. 8.デプロイ自動化
  98. 98. http://bit.ly/vd1Nin プロジェクト最初に、((デプロイするものがなくても))デプロイを 自動化する
  99. 99. http://bit.ly/u27Oiz プロジェクトのあ いだ、ずっとデプ ロイスクリプトを 使うことで、プロ セスがテストされ 続ける 開発環境・本番環 境問わず、同じ方 法でデプロイする
  100. 100. デプロイが失敗した場 合にロールバックでき るようにする http://bit.ly/vFzaU9
  101. 101. デプロイが途中で失敗 した場合、その先を手 動でやらない http://bit.ly/w34bFM
  102. 102. CapistranoRailsアプリのデプロイに利利⽤用されることが多いが、もちろんそれ以外にも利利⽤用可能。SSHで接続し、サーバに対して⾊色々な操作を⾏行行うことが出来る。
  103. 103. 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.
  104. 104. Webistrano

×