ワンクリックデプロイ 〜いつまで手でデプロイしてるんですか〜 #devsumiA

2013/2/15に目黒雅叙園で行われたデブサミ2013 15-A-7セッションの資料です

1. #devsumi Developers Summit ワンクリックデプロイ ∼いつまで手でデプロイしてるんですか？∼ http://www.flickr.com/photos/nimasadigh/4921186134/ 13年4月24日水曜日 Ryutaro YOSHIBA
2. 吉羽 龍太郎 Ryutaro YOSHIBA クラウド・DevOpsとかの コンサルタント http://www.ryuzee.com/ Twitter: @ryuzee 13年4月24日水曜日
3. 好評発売中! 定価：2520円 http://www.seshop.com/ product/detail/15395/ #scrumbcbook 13年4月24日水曜日
4. 好評発売中! 定価：1680円 主にマネー ジャーや経営者 など上位層向け 定価：2520円 13年4月24日水曜日
5. はじめに 13年4月24日水曜日
6. 本当に必要なものがわかるか？ 13年4月24日水曜日
7. 13年4月24日水曜日
8. 期待のマネジメントに失敗 13年4月24日水曜日
9. システムの機能の利用割合 7% 13% 45% 16% 19% Standishの2000年の調査より 13年4月24日水曜日
10. システムの機能の利用割合 7% 13% 45% 16% まったく使わない ほとんど使わない たまに使う よく使う いつも使う 19% Standishの2000年の調査より 13年4月24日水曜日
11. あなたの開発はムダだらけ？ • 作りすぎのムダ • 手待ちのムダ • 運搬のムダ • 加工のムダ • 在庫のムダ • 動作のムダ • 不良をつくるムダ 13年4月24日水曜日
12. コストの見積りは正しいか？ • 不確実性コーン 13年4月24日水曜日
13. ウォーターフォール(V字) 要件定義 受け入れ試験 基本設計 総合試験 詳細設計 結合試験 製造・単体 13年4月24日水曜日
14. ウォーターフォール(V字) 要件定義 受け入れ試験 ぎ す り か 基本設計 総合試験 か が 要 間 は 時 に 頃 た 来 も 出 そ も て、 そ 。 化 い 変 詳細設計 結合試験 な が い 求 て っ あ る が か 分 要件 で こ こ が と こ 製造・単体 13年4月24日水曜日
15. よくみかける光景 13年4月24日水曜日
16. よくみかける光景 要件定義は順調です 13年4月24日水曜日
17. よくみかける光景 要件定義は順調です ○○設計は順調です 13年4月24日水曜日
18. よくみかける光景 要件定義は順調です ○○設計は順調です 開発は遅れていますが挽回可能です 13年4月24日水曜日
19. よくみかける光景 要件定義は順調です ○○設計は順調です 開発は遅れていますが挽回可能です 結合試験で重大な問題が出ています 13年4月24日水曜日
20. よくみかける光景 要件定義は順調です ○○設計は順調です 開発は遅れていますが挽回可能です 結合試験で重大な問題が出ています 受入れ試験でニーズ不一致が判明 13年4月24日水曜日
21. よくみかける光景 要件定義は順調です ○○設計は順調です 開発は遅れていますが挽回可能です 結合試験で重大な問題が出ています 受入れ試験でニーズ不一致が判明 リリースできません。てへっ 13年4月24日水曜日
22. よくみかける光景 要件定義は順調です ○○設計は順調です 多くのリスクが後半になって顕在 開発は遅れていますが挽回可能です 化する。顕在化した時点では取り 結合試験で重大な問題が出ています 返しがつかない 受入れ試験でニーズ不一致が判明 リリースできません。てへっ 13年4月24日水曜日
23. アジャイルマニフェスト • 2001年に、ケント・ベック、マーティン・ファウラー、ケ ン・シュウェイバーら、17人によって採択された Agileソフトウェア開発の原則を指す。 13年4月24日水曜日
24. アジャイルマニフェスト • プロセスやツールより人と人同士の相互作用を重視する • 包括的なドキュメントより動作するソフトウェアを重視する • 契約上の交渉よりも顧客との協調を重視する • 計画に従うことよりも変化に対応することを重視する 13年4月24日水曜日
25. アジャイルマニフェスト • プロセスやツールより人と人同士の相互作用を重視する • 包括的なドキュメントより動作するソフトウェアを重視する 契約上の交渉よりも顧客との協調を重視する •顧客満足を最優先し、価値のあるソフトウェアを 計画に従うことよりも変化に対応することを重視する •早く継続的に提供します。 13年4月24日水曜日
26. マーケットに製品を 早期に投入して 投資を回収し 利益に結びつける 必要性がある 13年4月24日水曜日
27. Developers Summit • MVPとフィードバックループ • ビジネスの成長とプロダクトの成長を同期させる http://www.flickr.com/photos/pagedooley/2120528888/ 13年4月24日水曜日
28. アジャイルな開発 してますか？ http://bit.ly/shZMnK 13年4月24日水曜日
29. Developers Summit アジャイルの範囲 今日の話は こちら側 平鍋健児氏の資料を許可を得て引用 http://blogs.itmedia.co.jp/hiranabe/2012/09/rightwing-and-leftwing-of-agile.html 13年4月24日水曜日
30. 毎日何回も本番環境にデプロイ できているか？ 顧客に頻繁に価値を届けられて いるか？ 13年4月24日水曜日
31. Developers Summit 1000+ deploys / hour http://bit.ly/XonkX7 13年4月24日水曜日
32. Developers Summit よくある光景 ビジネス 開発 http://www.flickr.com/photos/makitani/3940687822/ 13年4月24日水曜日 運用
33. Developers Summit よくある光景 てめーもっとちゃ んとアプリ作れ ビジネス 開発 http://www.flickr.com/photos/makitani/3940687822/ 13年4月24日水曜日 運用
34. Developers Summit よくある光景 運用でなんとかすんの があんたらの仕事だろ てめーもっとちゃ んとアプリ作れ ビジネス 開発 http://www.flickr.com/photos/makitani/3940687822/ 13年4月24日水曜日 運用
35. Developers Summit よくある光景 運用でなんとかすんの があんたらの仕事だろ てめーもっとちゃ んとアプリ作れ ビジネス 開発 http://www.flickr.com/photos/makitani/3940687822/ 13年4月24日水曜日 運用 あの∼、ビジネス のこと考えてよ
36. Developers Summit 13年4月24日水曜日 会場調査
37. Developers Summit 会場調査 •ユニットテストを書いている方は挙手 13年4月24日水曜日
38. Developers Summit 会場調査 •ユニットテストを書いている方は挙手 •継続的インテグレーションサーバを使っている方は そのまま挙手 13年4月24日水曜日
39. Developers Summit 会場調査 •ユニットテストを書いている方は挙手 •継続的インテグレーションサーバを使っている方は そのまま挙手 •結合テストを自動化している方はそのまま挙手 13年4月24日水曜日
40. Developers Summit 会場調査 •ユニットテストを書いている方は挙手 •継続的インテグレーションサーバを使っている方は そのまま挙手 •結合テストを自動化している方はそのまま挙手 •デプロイを自動化している方はそのまま挙手 13年4月24日水曜日
41. Developers Summit 会場調査 •ユニットテストを書いている方は挙手 •継続的インテグレーションサーバを使っている方は そのまま挙手 •結合テストを自動化している方はそのまま挙手 •デプロイを自動化している方はそのまま挙手 •環境構築を自動化している方はそのまま挙手 13年4月24日水曜日
42. Developers Summit 会場調査 •ユニットテストを書いている方は挙手 •継続的インテグレーションサーバを使っている方は そのまま挙手 最後まで残っていた方は帰って •結合テストを自動化している方はそのまま挙手 大丈夫です！ •デプロイを自動化している方はそのまま挙手 •環境構築を自動化している方はそのまま挙手 13年4月24日水曜日
43. 一日にしてならず http://bit.ly/vPmiFJ 13年4月24日水曜日
44. No Silver Bullet http://bit.ly/vj0b0v 13年4月24日水曜日
45. 自分たちのプロセス は自分たちで進化さ せるしかない 13年4月24日水曜日 http://bit.ly/sygcE9
46. Developers Summit 製品そのものをAgileな状態に保つ 技術的負債を少なく保つ http://www.flickr.com/photos/stuckincustoms/5094583941/ 13年4月24日水曜日
47. 継続的デリバリー 13年4月24日水曜日
48. Developers Summit 13年4月24日水曜日
49. 継続的デリバリーの原則 1 13年4月24日水曜日 ソフトウェアのリ リースやデプロイの プロセスは繰り返し 可能であり信頼性が 高い必要がある。
50. 継続的デリバリーの原則 2 13年4月24日水曜日 全てを自動化する
51. 継続的デリバリーの原則 3 13年4月24日水曜日 難解なことや苦痛な ことを繰り返し行い 自動化の方法を考え る
52. 継続的デリバリーの原則 4 13年4月24日水曜日 全てをソースコード 管理システムで管理 する
53. 継続的デリバリーの原則 5 13年4月24日水曜日 完了は「リリースさ れたこと」を意味す る
54. 継続的デリバリーの原則 6 13年4月24日水曜日 品質を作りこむ
55. 継続的デリバリーの原則 7 13年4月24日水曜日 すべての人にリリー スプロセスに対して の責任がある
56. 継続的デリバリーの原則 8 13年4月24日水曜日 継続的に改善する
57. 継続的デリバリーの4プラクティス • バイナリは一度だけビルドする • すべての環境にデプロイするのに完全に同一の メカニズムを使う • デプロイメントでスモークテストを実施する • 何か問題が起こったらラインを止める 13年4月24日水曜日
58. テスト自動化 13年4月24日水曜日
59. テスト自動化の必要性 小規模リリースのたびに手動でテス トするとコードベースが大きくなるに つれてテストコストが膨らむ • アジャイル開発においてはテスト自動化は必須 • アジャイルかどうかに関係なくソフトウェアのライフサイク ルを考慮する必要がある。 13年4月24日水曜日
60. 自動化されたテストの損益分岐点 ITアーキテクト「機能テストの自動化について考える」  より引用 http://www.itarchitect.jp/print/?menu3=24601 13年4月24日水曜日
61. 自動化されたテストの損益分岐点 テスト自動化にかかるコストよりも 手動テストのコストがすぐ高くなる ITアーキテクト「機能テストの自動化について考える」  より引用 http://www.itarchitect.jp/print/?menu3=24601 13年4月24日水曜日
62. 問題は早めに解決する フェーズ 修正までの時間 要求や設計 5分 コードやユニットテスト 15分 結合テストやシステムテスト 1時間 ベータテスト 2時間 リリース後 1日 • 早く見つけて速く直す 13年4月24日水曜日
63. デプロイのたびに 人手でテストするのは無理 13年4月24日水曜日
64. テストしていない ものを目を瞑って デプロイしてはい けない http://bit.ly/rAOG9h 13年4月24日水曜日
65. テストしていない ものを目を瞑って デプロイしてはい けない 設定ファイル1行だ し大丈夫だよね？ http://bit.ly/rAOG9h 13年4月24日水曜日
66. テストしていない ものを目を瞑って デプロイしてはい けない 悪 http://bit.ly/rAOG9h 13年4月24日水曜日 の 魔 き 囁 設定ファイル1行だ し大丈夫だよね？
67. 清水の舞台から 飛び降りない http://bit.ly/tnB8i0 13年4月24日水曜日
68. アジャイルテストの4象限 13年4月24日水曜日
69. Developers Summit 自動テストに求められる特性 • 繰り返し可能 (Repeatable) • 独立性 (Independent) • 自己検証 (Self validation) • 簡単実行 (Easy) http://www.flickr.com/photos/spackletoe/90811910/ 13年4月24日水曜日
70. Developers Summit Webアプリケーションだと... • テストの実行時間を短く、依存関係を少なく • 自信のない箇所をテスト • 問題は実装箇所に近いところで見つける • モデル、ヘルパー、コンポーネント単位でのテストを書く • コントローラーのテストを沢山書かざるを得ないのは、Fat Controllerや密結合の証 • そうなる前にペアプロ、コードレビュー、TDD、リファクタ リング 13年4月24日水曜日
71. 完了の定義 • 完了の定義を作り、何をもって出荷可能かを定 める • 全部を短い間隔で出来れば頻繁にリリース可能 チェックイン ユニット テスト カバレッジ 75% 結合テスト 受け入れ テスト クロス ブラウザ 静的解析 ドキュメント 性能 セキュリティ デプロイ 13年4月24日水曜日 コード レビュー
72. フィーチャー単位で完了 フィーチャー フィーチャー フィーチャー フィーチャー フィーチャー フィーチャー フィーチャー コードレビュー コードレビュー コードレビュー コードレビュー コードレビュー コードレビュー コードレビュー チェックイン チェックイン チェックイン チェックイン チェックイン チェックイン チェックイン ユニットテスト ユニットテスト ユニットテスト ユニットテスト ユニットテスト ユニットテスト ユニットテスト カバレッジ カバレッジ カバレッジ カバレッジ カバレッジ カバレッジ カバレッジ 静的解析 静的解析 静的解析 静的解析 静的解析 静的解析 静的解析 結合テスト 結合テスト 結合テスト 結合テスト 結合テスト 結合テスト 結合テスト 受け入れテスト 受け入れテスト 受け入れテスト 受け入れテスト 受け入れテスト 受け入れテスト 受け入れテスト クロスブラウザ クロスブラウザ クロスブラウザ クロスブラウザ クロスブラウザ クロスブラウザ クロスブラウザ ドキュメント ドキュメント ドキュメント ドキュメント ドキュメント ドキュメント ドキュメント セキュリティ セキュリティ セキュリティ セキュリティ セキュリティ セキュリティ セキュリティ 性能 性能 性能 性能 性能 性能 性能 デプロイ デプロイ デプロイ デプロイ デプロイ デプロイ デプロイ 13年4月24日水曜日
73. XPのプラクティスの利用 ! ! ! YAGNI 13年4月24日水曜日
74. 13年4月24日水曜日
75. 継続的インテグレーション 13年4月24日水曜日
76. CIサーバ • プロジェクト初期の段階でコードがなくても構築する • コードのメトリクス取得や静的解析は初期から継続的に実施 する方が効果がある • 常にグリーン(Jenkinsなら青)の状態を保ち、エラーがある 状態に慣れない • 常にグリーンに保つにはアトミックな単位での作業、マイグ レーションとの連携、チームのコミットに対する態度が欠か せない 13年4月24日水曜日
77. CIアンチパターン • 頻繁にバージョン管理システムにコミットしない • テストコードを書かない • テストコードと製品コードを同時にコミットしない • 定時ビルドのみでコミットビルドがない・夜間ビルドしかな い • 帰り際にコミットしてそのままCIの結果を見ずに帰る • CIでテストを通すために手作業の準備が必要 • メインラインのみで大きなブランチをCI対象にしていない 13年4月24日水曜日
78. CIアンチパターン • 様々な種類のテストをまとめて行っている • ビルドの失敗に気付かない • ビルドに失敗しても放置している • ビルドの失敗に気づいても、修正コード以外のコードをコ ミットする • 何も変更していないのにビルドが落ちたり落ちなかったり • 頻繁にビルドが失敗するので、失敗するのが普通だと思う • CIからの通知メッセージが大量すぎる 13年4月24日水曜日
79. CIアンチパターン • CIが落ちても何も通知しない • CIサーバのリソースが貧弱 • ビルドが肥大化して結果が出るまでに時間がかかる • 本番環境やステージング環境と大幅に環境が異なる • コードの静的解析をCIで行わずに人手で行う • CIサーバがおかしくなったときに直せる人がいない • ずっとCIでのチェック内容が変わらない、プロセスが変わら ない 13年4月24日水曜日
80. バージョン管理 13年4月24日水曜日
81. ソースコードのバージョン管理 • いわずもがな。全ての起点はここにある • コードの共同所有の原則への理解 • このソースコードは本番環境または開発環境な どで同じように動作しなければならない • テストを書く習慣、コミット前に他のテストも 含めて通してからコミットする習慣 13年4月24日水曜日
82. 設定情報のバージョン管理 • 環境によって異なる設定値（接続先データベース情報 など）が書かれた設定ファイルもバージョン管理する • 開発環境用、ステージング環境用、本番環境用などに 分けて定義し、容易に切り替え可能にする • 本番環境に配置する際に、アプリケーションの各所を 書き換えなければ動作しないとかアマチュア以下 13年4月24日水曜日
83. http://www.flickr.com/photos/seanmolin/7028040701/ 13年4月24日水曜日
84. マージって何？ http://www.flickr.com/photos/seanmolin/7028040701/ 13年4月24日水曜日
85. マージって何？ Excel台帳じゃ だめ？ http://www.flickr.com/photos/seanmolin/7028040701/ 13年4月24日水曜日
86. マージって何？ Excel台帳じゃ だめ？ コンフリクトするとつ らいから動かなくても コミットしますね！ http://www.flickr.com/photos/seanmolin/7028040701/ 13年4月24日水曜日
87. マージって何？ Excel台帳じゃ だめ？ コンフリクトするとつ らいから動かなくても コミットしますね！ http://www.flickr.com/photos/seanmolin/7028040701/ 13年4月24日水曜日
88. マージって何？ Excel台帳じゃ だめ？ コンフリクトするとつ らいから動かなくても コミットしますね！ http://www.flickr.com/photos/seanmolin/7028040701/ 13年4月24日水曜日
89. バージョン管理は 開発者のしつけ http://bit.ly/utD8aA 13年4月24日水曜日
90. どの断面でも再現可能か？ http://www.flickr.com/photos/55310085@N06/8436234163/ 13年4月24日水曜日
91. リリースした際に、前のバージョンに即座に戻 せるか？これはコードだけでなくデータベース 等も含む http://bit.ly/tgbmyr 13年4月24日水曜日
92. マイグレーション 13年4月24日水曜日
93. データベーススキーマの管理 これ試すのにどのSQL適 用すればいいの？ このバージョンはス キーマ違うの？？？ データベースのスキーマの状態とリリースの状態を関連 付けることによって再現可能にする 13年4月24日水曜日
94. 既存のアプローチの問題 • SQLスクリプトファイルは管理が煩雑 • SQLスクリプトは自動実行に向かない • ロールバックやデータ移行の考慮もしづらい • 複数のSQLスクリプトの実行順序が分からない http://bit.ly/vbtqZc 13年4月24日水曜日
95. 問題の例 • SQLの実行順序で状態が変わる 1.sql 1.sql→2.sql alter table users add column lastlogin datetime after name; 2.sql alter table users add column disabled boolean default false after name; 13年4月24日水曜日 2.sql→1.sql
96. マイグレーション 13年4月24日水曜日
97. マイグレーション $ 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 13年4月24日水曜日
98. マイグレーション実行(例) # 最新のバージョンへ更新 $ php doctrine_cli.php migrate # 指定したバージョンへ更新 $ php doctrine_cli.php migrate 29 マイグレーションファイルをソースコードとしてバージョ ン管理し、CIのビルド定義の中にマイグレーションコマ ンドを組み込むことで、自動的にDBの状態を連動させる 13年4月24日水曜日
99. 13年4月24日水曜日
100. 環境構築自動化 13年4月24日水曜日
101. 環境構築の自動化が必要なわけ • そもそも時間がかかる • 数が増えれば単純作業の繰り返し • 人手による単純作業はミスを誘発 • ミスした場合でも検知する仕掛けが本番障害しかない • 手順書がメンテナンスされないことがある • 手順書の手順の妥当性の評価が難しい • 手順の逆転により状態が変わりうる 13年4月24日水曜日
102. 設定やインストールの自動化 • いつでもクリーンな動作 環境を作れるようにする http://bit.ly/vMHRjL 13年4月24日水曜日
103. 設定やインストールの自動化 この自動化によっ て後はアプリケー ションをデプロイ すればすぐ動作す る状態にする http://bit.ly/v30Zl7 13年4月24日水曜日
104. 設定やインストールの自動化 http://bit.ly/ttwsmT 本番環境と開発環境の 各種バージョンをあわせる 13年4月24日水曜日
105. 設定やインストールの自動化 • ミドルウェアのバージョンをあげたり、 パッチを適用する場合も、 この自動化機構を使って行う http://bit.ly/tkSfaO 13年4月24日水曜日
106. Chef / Chef Solo 13年4月24日水曜日
107. Chefの概要 • Ruby製のシステム管理ツール • 出来ること • OSのパッケージのインストールや管理 • OSの設定やミドルウェアの設定 • サービスの起動・停止 • クーロンの設定 • 特徴 • Rubyでジョブや設定を記述する • Chef自体はクライアント/サーバモデル • Chef-soloを使えばローカル単体で動作 • Recipeが多数公開されている 13年4月24日水曜日
108. バージョンを指定 してパッケージを インストールする ことも可能 13年4月24日水曜日
109. 多数のRecipeがOSS で公開されている 13年4月24日水曜日
110. 13年4月24日水曜日
111. 仮想化と自動化(Vagrant) 13年4月24日水曜日
112. VagrantでSandbox Sandbox機能を使うことで、ミドルウェアのバージョンアッ プの検証・構成の変更の検証・デプロイの試験などを気軽に行 えるようになる（何度でも変更をRollbackできる） $ sudo git clone https://github.com/ryuzee/sahara.git $ cd sahara $ sudo rake build $ cd pkg $ sudo gem install ./sahara-0.0.14.gem Vagrant 1.1系用にforkしたバージョン用意しました!! 13年4月24日水曜日
113. クラウドの利用 • Stampパターンで自由にインスタンスを複製可能 13年4月24日水曜日
114. 環境構築自動化の敷居の低下 • 仮想マシンを使うことで、何度でも簡単に自動化の試験をお こなうことが可能 • 環境構築でTDDを行う例も登場 • 不要になったインスタンスは削除すれば良く、調達コストは 極めて低い • 一方で有償ソフトウェアのライセンス管理をどうするかは課 題の１つ http://www.flickr.com/photos/stuckincustoms/393494014/ 13年4月24日水曜日
115. デプロイ自動化 13年4月24日水曜日
116. Developers Summit 当たり前の話 ( ﾟ皿ﾟ)ｷｰｯ!! Day1 13年4月24日水曜日 Day2 Day3 Day4 DayN
117. Developers Summit 当たり前の話 (^_^;) ( ﾟ皿ﾟ)ｷｰｯ!! 13年4月24日水曜日
118. ゼロデプロイ プロジェクト最初に、 (デプロイするものがなくても) デプロイを自動化する http://bit.ly/vd1Nin 13年4月24日水曜日
119. プロジェクトのあいだ、 ずっとデプロイスクリプトを 使うことで、 プロセスがテストされ続ける 開発環境・本番環境問わず、 同じ方法でデプロイする http://bit.ly/u27Oiz 13年4月24日水曜日
120. デプロイが失敗した場合に ロールバックできるように する http://bit.ly/vFzaU9 13年4月24日水曜日
121. デプロイが途中で失敗 した場合、その先を手 動でやらない http://bit.ly/w34bFM 13年4月24日水曜日
122. Capistrano Railsアプリのデプロイに利用されることが多いが、もちろん それ以外にも利用可能。SSHで接続し、サーバに対して色々 な操作を行うことが出来る。 13年4月24日水曜日
123. 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. 13年4月24日水曜日
124. 13年4月24日水曜日
125. Webistrano 13年4月24日水曜日
126. Fabric 13年4月24日水曜日
127. よくあるデプロイ方法 メンテ中ページに 差し替える LBから切り離す 新規環境構築 データベースの マイグレーション アプリケーションの デプロイ アプリケーションの デプロイ アプリケーションの デプロイ スモークテスト スモークテスト スモークテスト LB対象に戻す LB切り替え メンテ中ページから 戻す 13年4月24日水曜日 アプリケーションの デプロイ データベースの不可逆な変更を避けるよ うにアプリケーションを作りこんだ方が 良い場合が多い
128. ビルドパイプライン 各種テストや静的解析、ステージング環境 リリース、本番環境リリースなどを 一元的に管理できる。 13年4月24日水曜日
129. Action 13年4月24日水曜日
130. 通常時のリリース http://bit.ly/wo4eyD 13年4月24日水曜日
131. 通常時のリリース • テストが完了してから リリースまで1日以内？ http://bit.ly/wo4eyD 13年4月24日水曜日
132. 通常時のリリース • テストが完了してから リリースまで1日以内？ • テストが完了してから リリースまで3日以内？ http://bit.ly/wo4eyD 13年4月24日水曜日
133. 通常時のリリース • テストが完了してから リリースまで1日以内？ • テストが完了してから リリースまで3日以内？ • テストが完了してから リリースまで1週間以内？ http://bit.ly/wo4eyD 13年4月24日水曜日
134. 通常時のリリース • テストが完了してから リリースまで1日以内？ • テストが完了してから リリースまで3日以内？ • テストが完了してから リリースまで1週間以内？ • それ以上かかる？ http://bit.ly/wo4eyD 13年4月24日水曜日
135. 障害発生時のリリース http://bit.ly/zeFv2G 13年4月24日水曜日
136. 障害発生時のリリース • テストが完了してからリリースまで1日以内？ http://bit.ly/zeFv2G 13年4月24日水曜日
137. 障害発生時のリリース • テストが完了してからリリースまで1日以内？ • テストが完了してからリリースまで3日以内？ http://bit.ly/zeFv2G 13年4月24日水曜日
138. 障害発生時のリリース • テストが完了してからリリースまで1日以内？ • テストが完了してからリリースまで3日以内？ • テストが完了してからリリースまで1週間以内？ http://bit.ly/zeFv2G 13年4月24日水曜日
139. 障害発生時のリリース • テストが完了してからリリースまで1日以内？ • テストが完了してからリリースまで3日以内？ • テストが完了してからリリースまで1週間以内？ • それ以上かかる？ http://bit.ly/zeFv2G 13年4月24日水曜日
140. 障害時に1日でリリースできるのであれば、 今のリリースプロセスには組織的なムダがある。 ワンクリックでデプロイできたとしても リリースの意思決定に時間がかかったら 無意味！ http://bit.ly/rZyM3H 13年4月24日水曜日
141. Developers Summit 組織のアジリティを高める • 変化しないとゆるやかに死ぬ • 自分たちで変えていく。できることは沢山あるはず！ http://www.flickr.com/photos/eole/4350200158/ 13年4月24日水曜日
142. まとめ • ビジネスのために継続的に成果を届ける • そのためにはAgileなやり方が必要 • テストの自動化は必須 • 常に出荷可能な状態に保つ • デプロイや環境構築も自動化 • 改善をずっと続ける 13年4月24日水曜日
No comments...
Yoshiba Ryutaro
Attractor Inc. Founder / CTO / Agile Coach / Certified Team Coach / Certified Scrum Professional / Certified ScrumMaster / Certified Scrum Product Owner Twitter : @ryuzee Web : https://www.attractor.co.jp/ Web : http://www.ryuzee.com/

Related Slides