1. CakePHP + Jenkins によるアジャイル開発 2012/11/3 #phpmatsuri Ryutaro YOSHIBA
2. 吉羽 龍太郎 Ryutaro YOSHIBA アジャイルコーチ Web: http://www.ryuzee.com Twitter: @ryuzee 認定スクラムプロフェッショナル 認定スクラムマスター 認定スクラムプロダクトオーナー Microsoft MVP for Visual Studio ALM
7. 2013/1/15-16 at Akihabara UDX Scrum Alliance Regional Gathering Tokyo 2013 http://bit.ly/LtunLe
9. スライドは後で公開し ますので、逐次メモを 取るのは無意味です。
10. 約140スライドある のでLT並にぶっとば していきますね…
13. 顧客が説明した要件 顧客が本当に必要 だった物
14. 従来型の開発モデル 受⼊テスト 要件定義 基本設計 総合テスト 時間がかかりすぎて、 出来 詳細設計 結合テスト た頃には要求が変化。 そも そも要件があっていな いこ とがここで実装・単体テスト 分かる V字モデル
15. 従来のやり方でありがちな話 要件定義は順調です ○○設計は順調です 開発は遅れてますが、挽回可能です 結合試験で重⼤な問題が出ています 受⼊試験でニーズ不⼀致が判明 リリースできません。てへっ 多くのリスクが後半に顕在化 http://www.flickr.com/photos/kwazar/2289418010/
16. 付加価値を 高めない 各種現象や 結果を ムダ と呼ぶ
17. ü 作り過ぎのムダ ü 手待ちのムダ ü 運搬のムダ ü 加工のムダ ü 在庫のムダ ü 動作のムダ ü 不良をつくるムダ
18. システムの機能の利用割合 いつも使う 7% よく使う 13 % 45 % たまに使う 16 % ほとんど使わない 19 % まったく使わない Standishの2000年の調査より
19. http://bit.ly/olku51 64% の機能は、使われない
20. アジャイルマニフェスト 1. プロセスやツールより人と人同士の相互 作用を重視する。 2. 包括的なドキュメントより動作するソフ 顧客満足を最優先し、 トウェアを重視する。 価値のあるソフトウェアを 3. 契約上の交渉よりも顧客との協調を重視 する。 早く継続的に提供します。 4. 計画に従うことよりも変化に対応する ことを重視する。
21. マーケットに製品 を早期に投入して 投資を回収し利益 に結びつける必要 性がある
22. Agileな開発 してますか？ h-p://bit.ly/shZMnK
23. 会場調査 全員起⽴してください ユニットテストを書いていない⽅は着席 結合テストを⾃動化していない⽅は着席 継続的インテグレーションサーバを使っていな い⽅は着席 • デプロイを⾃動化していない⽅は着席 • 環境構築を⾃動化していない⽅は着席 • • • • 最後まで起立されている方は 帰って大丈夫ですｗ
24. 一日にしてならず http://bit.ly/vPmiFJ
25. No Silver Bullet† http://bit.ly/vj0b0v
26. 自分たちのプロセス は自分たちで進化さ せるしかない！ http://bit.ly/sygcE9
30. Scrumとは？ 可能な限り価値の高いプロダク トを生産的かつ創造的に届ける ためのもの
32. 参考リソース http:// www.scrum.org/ scrumguides/
33. 複雑で変化の激しい 問題に対応するための 仕事の進め方
34. プロダクトオーナー 製品に対して責任をもち機能 に優先順位を付ける スクラムマスター スクラムプロセスがうまく いくようにする。 外部からチームを守る ステークホルダー チーム (6±3⼈) 製品の利⽤者、出資者、管理職 などの利害関係者。鶏と称す プロダクトの開発を⾏う。 製品の成功に向けて最⼤限 の努⼒をコミットする デイリースクラム プロダクトバックログ 製品の機能をストーリー形式で記載 プロダクトオーナーが優先順位を付け、プラ ンニングポーカーで相対⾒積もり。 項⽬の追加はいつでも⾃由だが実施有無や優 先順位はPOが決める。 毎⽇チームが以下の３つの質問に答える ・昨⽇やったこと ・今⽇やること ・困っていること バーンダウンチャート 完了の定義 何をもって「完了」とするかを 定義したリスト スプリント計画会議 スプリントタスクの「推定残り時間」を 更新してグラフにプロットする スプリント プロダクトバックログを再度分析・評価し、 そのスプリントで開発するプロダクトバック ログアイテムを選択する。また選択した項⽬ をタスクにばらす 最⼤4週間までのタイムボックス 各スプリントの⻑さは同⼀。この間は外部 からの変更を受け⼊れない タスク 時間で⾒ 積もり 毎⽇の繰り返し スプリントバックログ そのスプリント期間中に⾏う タスクのリスト スプリントレビュー スプリント中の成果である 動作するソフトウェアをデモ する レトロスペクティブ スプリントの中での改善事項 を話合い次に繋げる 出荷可能な 製品の増分 複 数 回 ス プ リ ン ト を 繰 り 返 す
35. 同じペースで!! 誤 #1 #3 #2 #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. 繰り返す… #1 #2 #3 #N タイムボックスを繰り返して ü POがほしいものから順に ü 出荷可能な製品を届け続ける ü うまく届けられるように改善 し続ける
43. Scrumで技術面が大事ではな いなんて一言もいってない
44. 共通理解 完了の定義を作り、何をもっ て出荷可能かを定める。 コード レビュー チェックイン ユニット テスト カバレージ ドキュメント セキュリティ 性能 デプロイ 技術面も当然大事 →XPと組み合わせる などなど
46. XP ‒ 19個のプラクティス 反復 テスト駆動開発 責任 ストーリー作成 メタファー ペアプロ 擁護 リリース計画 作業空間 リファクタリング 四半期毎の 見直し 受け入れテスト ふりかえり コードの 共同所有 ミラー 短期リリース 継続的インテグ レーション YAGNI 持続可能な ペース
47. Kent Beck h-p://bit.ly/QqTATG
48. ITアーキテクト「機能テストの⾃動化について考える」 より引⽤ http://www.itarchitect.jp/print/?menu3=24601 テスト自動化の損益分岐点 は相当早期にある感覚
49. Scrum＋XP ü Scrumではフレームワークの定義のみで、テスト ⾃動化については触れられていない.しかしアジャ イル開発においてはテスト⾃動化は必須 ⼩規模リリー スのたびに⼿ アジャイルかウォーターフォールかという話では 動でテストす るとコード なく、現代のソフトウェアのライフサイクルを考 ベースが⼤き 慮すると、テスト自動化は当然の流れと言える くなるにつれ てテストコス トが膨らむ ⾃動化しないとソフトウェア規模に応じて、テスト⼯数の占め る割合が増加してき価値への投資が減少する
50. http://bit.ly/shZMnK デプロイするたびに人手 で全体をテストするのは 無理
51. けデもテ なプのス いロをト イ目し しをて て瞑い はっな いてい http://bit.ly/rAOG9h
52. 清水の舞台から 飛び降りない http://bit.ly/tnB8i0
53. アジャイルでの品質の作りこみ Scrumの場合 24時間 スプリント 2~4週間 スプリントゴール 返品 スプリント バックログ キャンセル Return クーポン Gift wrap ギフト包装 Cancel クーポン プロダクトバックログ 出荷可能な製品の 積み上げ 単体テスト、結合テスト、 受け⼊れテストがスプリン ト単位(もしくはリリース単 位)で⾏われる.
54. テストの4象限 ビジネス⾯（ビジネス的品質） 【⾃動と⼿動】 【⼿動】※1 機能テスト ストーリーテスト プロトタイプ シミュレーション 探索的テスト シナリオテスト ユーザビリティテスト ユーザー受⼊テスト アルファ版、ベータ版 ー チ 第２象限 ム を ⽀ 【⾃動化】 援 単体テスト コンポーネントテスト 第３象限 【ツール】 パフォーマンステスト 負荷テスト セキュリティテスト 第１象限 技術⾯（技術的品質） ※1 ATDD等では⾃動化 第４象限 製 品 を 批 評
55. ツール・手法のマッピング(例) ビジネス⾯（ビジネス的品質） 【⾃動と⼿動】 機能テスト ストーリーテストSelenium プロトタイプ Behat シミュレーション RobotFramework… ー チ CI推奨 第２象限 ム を ⽀ 【⾃動化】 援 単体テスト コンポーネントテスト TDD PHPUnit PMD, CPD … CI必須 第１象限 【⼿動】 探索的テスト シナリオテスト ユーザビリティテスト ユーザー受⼊テスト アルファ版、ベータ版 ⼀部CI可能 第３象限 【ツール】 パフォーマンステスト 負荷テストJmeter セキュリティテスト WebScarab RatProxy … CI推奨 技術⾯（技術的品質） 第４象限 製 品 を 批 評
56. テスト⾃動化バックログ プロダクトバックログ テスト自動化の進め方 スプリント バックログ レガシーコードにおい て、製品コードの開発 をとめて自動化のみへ 投資するのは現実的に 難しいので、投資割合 をきめて、予めバック ログに組み込むことが 望ましい
57. 問題修正にかかる時間 フェーズ 要求や設計 修正までの時間 5分 コードやユニットテスト 15分 結合テストやシステムテスト 1時間 ベータテスト 2時間 リリース後 1⽇
58. PHPUnit化 • 〜CakePHP 1.3 SimpleTest • CakePHP 2〜 PHPUnit • デファクトのライブラリへ変更 • テストを作りやすい • xdebugとの連携が容易でCoverageの取得がし やすい • ̶log-junitオプションによる結果のXML出⼒が 可能でJenkinsと連携しやすい
60. Bakeを徹底的に利用しまくる h-p://www.flickr.com/photos/clintjcl/4298588359
61. テストの例 他の箇所はbakeコマ ンドによる⾃動⽣成。 実際のテストの記述に 集中できる
63. まとめてテストを実行 ⼀括実⾏⽤のテストクラスを作成する
64. まとめてテストを実行 テストを記述するときに@groupを使えばさらに便利
65. PHPUnit用設定ファイルの利用 <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. ² テストの実行時間を短く、依存関係を少なく ² 自信のない箇所をテスト ² 問題は実装箇所に近いところで見つける ² モデル、ヘルパー、コンポーネント単位でのテ ストを書く ² コントローラーのテストを沢山書かざるを得な いのは、Fat Controllerや密結合の証 ² そうなる前にペアプロ、コードレビュー、TDD、 リファクタリング
68. 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 ……. 手抜きのFixtureはしっぺ返しあり h-p://www.flickr.com/photos/Omothymorgan/75593157/
72. 継続的インテグ レーションの導入 と利用促進の７ス テップ http://bit.ly/soiCFy
73. http://bit.ly/rVAW90 1 ビルドサーバを 用意する ◆残りモノのしょぼいものは使うな
74. http://bit.ly/rubXiA 2 夜間ビルドを 行う ◆不十分だがないよりはマシ
75. http://bit.ly/s3W9aF 3 夜間ビルド＋ コミット時の ユニットテスト ◆平均的な状態
76. http://bit.ly/rYN42H 4 メトリクスの取得 ◆取得の目的がないと無意味…
77. http://bit.ly/rOloeO 5 テストに対する信 頼性と依存性の確 立 ◆これがないと不安な状態
78. http://bit.ly/sP6BvN 6 自動化された受け 入れテスト＋デプ ロイ自動化 ◆一気通貫の環境
79. http://bit.ly/uc3x59 7 継続的なデプロイ ◆開発プロセスの成熟化
80. CIサーバの構築 • プロジェクト初期の段階でコードがなくても構 築する • コードのメトリクスや静的解析は初期から継続 的に実施する⽅が効果がある • 常にグリーン(Jenkinsなら⻘)の状態を保ち、エ ラーがある状態に慣れない • 常にグリーンに保つにはアトミックな単位での 作業、マイグレーションとの連携、チームのコ ミットに対する態度が⽋かせない
81. CIアンチパターン • 頻繁にSCMにコミットしない • テストコードを書かない • テストコードと製品コードを同時にコミットし ない • 定時ビルドのみでコミットビルドがない・夜間 ビルドしかない • 帰り際にコミットしてそのままCIの結果を⾒ず に帰る • CIでテストを通すために⼿作業の準備が必要 • メインラインのみで⼤きなブランチをCI対象に していない
82. CIアンチパターン • • • • • • • • 様々な種類のテストをまとめて⾏っている ビルドの失敗に気付かない ビルドに失敗しても放置している ビルドの失敗に気づいても、修正コード以外の コードをコミットする 何も変更していないのにビルドが落ちたり落ち なかったりする 頻繁にビルドが失敗しているので、失敗するの が普通だと思う CIからの通知メッセージが⼤量すぎる CIが落ちても何も通知しない
83. CIアンチパターン • CIサーバのリソースが貧弱 • ビルドが肥⼤化して結果が出るまでに時間がか かる • 本番環境やステージング環境と⼤幅に環境が異 なる • コードの静的解析をCIで⾏わずに⼈⼿で⾏う • CIサーバがおかしくなったときに直せる⼈がい ない • ずっとCIでのチェック内容が変わらない、プロ セスが変わらない
84. CakePHP用にJenkinsを設定 xUnit Plugin テスト結果のjunit互換xmlを取り込む Checkstyle plugin PHP_CodeSnifferのチェック結果を取 り込む Javadoc Plugin phpDocumentorの結果を取り込む PMD Plugin PHPMDのチェック結果を取り込む Clover Plugin カバレッジの計算結果を取り込む DRY Plugin コピペ分析の結果を取り込む
85. ビルドの定義 ワークスペースに移動して、コマンドラインでのテス トを同じことをするようにシェルスクリプトを記述。
87. カバレッジが一定以下になったら ビルドをUNSTABLEにする
88. ビルドがコケたら光と音で通知 ArduinoとJenkins APIの連携 h-p://bit.ly/VHe7VW
90. CakePHP用に設定する CakePHP⽤のコーディング規約の導⼊ pear channel-discover pear.cakephp.org pear install cakephp/CakePHP_CodeSniffer 実⾏(概要) phpcs --report=summary -standard=CakePHP --extensions=php ./app 実⾏(詳細) phpcs --report=checkstyle --reportcheckstyle=./reports/checkstyle.xml \ --extensions=php ./app
91. Jenkinsと組み合わせる ビルド定義 cd ${WORKSPACE} && phpcs --report=checkstyle \ --report-checkstyle=${WORKSPACE}/reports/checkstyle.xml \ --standard=CakePHP --extensions=php \ --ignore=Vendor/*,Plugin/* ./app id
92. phpDocumentor h-p://pear.phpdoc.org/
93. phpcpd h-ps://github.com/sebasOanbergmann/phpcpd
94. PHPMD h-p://phpmd.org/
95. h-p://jenkins-php.org/
98. DBスキーマのバージョン管理 データベースのスキーマの状態とリリース の状態を関連付けることによって再現可能 にする
99. 既存のアプローチの問題 http://bit.ly/vbtqZc ü sqlスクリプトファイルは管理が煩雑 ü sqlスクリプトは⾃動実⾏に向かない ü ロールバックやデータ移⾏の考慮もしづらい ü 複数のsqlスクリプトの実⾏順序の制御が難しい
100. 問題の例 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の順に実⾏すると….
101. CakeDC::Migration $ 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. マイグレーションファイルをソースコードとしてバージョ ン管理し、CIのビルド定義の中にマイグレーションコマン ドを組み込むことで、⾃動的にDBの状態を連動させる All migrations have completed.
104. http://bit.ly/vd1Nin プロジェクト最初に、 (デプロイするものが なくても)デプロイを 自動化する
105. http://bit.ly/u27Oiz プロジェクトのあ いだ、ずっとデプ ロイスクリプトを 使うことで、プロ セスがテストされ 続ける 開発環境・本番環 境問わず、同じ方 法でデプロイする
106. デプロイが失敗した場 合にロールバックでき るようにする http://bit.ly/vFzaU9
107. デプロイが途中で失敗 した場合、その先を手 動でやらない http://bit.ly/w34bFM
108. Capistrano Railsアプリのデプロイに利⽤されることが多いが、もちろんそ れ以外にも利⽤可能。SSHで接続し、サーバに対して⾊々な操作 を⾏うことが出来る。
110. capコマンド cap cap cap cap cap cap cap cap cap cap cap cap cap cap cap cap cap cap cap deploy deploy:check deploy:cleanup deploy:pending deploy:pending:diff deploy:rollback deploy:rollback:code deploy:setup deploy:symlink deploy:update deploy:update_code deploy:upload deploy:web:disable deploy:web:enable develop invoke multistage:prepare production 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.
112. CakePHPでもCapistranoの利用 Capcake使わなくてもOK
115. なぜ環境構築の自動化が必要？ ü そもそも時間がかかる ü 数が増えれば単純作業の繰り返し ü ⼈⼿による単純作業はミスを誘発 ü ミスした場合でも検知する仕掛けが本番障 害しかない ü ⼿順書がメンテナンスされないことがある ü ⼿順書の⼿順の妥当性の評価が難しい ü ⼿順の逆転により状態が変わりうる
116. ミドルや設定インストールの自動化 いつでも クリーンな 動作環境を作れ るようにする http://bit.ly/vMHRjL
117. ミドルや設定インストールの自動化 この自動化に よって後はア プリケーショ ンをデプロイ すればすぐ動 作する状態に する http://bit.ly/v30Zl7
118. ミドルや設定インストールの自動化 http://bit.ly/ttwsmT 本番環境と開発環境の各種 バージョンをあわせる
119. ミドルや設定インストールの自動化 ミドルウェアのバージョ ンをあげる場合も、この 自動化機構を使って行う
121. Vagrantのインストールと起動 $ sudo gem install vagrant $ sudo vagrant box add lucid32 h-p:// files.vagrantup.com/lucid32.box $ sudo vagrant init $ sudo vagrant up わずか４ステップで、仮想イン スタンスが起動する!!
122. Vagrantファイルでの設定 Vagrantファイルで、ベース ボックス名やVirtualBoxの GUI表⽰の有無、インスタン ス名、メモリ容量、⾃動実⾏ するChefのRecipeなどを指 定できる
123. 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機能を使うことで、ミドルウェアの バージョンアップの検証や、構成の変更の検 証を気軽に⾏えるようになる。
125. Chefとは？ • Ruby製のシステム管理ツール • 出来ること – OSのパッケージのインストールや管理 – OSの設定やミドルウェアの設定 – サービスの起動・停⽌ – クーロンの設定 • 特徴 – Rubyでジョブや設定を記述する – Chef⾃体はクライアント/サーバモデル – Chef-soloを使えばローカル単体で動作 – Recipeが多数公開されている
126. Chefのアーキテクチャ 詳しくは⽇経Linux3⽉号参照ｗ
127. バージョンを指定し てパッケージをイン ストールすることも 可能
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 全体最適
132. ビルド(デプロイ)パイプライン • SCMへのコミットをトリガーにする • 開発者のリズムを維持するために、最初にユ ニットテストや⼀部のスモークテストを⾏い素 早く開発者にフィードバックする • 時間のかかる結合テストや受け⼊れテストは、 前⼯程が正常だった場合のみに⾏う • これによってムダな時間を使わないようにする • ユーザビリティテストや探索的テストのうち⾃ 動化できないものもプロセスとしてはパイプラ イン上に定義 • 最後にデプロイできれば、デプロイパイプライ ン
133. 毎日何回も本番環境にデプロイで きているか？ 顧客に頻繁に価値を届けられてい るか？
134. 通常のリリース ü テストが完了してから リリースまで1日以内？ ü テストが完了してから リリースまで3日以内？ ü テストが完了してから リリースまで1週間以内？ ü それ以上かかる？ h-p://bit.ly/wo4eyD
135. 障害時のリリース ü テストが完了してからリリースまで1日以内？ ü テストが完了してからリリースまで3日以内？ ü テストが完了してからリリースまで1週間以内？ ü それ以上かかる？ h-p://bit.ly/zeFv2G
136. 障害時に1日でリリース できるのであれば、 今のリリースプロセスに は組織的なムダがある
137. 継続的デリバリーの8原則 ソフトウェアのリ リースやデプロイ のプロセスは繰り 返し可能であり信 頼性が高い必要が ある。 1
138. 継続的デリバリーの8原則 2 全てを自動化 する
139. 継続的デリバリーの8原則 3 難解なことや苦 痛なことを繰り 返し行い自動化 の方法を考える
140. 継続的デリバリーの8原則 4 全てをソース コード管理シス テムで管理する
141. 継続的デリバリーの8原則 5 完了は「リリー スされたこと」 を意味する
142. 継続的デリバリーの8原則 6 品質を作りこむ
143. 継続的デリバリーの8原則 7 すべての人にリ リースプロセス に対しての責任 がある
144. 継続的デリバリーの8原則 8 継続的に改善 する
145. まとめ ü ビジネスのために継続的に成果をデリバリする ü そのためにはAgileなやり方が必要 ü CakePHPはAgileなやり方にあっている ü テストの自動化は必須 ü Jenkinsを使って常に出荷可能な状態に保つ ü デプロイや環境構築も自動化 ü 改善を繰り返す
