CakePHP+Jenkinsによるアジャイル開発 #phpmatsuri

2012/11/3に博多で行われたPHPMatsuri2012で話をした際のスライドです。CakePHPとタイトルにありますが、CakePHPの話はほとんどありませんｗ。内容は過去のワンクリックデプロイ勉強会の再構成です。

Transcript

1. $BLF1)1
   
   +FOLJOT
   ʹΑΔΞδϟΠϧ։ൃ
   2012/11/3 #phpmatsuri Ryutaro YOSHIBA
   
2. ٢Ӌ
   ཾଠ࿠
   Ryutaro  YOSHIBA アジャイルコーチ Web: http://www.ryuzee.com     Twitter:  @ryuzee 認定スクラムプロフェッショナル 認定スクラムマスター 認定スクラムプロダクトオーナー Microsoft  MVP  for  Visual  Studio  ALM
5. SSccrruumm BBoooott CCaammpp
7. http://bit.ly/LtunLe 2013/1/15-­‐16  at  Akihabara  UDX     Scrum  Alliance   Regional  Gathering  Tokyo  2013  
8. ΑΖ͘͠
   ͓ئ͍͠·͢
   
9. εϥΠυ͸ޙͰެ։͠ ·͢ͷͰɺஞ࣍ϝϞΛ औΔͷ͸ແҙຯͰ͢ɻ
   
10. ໿εϥΠυ͋Δ ͷͰ-5ฒʹͿͬͱ͹ ͍͖ͯ͠·͢Ͷʜ
    
11. １．なぜAAggiillee開発か
13. 顧客が説明した要件 顧客が本当に必要 だった物
14. ैདྷܕͷ։ൃϞσϧ
    要件定義 受⼊入テスト 基本設計 総合テスト 詳細設計 結合テスト 実装・単体テスト V字モデル ͕͔͔࣌ؒΓ͗ͯ͢ɺग़དྷ ͨࠒʹ͸ཁٻ͕มԽɻͦ΋ ͦ΋ཁ͕͍݅͋ͬͯͳ͍͜ ͱ͕͜͜Ͱ෼͔Δ
    
15. ैདྷͷ΍ΓํͰ͋Γ͕ͪͳ࿩
    要件定義は順調です ◦◦設計は順調です 開発は遅れてますが、挽回可能です 結合試験で重⼤大な問題が出ています 受⼊入試験でニーズ不不⼀一致が判明 多くのリスクが後半に顕在化 http://www.flickr.com/photos/kwazar/2289418010/ リリースできません。てへっ
16. 付加価値を 高めない 各種現象や 結果を ムダ と呼ぶ
17. ü 作り過ぎのムダ ü 手待ちのムダ ü 運搬のムダ ü 加工のムダ ü 在庫のムダ ü 動作のムダ ü 不良をつくるムダ
18. γεςϜͷػೳͷར༻ׂ߹
    4455 %% 1199 %% 1166 %% 1133 %% 77 %% Standishの2000年年の調査より   いつも使う よく使う たまに使う ほとんど使わない まったく使わない
19. 6644%% の機能は、使われない http://bit.ly/olku51
20. ΞδϟΠϧϚχϑΣετ
    11..  プロセスやツールより人と人同士の相互 作用を重視する。 22..  包括的なドキュメントより動作するソフ トウェアを重視する。 33..  契約上の交渉よりも顧客との協調を重視 する。 44..  計画に従うことよりも変化に対応する ことを重視する。 顧客満足を最優先し、 価値のあるソフトウェアを 早く継続的に提供します。
21. マーケットに製品 を早期に投入�して 投資を回収し利益 に結びつける必要 性がある
22. AAggiilleeな開発 してますか？ h-p://bit.ly/shZMnK
23. ձ৔ௐࠪ
    •  全員起⽴立立してください •  ユニットテストを書いていない⽅方は着席 •  結合テストを⾃自動化していない⽅方は着席 •  継続的インテグレーションサーバを使っていな い⽅方は着席 •  デプロイを⾃自動化していない⽅方は着席 •  環境構築を⾃自動化していない⽅方は着席 最後まで起立されている方は 帰って大丈夫ですｗ
24. http://bit.ly/vPmiFJ 一日にしてならず
25. http://bit.ly/vj0b0v NNoo SSiillvveerr BBuulllleett† 
26. http://bit.ly/sygcE9 自分たちのプロセス は自分たちで進化さ せるしかない！
27. 製品そのものを AAggiilleeな状態に 保つ
28. 技術的負債を 少なく保つ
29. ２．SSccrruummとは
30. 4DSVNͱ͸ʁ
    可能な限り価値の高いプロダク トを生産的かつ創造的に届ける ためのもの
31. 野中郁次郎郎⽒氏 ジェフ・ サザーランド⽒氏
32. hhttttpp:://// wwwwww..ssccrruumm..oorrgg// ssccrruummgguuiiddeess// 参考リソース
33. 複雑で変化の激しい 問題に対応するための 仕事の進め方
34. プロダクトバックログ 製品の機能をストーリー形式で記載 プロダクトオーナーが優先順位を付け、プラ ンニングポーカーで相対⾒見見積もり。 項⽬目の追加はいつでも⾃自由だが実施有無や優 先順位はPOが決める。 チーム  (6±3⼈人) プロダクトの開発を⾏行行う。 製品の成功に向けて最⼤大限 の努⼒力力をコミットする スクラムマスター スクラムプロセスがうまく いくようにする。 外部からチームを守る プロダクトオーナー 製品に対して責任をもち機能 に優先順位を付ける ステークホルダー 製品の利利⽤用者、出資者、管理理職 などの利利害関係者。鶏と称す スプリントバックログ そのスプリント期間中に⾏行行う タスクのリスト スプリント 最⼤大4週間までのタイムボックス 各スプリントの⻑⾧長さは同⼀一。この間は外部 からの変更更を受け⼊入れない スプリントレビュー スプリント中の成果である 動作するソフトウェアをデモ する レトロスペクティブ スプリントの中での改善事項 を話合い次に繋げる 複 数 回 ス プ リ ン ト を 繰 り 返 す 出荷可能な 製品の増分 スプリント計画会議 プロダクトバックログを再度度分析・評価し、 そのスプリントで開発するプロダクトバック ログアイテムを選択する。また選択した項⽬目 をタスクにばらす 完了了の定義 何をもって「完了了」とするかを 定義したリスト 毎⽇日の繰り返し デイリースクラム 毎⽇日チームが以下の３つの質問に答える ・昨⽇日やったこと ・今⽇日やること ・困っていること バーンダウンチャート スプリントタスクの「推定残り時間」を 更更新してグラフにプロットする タスク 時間で⾒見見 積もり
35. ಉ͡ϖʔεͰ
    正 #1 #2 #3 #N #1 #2 #3 #N 誤
36. େࣄͳ΋ͷ͸ઌʹʂ
    欲しいものを リストにして 順位をつける。 順位は状況に よって変わる。 1番⽬目にほしい 2番⽬目にほしい 3番⽬目にほしい 4番⽬目にほしい 5番⽬目にほしい 呍 呍 呍 99番⽬目にほしい 100番⽬目にほしい
37. ग़ՙՄೳʁ
    部品だけでは出荷できない 小さくても使えるものを作る
38. ग़ՙՄೳʁ
    ここまでできれば 終わりだと思って たんだけど… これもあれもでき てないじゃない？
39. ϞϊΛ࡞Δ
    http://bit.ly/N4I8LV チームで進める
40. ੒Ռ෺ͷසൟͳ֬ೝ
    1番⽬目にほしい 2番⽬目にほしい 3番⽬目にほしい 4番⽬目にほしい 5番⽬目にほしい 呍 呍 呍 99番⽬目にほしい 100番⽬目にほしい よし頼んだ通りなのでOKです。 完了了だ！ あれ、ここクリックすると遷移先 が違うね。これは未完了了 あ、こうなるのか。頼んだ通りだ から完了了だけど、次のスプリント で機能追加しようか！ この感じだと、秋ごろリ リースかな。次のスプリ ントはこの内容でどう？
41. ϑΟʔυόοΫϧʔϓ
    短いスプリント単位で 頻繁に確認と調整を行い 製品をよりよくする もちろん仕事の やり方ももっと うまくできるはず
42. ܁Γฦ͢ʜ
    タイムボックスを繰り返して ü PPOOがほしいものから順に ü 出荷可能な製品を届け続ける ü うまく届けられるように改�善 し続ける #1 #2 #3 #N
43. SSccrruummで技術面が大事ではな いなんて一言もいってない
44. ڞ௨ཧղ
    完了の定義を作り、何をもっ て出荷可能かを定める。 コード レビュー チェックイン ユニット テスト カバレージ ドキュメント セキュリティ 性能 デプロイ 技術面も当然大事 →XXPPと組み合わせる などなど
45. ３．XXPPとテスト自動化
46. 91
    r
    ݸͷϓϥΫςΟε
    反復 メタファー 作業空間 ふりかえり テスト駆動開発 ペアプロ リファクタリング コードの   共同所有 継続的インテグ レーション YAGNI 責任 擁護 四半期毎の   見直し ミラー 持続可能な   ペース ストーリー作成 リリース計画 受け入れテスト 短期リリース
47. h-p://bit.ly/QqTATG Kent  Beck
48. ITアーキテクト「機能テストの⾃自動化について考える」 　 より引⽤用 http://www.itarchitect.jp/print/?menu3=24601 テスト自動化の損益分岐点 は相当早期にある感覚
49. 4DSVNʴ91
    ü  Scrumではフレームワークの定義のみで、テスト ⾃自動化については触れられていない.しかしアジャ イル開発においてはテスト⾃自動化は必須 ⼩小規模リリー スのたびに⼿手 動でテストす るとコード ベースが⼤大き くなるにつれ てテストコス トが膨らむ ⾃自動化しないとソフトウェア規模に応じて、テスト⼯工数の占め る割合が増加してき価値への投資が減少する アジャイルかウォーターフォールかという話では なく、現代のソフトウェアのライフサイクルを考 慮すると、テスト自動化は当然の流れと言える
50. デプロイするたびに人手 で全体をテストするのは 無理 http://bit.ly/shZMnK
51. テ ス ト し て い な い も の を 目 を 瞑 っ て デ プ ロ イ し て は い け な い http://bit.ly/rAOG9h
52. 清水の舞台から 飛び降りない http://bit.ly/tnB8i0
53. ΞδϟΠϧͰͷ඼࣭ͷ࡞Γ͜Έ 4DSVNͷ৔߹
    Cancel Gift  wrap Return スプリント 2~∼4週間 返品 スプリントゴール スプリント バックログ 出荷可能な製品の 積み上げ プロダクトバックログ クーポン ギフト包装 クーポン キャンセル 24時間 単体テスト、結合テスト、 受け⼊入れテストがスプリン ト単位(もしくはリリース単 位)で⾏行行われる.
54. 【⾃自動と⼿手動】 機能テスト ストーリーテスト プロトタイプ シミュレーション 【⼿手動】※1 探索索的テスト シナリオテスト ユーザビリティテスト ユーザー受⼊入テスト アルファ版、ベータ版 【⾃自動化】 単体テスト コンポーネントテスト 【ツール】 パフォーマンステスト 負荷テスト セキュリティテスト 第１象限 第２象限 第３象限 第４象限 技術⾯面（技術的品質） ビジネス⾯面（ビジネス的品質） チ ー ム を ⽀支 援 製 品 を 批 評 ςετͷ৅ݶ
    ※1  ATDD等では⾃自動化
55. 【⾃自動と⼿手動】 機能テスト ストーリーテスト プロトタイプ シミュレーション 【⼿手動】 探索索的テスト シナリオテスト ユーザビリティテスト ユーザー受⼊入テスト アルファ版、ベータ版 【⾃自動化】 単体テスト コンポーネントテスト 【ツール】 パフォーマンステスト 負荷テスト セキュリティテスト 第１象限 第２象限 第３象限 第４象限 技術⾯面（技術的品質） ビジネス⾯面（ビジネス的品質） チ ー ム を ⽀支 援 製 品 を 批 評 πʔϧɾख๏ͷϚοϐϯά ྫ
    TDD PHPUnit PMD,  CPD  … Jmeter WebScarab RatProxy  … Selenium Behat RobotFramework… CI推奨 CI推奨 CI必須 ⼀一部CI可能
56. ςετࣗಈԽͷਐΊํ
    プロダクトバックログ テスト⾃自動化バックログ スプリント バックログ レガシーコードにおい て、製品コードの開発 をとめて自動化のみへ 投資するのは現実的に 難しいので、投資割合 をきめて、予めバック ログに組み込むことが 望ましい
57. ໰୊मਖ਼ʹ͔͔Δ࣌ؒ
    フェーズ 修正までの時間 要求や設計 5分 コードやユニットテスト 15分 結合テストやシステムテスト 1時間 ベータテスト 2時間 リリース後 1⽇日
58. 1)16OJUԽ
    •  〜～CakePHP  1.3 SimpleTest •  CakePHP  2〜～          PHPUnit •  デファクトのライブラリへ変更更 •  テストを作りやすい •  xdebugとの連携が容易易でCoverageの取得がし やすい •  ̶—log-‐‑‒junitオプションによる結果のXML出⼒力力が 可能でJenkinsと連携しやすい
59. #BLFͰςετϑΝΠϧࣗಈੜ੒
    
60. h-p://www.flickr.com/photos/clintjcl/4298588359 #BLFΛపఈతʹར༻͠·͘Δ
    
61. ςετͷྫ
    他の箇所はbakeコマ ンドによる⾃自動⽣生成。 実際のテストの記述に 集中できる
62. ςετΛબ୒࣮ͯ͠ߦ
    
63. ·ͱΊͯςετΛ࣮ߦ
    ⼀一括実⾏行行⽤用のテストクラスを作成する
64. ·ͱΊͯςετΛ࣮ߦ
    テストを記述するときに@groupを使えばさらに便便利利
65. 1)16OJU༻ઃఆϑΝΠϧͷར༻
    <phpunit> <logging> <log  type="coverage-‐‑‒html"  target="./reports/coverage_̲html/"   title="My  Project"  charset="UTF-‐‑‒8"  yui="true"  highlight="true"   lowUpperBound="35"  highLowerBound="70"/> <log  type="coverage-‐‑‒clover"  target="./reports/coverage.xml"/> <log  type="junit"  target="./reports/unittest.xml"   logIncompleteSkipped="false"/> </logging> <filter>    <blacklist>        <directory  suffix=".php">lib</directory>        <directory  suffix=".php">app/Test</directory>        <directory  suffix=".php">app/Vendor</directory>        <directory  suffix=".php">app/Lib</directory>    </blacklist> </filter> </phpunit>
66. ςετ͠΍͘͢࡞Δඞཁ
    h-p://www.flickr.com/photos/spackletoe/90811910/
67. ² ςετͷ࣮ߦ࣌ؒΛ୹͘ɺґଘؔ܎Λগͳ͘
    ² ࣗ৴ͷͳ͍ՕॴΛςετ
    ² ໰୊͸࣮૷Օॴʹ͍ۙͱ͜ΖͰݟ͚ͭΔ
    ² Ϟσϧɺϔϧύʔɺίϯϙʔωϯτ୯ҐͰͷς ετΛॻ͘
    ² ίϯτϩʔϥʔͷςετΛ୔ࢁॻ͔͟ΔΛಘͳ ͍ͷ͸ɺ'BU
    $POUSPMMFS΍ີ݁߹ͷূ
    ² ͦ͏ͳΔલʹϖΞϓϩɺίʔυϨϏϡʔɺ5%%ɺ ϦϑΝΫλϦϯά
    
68. h-p://www.flickr.com/photos/Omothymorgan/75593157/ खൈ͖ͷ'JYUVSF͸ͬ͠΃ฦ͋͠Γ
    app.user   app.user2   app.user3   app.user4   app.user_test_foo   app.user_test_bar   app.role   app.role2   app.role_test_foo_and_bar   app.group   app.group2   …….
69. ４．継続的 インテグレーション
71. ܧଓతΠϯςάϨʔγϣϯ
    
72. http://bit.ly/soiCFy 継続的インテグ レーションの導入� と利用促進の７ス テップ
73. 1 ビルドサーバを 用意する http://bit.ly/rVAW90 ˗࢒ΓϞϊͷ͠ΐ΅͍΋ͷ͸࢖͏ͳ
    
74. http://bit.ly/rubXiA 2 夜間ビルドを 行う ˗ෆे෼͕ͩͳ͍ΑΓ͸Ϛγ
    
75. 3 夜間ビルド＋ コミット時の ユニットテスト http://bit.ly/s3W9aF ˗ฏۉతͳঢ়ଶ
    
76. 4 メトリクスの取得 http://bit.ly/rYN42H ˗औಘͷ໨త͕ͳ͍ͱແҙຯʜ
    
77. 5 テストに対する信 頼性と依存性の確 立 http://bit.ly/rOloeO ˗͜Ε͕ͳ͍ͱෆ҆ͳঢ়ଶ
    
78. http://bit.ly/sP6BvN 6 自動化された受け 入�れテスト＋デプ ロイ自動化 ˗Ұؾ௨؏ͷ؀ڥ
    
79. 7 継続的なデプロイ http://bit.ly/uc3x59 ˗։ൃϓϩηεͷ੒ख़Խ
    
80. $*αʔόͷߏங
    •  プロジェクト初期の段階でコードがなくても構 築する •  コードのメトリクスや静的解析は初期から継続 的に実施する⽅方が効果がある •  常にグリーン(Jenkinsなら⻘青)の状態を保ち、エ ラーがある状態に慣れない •  常にグリーンに保つにはアトミックな単位での 作業、マイグレーションとの連携、チームのコ ミットに対する態度度が⽋欠かせない
81. $*Ξϯνύλʔϯ
    •  頻繁にSCMにコミットしない •  テストコードを書かない •  テストコードと製品コードを同時にコミットし ない •  定時ビルドのみでコミットビルドがない・夜間 ビルドしかない •  帰り際にコミットしてそのままCIの結果を⾒見見ず に帰る •  CIでテストを通すために⼿手作業の準備が必要 •  メインラインのみで⼤大きなブランチをCI対象に していない
82. $*Ξϯνύλʔϯ
    •  様々な種類のテストをまとめて⾏行行っている •  ビルドの失敗に気付かない •  ビルドに失敗しても放置している •  ビルドの失敗に気づいても、修正コード以外の コードをコミットする •  何も変更更していないのにビルドが落落ちたり落落ち なかったりする •  頻繁にビルドが失敗しているので、失敗するの が普通だと思う •  CIからの通知メッセージが⼤大量量すぎる •  CIが落落ちても何も通知しない
83. $*Ξϯνύλʔϯ
    •  CIサーバのリソースが貧弱 •  ビルドが肥⼤大化して結果が出るまでに時間がか かる •  本番環境やステージング環境と⼤大幅に環境が異異 なる •  コードの静的解析をCIで⾏行行わずに⼈人⼿手で⾏行行う •  CIサーバがおかしくなったときに直せる⼈人がい ない •  ずっとCIでのチェック内容が変わらない、プロ セスが変わらない
84. $BLF1)1༻ʹ+FOLJOTΛઃఆ
    xUnit  Plugin テスト結果のjunit互換xmlを取り込む Checkstyle  plugin PHP_̲CodeSnifferのチェック結果を取 り込む Javadoc  Plugin phpDocumentorの結果を取り込む PMD  Plugin PHPMDのチェック結果を取り込む Clover  Plugin カバレッジの計算結果を取り込む DRY  Plugin コピペ分析の結果を取り込む
85. Ϗϧυͷఆٛ
    ワークスペースに移動して、コマンドラインでのテス トを同じことをするようにシェルスクリプトを記述。
86. ΧόϨʔδΛࣗಈूܭ
    
87. ΧόϨοδ͕ҰఆҎԼʹͳͬͨΒ
    ϏϧυΛ6/45"#-&ʹ͢Δ
    
88. Ϗϧυ͕ίέͨΒޫͱԻͰ௨஌
    h-p://bit.ly/VHe7VW ArduinoとJenkins  APIの連携
89. 1)1@$PEF4OJGGFS
    
90. $BLF1)1༻ʹઃఆ͢Δ
    CakePHP⽤用のコーディング規約の導⼊入 pear  channel-‐‑‒discover  pear.cakephp.org pear  install  cakephp/CakePHP_̲CodeSniffer 実⾏行行(概要) phpcs  -‐‑‒-‐‑‒report=summary    -‐‑‒-‐‑‒ standard=CakePHP  -‐‑‒-‐‑‒extensions=php  ./app 実⾏行行(詳細) phpcs  -‐‑‒-‐‑‒report=checkstyle  -‐‑‒-‐‑‒report-‐‑‒ checkstyle=./reports/checkstyle.xml  \ -‐‑‒-‐‑‒extensions=php  ./app
91. +FOLJOTͱ૊Έ߹ΘͤΔ
    ビルド定義 cd  ${WORKSPACE}  &&  phpcs  -‐‑‒-‐‑‒report=checkstyle  \ -‐‑‒-‐‑‒report-‐‑‒checkstyle=${WORKSPACE}/reports/checkstyle.xml  \ -‐‑‒-‐‑‒standard=CakePHP  -‐‑‒-‐‑‒extensions=php  \ -‐‑‒-‐‑‒ignore=Vendor/*,Plugin/*  ./app  ||  id
92. QIQ%PDVNFOUPS
    h-p://pear.phpdoc.org/
93. QIQDQE
      h-ps://github.com/sebasOanbergmann/phpcpd
94. 1)1.%
    h-p://phpmd.org/
95. h-p://jenkins-­‐php.org/
97. ５．マイグレーション
98. %#εΩʔϚͷόʔδϣϯ؅ཧ
    データベースのスキーマの状態とリリース の状態を関連付けることによって再現可能 にする
99. طଘͷΞϓϩʔνͷ໰୊
    ü  sqlスクリプトファイルは管理理が煩雑 ü  sqlスクリプトは⾃自動実⾏行行に向かない ü  ロールバックやデータ移⾏行行の考慮もしづらい ü  複数のsqlスクリプトの実⾏行行順序の制御が難しい http://bit.ly/vbtqZc
100. ໰୊ͷྫ
     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の順に実⾏行行すると….
101. $BLF%$.JHSBUJPO
     $  cd  <project> $  git  submodule  add  git://github.com/ CakeDC/migrations.git  app/Plugin/Migrations $  vi  app/Config/bootstrap.php
102. ϚΠάϨʔγϣϯ࣮ߦ
     $  Console/cake  Migrations.migration  run Cake  Migration  Shell -‐‑‒-‐‑‒-‐‑‒-‐‑‒-‐‑‒-‐‑‒-‐‑‒-‐‑‒-‐‑‒-‐‑‒-‐‑‒-‐‑‒-‐‑‒-‐‑‒-‐‑‒-‐‑‒-‐‑‒-‐‑‒-‐‑‒-‐‑‒-‐‑‒-‐‑‒-‐‑‒-‐‑‒-‐‑‒-‐‑‒-‐‑‒-‐‑‒-‐‑‒-‐‑‒-‐‑‒-‐‑‒-‐‑‒-‐‑‒-‐‑‒-‐‑‒-‐‑‒-‐‑‒-‐‑‒-‐‑‒-‐‑‒-‐‑‒-‐‑‒-‐‑‒-‐‑‒-‐‑‒-‐‑‒-‐‑‒-‐‑‒-‐‑‒-‐‑‒-‐‑‒-‐‑‒-‐‑‒-‐‑‒-‐‑‒-‐‑‒-‐‑‒-‐‑‒-‐‑‒-‐‑‒-‐‑‒-‐‑‒ Available  migrations:    [1351374894]  1351374894_̲add_̲items                not  applied -‐‑‒-‐‑‒-‐‑‒-‐‑‒-‐‑‒-‐‑‒-‐‑‒-‐‑‒-‐‑‒-‐‑‒-‐‑‒-‐‑‒-‐‑‒-‐‑‒-‐‑‒-‐‑‒-‐‑‒-‐‑‒-‐‑‒-‐‑‒-‐‑‒-‐‑‒-‐‑‒-‐‑‒-‐‑‒-‐‑‒-‐‑‒-‐‑‒-‐‑‒-‐‑‒-‐‑‒-‐‑‒-‐‑‒-‐‑‒-‐‑‒-‐‑‒-‐‑‒-‐‑‒-‐‑‒-‐‑‒-‐‑‒-‐‑‒-‐‑‒-‐‑‒-‐‑‒-‐‑‒-‐‑‒-‐‑‒-‐‑‒-‐‑‒-‐‑‒-‐‑‒-‐‑‒-‐‑‒-‐‑‒-‐‑‒-‐‑‒-‐‑‒-‐‑‒-‐‑‒-‐‑‒-‐‑‒-‐‑‒ Please,  choose  what  version  you  want  to  migrate  to.  [q]uit  or   [c]lean.     >  1351374894 -‐‑‒-‐‑‒-‐‑‒-‐‑‒-‐‑‒-‐‑‒-‐‑‒-‐‑‒-‐‑‒-‐‑‒-‐‑‒-‐‑‒-‐‑‒-‐‑‒-‐‑‒-‐‑‒-‐‑‒-‐‑‒-‐‑‒-‐‑‒-‐‑‒-‐‑‒-‐‑‒-‐‑‒-‐‑‒-‐‑‒-‐‑‒-‐‑‒-‐‑‒-‐‑‒-‐‑‒-‐‑‒-‐‑‒-‐‑‒-‐‑‒-‐‑‒-‐‑‒-‐‑‒-‐‑‒-‐‑‒-‐‑‒-‐‑‒-‐‑‒-‐‑‒-‐‑‒-‐‑‒-‐‑‒-‐‑‒-‐‑‒-‐‑‒-‐‑‒-‐‑‒-‐‑‒-‐‑‒-‐‑‒-‐‑‒-‐‑‒-‐‑‒-‐‑‒-‐‑‒-‐‑‒-‐‑‒-‐‑‒ Running  migrations:    [1351374894]  1351374894_̲add_̲items            >  Creating  table  items. All  migrations  have  completed. コマンド１つで最新のバージョンに更更新したり、 特定のバージョンに戻すことができる マイグレーションファイルをソースコードとしてバージョ ン管理理し、CIのビルド定義の中にマイグレーションコマン ドを組み込むことで、⾃自動的にDBの状態を連動させる
103. ６．デプロイ自動化
104. プロジェクト最初に、 ((デプロイするものが なくても))デプロイを 自動化する http://bit.ly/vd1Nin
105. プロジェクトのあ いだ、ずっとデプ ロイスクリプトを 使うことで、プロ セスがテストされ 続ける 開発環境・本番環 境問わず、同じ方 法でデプロイする http://bit.ly/u27Oiz
106. デプロイが失敗した場 合にロールバックでき るようにする http://bit.ly/vFzaU9
107. デプロイが途中で失敗 した場合、その先を手 動でやらない http://bit.ly/w34bFM
108. $BQJTUSBOP
     Railsアプリのデプロイに利利⽤用されることが多いが、もちろんそ れ以外にも利利⽤用可能。SSHで接続し、サーバに対して⾊色々な操作 を⾏行行うことが出来る。
110. DBQίϚϯυ
     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.
111. 8FCJTUSBOP
     
112. $BLF1)1Ͱ΋$BQJTUSBOPͷར༻
     Capcake使わなくてもOK
114. ７．環境構築自動化
115. ͳͥ؀ڥߏஙͷࣗಈԽ͕ඞཁʁ
     ü そもそも時間がかかる ü 数が増えれば単純作業の繰り返し ü ⼈人⼿手による単純作業はミスを誘発 ü ミスした場合でも検知する仕掛けが本番障 害しかない ü ⼿手順書がメンテナンスされないことがある ü ⼿手順書の⼿手順の妥当性の評価が難しい ü ⼿手順の逆転により状態が変わりうる
116. ϛυϧ΍ઃఆΠϯετʔϧͷࣗಈԽ
     いつでも クリーンな 動作環境を作れ るようにする http://bit.ly/vMHRjL
117. ϛυϧ΍ઃఆΠϯετʔϧͷࣗಈԽ
     この自動化に よって後はア プリケーショ ンをデプロイ すればすぐ動 作する状態に する http://bit.ly/v30Zl7
118. ϛυϧ΍ઃఆΠϯετʔϧͷࣗಈԽ
     本番環境と開発環境の各種 バージョンをあわせる http://bit.ly/ttwsmT
119. ϛυϧ΍ઃఆΠϯετʔϧͷࣗಈԽ
     ミドルウェアのバージョ ンをあげる場合も、この 自動化機構を使って行う
120. Ծ૝ԽͱࣗಈԽʢ7BHSBOUʣ
     
121. 7BHSBOUͷΠϯετʔϧͱىಈ
     $  sudo  gem  install  vagrant   $  sudo  vagrant  box  add  lucid32  h-p:// files.vagrantup.com/lucid32.box   $  sudo  vagrant  init   $  sudo  vagrant  up   わずか４ステップで、仮想イン スタンスが起動する!!!!
122. 7BHSBOUϑΝΠϧͰͷઃఆ
     Vagrantファイルで、ベース ボックス名やVirtualBoxの GUI表⽰示の有無、インスタン ス名、メモリ容量量、⾃自動実⾏行行 するChefのRecipeなどを指 定できる
123. 7BHSBOUͷϓϥάΠϯͰͷ֦ு
     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機能を使うことで、ミドルウェアの バージョンアップの検証や、構成の変更更の検 証を気軽に⾏行行えるようになる。
124. $IFG$IFGTPMP
     
125. $IFGͱ͸ʁ
     •  Ruby製のシステム管理理ツール •  出来ること –  OSのパッケージのインストールや管理理 –  OSの設定やミドルウェアの設定 –  サービスの起動・停⽌止 –  クーロンの設定 •  特徴 –  Rubyでジョブや設定を記述する –  Chef⾃自体はクライアント/サーバモデル –  Chef-‐‑‒soloを使えばローカル単体で動作 –  Recipeが多数公開されている
126. $IFGͷΞʔΩςΫνϟ
     詳しくは⽇日経Linux3⽉月号参照ｗ
127. バージョンを指定し てパッケージをイン ストールすることも 可能
128. ８．継続的デリバリー
129. ܧଓతσϦόϦʔ
     継続的デリバリーとは、ソフトウェア全体のライ フサイクルを通じて常にソフトウェアが本番環境 にリリース可能であるということを意味する。 すなわちどのビルドもボタン一発で、完全に自動 化されたリリースプロセスを通じてリリースする。 それによってビジネス側がビジネス状況に応じて リリース判断できるようになる。 繰り返し型の 開発 継続的 インテグレーション 継続的 デプロイ 継続的デリバリー
130. ܧଓతσϦόϦʔ
     繰り返し型の 開発 継続的 インテグレーション 継続的 デプロイ 継続的デリバリー Scrum u 要求に順位付け u タイムボックス による制御 u 検査と適⽤用によ る継続的改善 u 透明性の確保 u ⾃自⼰己組織型チー ム u 技術的プラク ティスの定義な し Scrum＋XP u xUnit等による テスト⾃自動化 u テスト駆動開発 u コーディング規 約 u ペアプロ等 u 常時出荷可能な 品質を保持 u 主に技術的プラ クティスから構 成される Lean u Just  in  Timeで 顧客が必要なも のを必要なとき に。 u サイクルタイム を測定し改善す る。 u ビジネス活動そ のもの u 全体最適
131. Ϗϧυ σϓϩΠ ύΠϓϥΠϯ
     
132. Ϗϧυ σϓϩΠ ύΠϓϥΠϯ
     •  SCMへのコミットをトリガーにする •  開発者のリズムを維持するために、最初にユ ニットテストや⼀一部のスモークテストを⾏行行い素 早く開発者にフィードバックする •  時間のかかる結合テストや受け⼊入れテストは、 前⼯工程が正常だった場合のみに⾏行行う •  これによってムダな時間を使わないようにする •  ユーザビリティテストや探索索的テストのうち⾃自 動化できないものもプロセスとしてはパイプラ イン上に定義 •  最後にデプロイできれば、デプロイパイプライ ン
133. 毎日何回も本番環境にデプロイで きているか？ 顧客に頻繁に価値を届けられてい るか？
134. ௨ৗͷϦϦʔε
     ü テストが完了してから リリースまで11日以内？ ü テストが完了してから リリースまで33日以内？ ü テストが完了してから リリースまで11週間以内？ ü それ以上かかる？ h-p://bit.ly/wo4eyD
135. ো֐࣌ͷϦϦʔε
     ü テストが完了してからリリースまで11日以内？ ü テストが完了してからリリースまで33日以内？ ü テストが完了してからリリースまで11週間以内？ ü それ以上かかる？ h-p://bit.ly/zeFv2G
136. 障害時に11日でリリース できるのであれば、 今のリリースプロセスに は組織的なムダがある
137. ܧଓతσϦόϦʔͷݪଇ
     ソフトウェアのリ リースやデプロイ のプロセスは繰り 返し可能であり信 頼性が高い必要が ある。 1
138. ܧଓతσϦόϦʔͷݪଇ
     全てを自動化 する 2
139. ܧଓతσϦόϦʔͷݪଇ
     難解なことや苦 痛なことを繰り 返し行い自動化 の方法を考える 3
140. ܧଓతσϦόϦʔͷݪଇ
     全てをソース コード管理シス テムで管理する 4
141. ܧଓతσϦόϦʔͷݪଇ
     完了は「リリー スされたこと」 を意味する 5
142. ܧଓతσϦόϦʔͷݪଇ
     品質を作りこむ 6
143. ܧଓతσϦόϦʔͷݪଇ
     すべての人にリ リースプロセス に対しての責任 がある 7
144. ܧଓతσϦόϦʔͷݪଇ
     継続的に改�善 する 8
145. ·ͱΊ
     ü ϏδωεͷͨΊʹܧଓతʹ੒ՌΛσϦόϦ͢Δ
     ü ͦͷͨΊʹ͸"HJMFͳ΍Γํ͕ඞཁ
     ü $BLF1)1͸"HJMFͳ΍Γํʹ͍͋ͬͯΔ
     ü ςετͷࣗಈԽ͸ඞਢ
     ü +FOLJOTΛ࢖ͬͯৗʹग़ՙՄೳͳঢ়ଶʹอͭ
     ü σϓϩΠ΍؀ڥߏங΋ࣗಈԽ
     ü վળΛ܁Γฦ͢