Upload
ryuzee-yoshiba
View
28.971
Download
0
Embed Size (px)
DESCRIPTION
2013/2/15に目黒雅叙園で行われたデブサミ2013 15-A-7セッションの資料です。
Citation preview
ワンクリックデプロイ~いつまで手でデプロイしてるんですか?~
http://www.flickr.com/photos/nimasadigh/4921186134/
SummitDevelopers 15-A-7 #devsumiA
Ryuzee.com 吉羽龍太郎13年2月15日金曜日
吉羽 龍太郎
アジャイルコーチRyuzee.comTwitter: @ryuzee
Ryutaro YOSHIBA
13年2月15日金曜日
好評発売中!定価:2520円
http://www.seshop.com/product/detail/15395/
#scrumbcbook13年2月15日金曜日
はじめに
13年2月15日金曜日
本当に必要なものがわかるか?
13年2月15日金曜日
13年2月15日金曜日
期待のマネジメントに失敗
13年2月15日金曜日
システムの機能の利用割合
7%
13%
16%
19%
45%
Standishの2000年の調査より13年2月15日金曜日
システムの機能の利用割合
7%
13%
16%
19%
45%
まったく使わないほとんど使わないたまに使うよく使ういつも使う
Standishの2000年の調査より13年2月15日金曜日
あなたの開発はムダだらけ?
•作りすぎのムダ•手待ちのムダ•運搬のムダ•加工のムダ•在庫のムダ•動作のムダ•不良をつくるムダ
13年2月15日金曜日
コストの見積りは正しいか?
•不確実性コーン13年2月15日金曜日
ウォーターフォール(V字)
要件定義 受け入れ試験
基本設計 総合試験
詳細設計 結合試験
製造・単体
13年2月15日金曜日
ウォーターフォール(V字)
要件定義 受け入れ試験
基本設計 総合試験
詳細設計 結合試験
製造・単体
時間がかかりすぎ
て、出来た頃には
要
求が変化。そもそ
も
要件があっていな
い
ことがここで分か
る
13年2月15日金曜日
よくみかける光景要件定義は順調です
○○設計は順調です
開発は遅れていますが挽回可能です
結合試験で重大な問題が出ています
受入れ試験でニーズ不一致が判明
リリースできません。てへっ13年2月15日金曜日
よくみかける光景要件定義は順調です
○○設計は順調です
開発は遅れていますが挽回可能です
結合試験で重大な問題が出ています
受入れ試験でニーズ不一致が判明
リリースできません。てへっ
多くのリスクが後半になって顕在化する。顕在化した時点では取り
返しがつかない
13年2月15日金曜日
アジャイルマニフェスト
• 2001年に、ケント・ベック、マーティン・ファウラー、ケン・シュウェイバーら、17人によって採択されたAgileソフトウェア開発の原則を指す。
13年2月15日金曜日
アジャイルマニフェスト
• プロセスやツールより人と人同士の相互作用を重視する
• 包括的なドキュメントより動作するソフトウェアを重視する
• 契約上の交渉よりも顧客との協調を重視する
• 計画に従うことよりも変化に対応することを重視する
13年2月15日金曜日
アジャイルマニフェスト
• プロセスやツールより人と人同士の相互作用を重視する
• 包括的なドキュメントより動作するソフトウェアを重視する
• 契約上の交渉よりも顧客との協調を重視する
• 計画に従うことよりも変化に対応することを重視する顧客満足を最優先し、価値のあるソフトウェアを早く継続的に提供します。
13年2月15日金曜日
マーケットに製品を早期に投入して投資を回収し
利益に結びつける必要性がある
13年2月15日金曜日
SummitDevelopers
• MVPとフィードバックループ
• ビジネスの成長とプロダクトの成長を同期させる
http://www.flickr.com/photos/pagedooley/2120528888/
13年2月15日金曜日
SummitDevelopers
平鍋健児氏の資料を許可を得て引用 http://blogs.itmedia.co.jp/hiranabe/2012/09/rightwing-and-leftwing-of-agile.html
アジャイルの範囲
今日の話はこちら側
13年2月15日金曜日
毎日何回も本番環境にデプロイできているか?
顧客に頻繁に価値を届けられているか?
13年2月15日金曜日
SummitDevelopers
http://bit.ly/XonkX7
1000+ deploys / hour
13年2月15日金曜日
SummitDevelopers よくある光景
てめーもっとちゃんとアプリ作れ
運用でなんとかすんのがあんたらの仕事だろ
http://www.flickr.com/photos/makitani/3940687822/
あの~、ビジネスのこと考えてよ
13年2月15日金曜日
SummitDevelopers 会場調査
•ユニットテストを書いている方は挙手
•継続的インテグレーションサーバを使っている方はそのまま挙手
•結合テストを自動化している方はそのまま挙手
•デプロイを自動化している方はそのまま挙手
•環境構築を自動化している方はそのまま挙手
13年2月15日金曜日
SummitDevelopers 会場調査
•ユニットテストを書いている方は挙手
•継続的インテグレーションサーバを使っている方はそのまま挙手
•結合テストを自動化している方はそのまま挙手
•デプロイを自動化している方はそのまま挙手
•環境構築を自動化している方はそのまま挙手
最後まで残っていた方は帰って大丈夫です!
13年2月15日金曜日
http://bit.ly/sygcE9自分たちのプロセスは自分たちで進化させるしかない
13年2月15日金曜日
SummitDevelopers
製品そのものをAgileな状態に保つ
技術的負債を少なく保つ
http://www.flickr.com/photos/stuckincustoms/5094583941/
13年2月15日金曜日
継続的デリバリー
13年2月15日金曜日
SummitDevelopers
13年2月15日金曜日
継続的デリバリーの原則
ソフトウェアのリリースやデプロイのプロセスは繰り返し可能であり信頼性が高い必要がある。
113年2月15日金曜日
継続的デリバリーの原則
全てを自動化する213年2月15日金曜日
継続的デリバリーの原則
難解なことや苦痛なことを繰り返し行い自動化の方法を考える
313年2月15日金曜日
継続的デリバリーの原則
全てをソースコード管理システムで管理する4
13年2月15日金曜日
継続的デリバリーの原則
完了は「リリースされたこと」を意味する5
13年2月15日金曜日
継続的デリバリーの原則
品質を作りこむ613年2月15日金曜日
継続的デリバリーの原則
すべての人にリリースプロセスに対しての責任がある7
13年2月15日金曜日
継続的デリバリーの原則
継続的に改善する813年2月15日金曜日
継続的デリバリーの4プラクティス
•バイナリは一度だけビルドする•すべての環境にデプロイするのに完全に同一のメカニズムを使う
•デプロイメントでスモークテストを実施する•何か問題が起こったらラインを止める
13年2月15日金曜日
テスト自動化
13年2月15日金曜日
テスト自動化の必要性
• アジャイル開発においてはテスト自動化は必須
• アジャイルかどうかに関係なくソフトウェアのライフサイクルを考慮する必要がある。
小規模リリースのたびに手動でテストするとコードベースが大きくなるに
つれてテストコストが膨らむ
13年2月15日金曜日
自動化されたテストの損益分岐点
ITアーキテクト「機能テストの自動化について考える」 より引用
http://www.itarchitect.jp/print/?menu3=24601
13年2月15日金曜日
自動化されたテストの損益分岐点
ITアーキテクト「機能テストの自動化について考える」 より引用
http://www.itarchitect.jp/print/?menu3=24601
テスト自動化にかかるコストよりも手動テストのコストがすぐ高くなる
13年2月15日金曜日
問題は早めに解決する
•早く見つけて速く直す
フェーズ 修正までの時間
要求や設計 5分
コードやユニットテスト 15分
結合テストやシステムテスト 1時間
ベータテスト 2時間
リリース後 1日
13年2月15日金曜日
デプロイのたびに人手でテストするのは無理
13年2月15日金曜日
http://bit.ly/rAOG9h
テストしていないものを目を瞑ってデプロイしてはい
けない
設定ファイル1行だし大丈夫だよね?
悪魔の囁き
13年2月15日金曜日
アジャイルテストの4象限
�������'(������� ������#����� ��"� �$�
�������+.%���� � �������� ����������������!��,����,�
������*&�����$���$�����
� ���������$�����)-������ ������
�����
����� �����
�����
�����������
���������������
��
�����
�����
13年2月15日金曜日
SummitDevelopers自動テストに求められる特性
•繰り返し可能 (Repeatable)•独立性 (Independent)•自己検証 (Self validation)•簡単実行 (Easy)
http://www.flickr.com/photos/spackletoe/90811910/
13年2月15日金曜日
SummitDevelopersWebアプリケーションだと...
• テストの実行時間を短く、依存関係を少なく
• 自信のない箇所をテスト
• 問題は実装箇所に近いところで見つける
• モデル、ヘルパー、コンポーネント単位でのテストを書く
• コントローラーのテストを沢山書かざるを得ないのは、Fat Controllerや密結合の証
• そうなる前にペアプロ、コードレビュー、TDD、リファクタリング
13年2月15日金曜日
完了の定義
•完了の定義を作り、何をもって出荷可能かを定める
•全部を短い間隔で出来れば頻繁にリリース可能コードレビュー
チェックイン ユニットテスト
カバレッジ75%
ドキュメント 性能 セキュリティ デプロイ
結合テスト 受け入れテスト
クロスブラウザ
静的解析
13年2月15日金曜日
フィーチャー単位で完了
コードレビュー
チェックイン
ユニットテスト
カバレッジ
ドキュメント
性能
セキュリティ
デプロイ
結合テスト
受け入れテスト
クロスブラウザ
静的解析
フィーチャー
コードレビュー
チェックイン
ユニットテスト
カバレッジ
ドキュメント
性能
セキュリティ
デプロイ
結合テスト
受け入れテスト
クロスブラウザ
静的解析
フィーチャー
コードレビュー
チェックイン
ユニットテスト
カバレッジ
ドキュメント
性能
セキュリティ
デプロイ
結合テスト
受け入れテスト
クロスブラウザ
静的解析
フィーチャー
コードレビュー
チェックイン
ユニットテスト
カバレッジ
ドキュメント
性能
セキュリティ
デプロイ
結合テスト
受け入れテスト
クロスブラウザ
静的解析
フィーチャー
コードレビュー
チェックイン
ユニットテスト
カバレッジ
ドキュメント
性能
セキュリティ
デプロイ
結合テスト
受け入れテスト
クロスブラウザ
静的解析
フィーチャー
コードレビュー
チェックイン
ユニットテスト
カバレッジ
ドキュメント
性能
セキュリティ
デプロイ
結合テスト
受け入れテスト
クロスブラウザ
静的解析
フィーチャー
コードレビュー
チェックイン
ユニットテスト
カバレッジ
ドキュメント
性能
セキュリティ
デプロイ
結合テスト
受け入れテスト
クロスブラウザ
静的解析
フィーチャー
13年2月15日金曜日
XPのプラクティスの利用� �
?7;/F�
���$�
,-'&-�
869%�#��
=0<D�
B;/27BE3�
4F:+!�����
���1E83CF5@E�
YAGNI�
"��
�!�
����+!��)�
>AF�
���*!=F6�
69FBF���
BBF6 ��
(�.869�
��BBF6�
13年2月15日金曜日
13年2月15日金曜日
継続的インテグレーション
13年2月15日金曜日
CIサーバ
• プロジェクト初期の段階でコードがなくても構築する
• コードのメトリクス取得や静的解析は初期から継続的に実施する方が効果がある
• 常にグリーン(Jenkinsなら青)の状態を保ち、エラーがある状態に慣れない
• 常にグリーンに保つにはアトミックな単位での作業、マイグレーションとの連携、チームのコミットに対する態度が欠かせない
13年2月15日金曜日
CIアンチパターン
• 頻繁にバージョン管理システムにコミットしない
• テストコードを書かない
• テストコードと製品コードを同時にコミットしない
• 定時ビルドのみでコミットビルドがない・夜間ビルドしかない
• 帰り際にコミットしてそのままCIの結果を見ずに帰る
• CIでテストを通すために手作業の準備が必要
• メインラインのみで大きなブランチをCI対象にしていない
13年2月15日金曜日
CIアンチパターン
• 様々な種類のテストをまとめて行っている
• ビルドの失敗に気付かない
• ビルドに失敗しても放置している
• ビルドの失敗に気づいても、修正コード以外のコードをコミットする
• 何も変更していないのにビルドが落ちたり落ちなかったり
• 頻繁にビルドが失敗するので、失敗するのが普通だと思う
• CIからの通知メッセージが大量すぎる
13年2月15日金曜日
CIアンチパターン
• CIが落ちても何も通知しない
• CIサーバのリソースが貧弱
• ビルドが肥大化して結果が出るまでに時間がかかる
• 本番環境やステージング環境と大幅に環境が異なる
• コードの静的解析をCIで行わずに人手で行う
• CIサーバがおかしくなったときに直せる人がいない
• ずっとCIでのチェック内容が変わらない、プロセスが変わらない
13年2月15日金曜日
バージョン管理
13年2月15日金曜日
ソースコードのバージョン管理
•いわずもがな。全ての起点はここにある•コードの共同所有の原則への理解•このソースコードは本番環境または開発環境などで同じように動作しなければならない
•テストを書く習慣、コミット前に他のテストも含めて通してからコミットする習慣
13年2月15日金曜日
設定情報のバージョン管理
•環境によって異なる設定値(接続先データベース情報など)が書かれた設定ファイルもバージョン管理する
•開発環境用、ステージング環境用、本番環境用などに分けて定義し、容易に切り替え可能にする
•本番環境に配置する際に、アプリケーションの各所を書き換えなければ動作しないとかアマチュア以下
13年2月15日金曜日
http://www.flickr.com/photos/seanmolin/7028040701/
マージって何?
Excel台帳じゃだめ?
コンフリクトするとつらいから動かなくてもコミットしますね!
13年2月15日金曜日
どの断面でも再現可能か?
http://www.flickr.com/photos/55310085@N06/8436234163/
13年2月15日金曜日
リリースした際に、前のバージョンに即座に戻せるか?これはコードだけでなくデータベース等も含む
http://bit.ly/tgbmyr
13年2月15日金曜日
マイグレーション
13年2月15日金曜日
データベースのスキーマの状態とリリースの状態を関連付けることによって再現可能にする
データベーススキーマの管理
これ試すのにどのSQL適用すればいいの?
このバージョンはスキーマ違うの???
13年2月15日金曜日
既存のアプローチの問題
• SQLスクリプトファイルは管理が煩雑• SQLスクリプトは自動実行に向かない•ロールバックやデータ移行の考慮もしづらい•複数のSQLスクリプトの実行順序が分からない
http://bit.ly/vbtqZc
13年2月15日金曜日
問題の例•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.sql→2.sql
2.sql→1.sql
13年2月15日金曜日
マイグレーション
13年2月15日金曜日
マイグレーション$ ls -11301223401_addchangelogs.php1313445291_addinformation.php1317489252_addpriorities.php1318776293_addprojects.php1318889397_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
前後関係は、ファイル先頭の数字の大小で判断される。
(規約)
13年2月15日金曜日
マイグレーション実行(例)# 最新のバージョンへ更新$ php doctrine_cli.php migrate# 指定したバージョンへ更新$ php doctrine_cli.php migrate 29
マイグレーションファイルをソースコードとしてバージョン管理し、CIのビルド定義の中にマイグレーションコマンドを組み込むことで、自動的にDBの状態を連動させる
13年2月15日金曜日
13年2月15日金曜日
環境構築自動化
13年2月15日金曜日
環境構築の自動化が必要なわけ
• そもそも時間がかかる
• 数が増えれば単純作業の繰り返し
• 人手による単純作業はミスを誘発
• ミスした場合でも検知する仕掛けが本番障害しかない
• 手順書がメンテナンスされないことがある
• 手順書の手順の妥当性の評価が難しい
• 手順の逆転により状態が変わりうる
13年2月15日金曜日
設定やインストールの自動化
•いつでもクリーンな動作環境を作れるようにする
http://bit.ly/vMHRjL
13年2月15日金曜日
設定やインストールの自動化
この自動化によって後はアプリケーションをデプロイすればすぐ動作する状態にする
http://bit.ly/v30Zl7
13年2月15日金曜日
設定やインストールの自動化
本番環境と開発環境の各種バージョンをあわせる
http://bit.ly/ttwsmT
13年2月15日金曜日
設定やインストールの自動化
•ミドルウェアのバージョンをあげたり、パッチを適用する場合も、この自動化機構を使って行う
http://bit.ly/tkSfaO
13年2月15日金曜日
Chef / Chef Solo
13年2月15日金曜日
Chefの概要• Ruby製のシステム管理ツール
• 出来ること
• OSのパッケージのインストールや管理
• OSの設定やミドルウェアの設定
• サービスの起動・停止
• クーロンの設定
• 特徴
• Rubyでジョブや設定を記述する
• Chef自体はクライアント/サーバモデル
• Chef-soloを使えばローカル単体で動作
• Recipeが多数公開されている13年2月15日金曜日
バージョンを指定してパッケージをインストールすることも可能
13年2月15日金曜日
多数のRecipeがOSSで公開されている
13年2月15日金曜日
13年2月15日金曜日
仮想化と自動化(Vagrant)
13年2月15日金曜日
VagrantでSandbox
Sandbox機能を使うことで、ミドルウェアのバージョンアップの検証・構成の変更の検証・デプロイの試験などを気軽に行えるようになる(何度でも変更をRollbackできる)
$ sudo git clone https://github.com/jedi4ever/sahara.git$ cd sahara$ sudo rake build$ cd pkg$ sudo gem install ./sahara-0.0.13.gem
13年2月15日金曜日
クラウドの利用
• Stampパターンで自由にインスタンスを複製可能
13年2月15日金曜日
環境構築自動化の敷居の低下
• 仮想マシンを使うことで、何度でも簡単に自動化の試験をおこなうことが可能
• 環境構築でTDDを行う例も登場
• 不要になったインスタンスは削除すれば良く、調達コストは極めて低い
• 一方で有償ソフトウェアのライセンス管理をどうするかは課題の1つ
http://www.flickr.com/photos/stuckincustoms/393494014/
13年2月15日金曜日
デプロイ自動化
13年2月15日金曜日
SummitDevelopers 当たり前の話
( ゚皿゚)キーッ!!
Day1 Day2 Day3 Day4 DayN
13年2月15日金曜日
SummitDevelopers 当たり前の話
(^_^;)
( ゚皿゚)キーッ!!
13年2月15日金曜日
ゼロデプロイ
プロジェクト最初に、(デプロイするものがなくても)デプロイを自動化する
http://bit.ly/vd1Nin
13年2月15日金曜日
プロジェクトのあいだ、ずっとデプロイスクリプトを使うことで、プロセスがテストされ続ける
開発環境・本番環境問わず、同じ方法でデプロイする
http://bit.ly/u27Oiz
13年2月15日金曜日
デプロイが失敗した場合にロールバックできるようにする
http://bit.ly/vFzaU9
13年2月15日金曜日
デプロイが途中で失敗した場合、その先を手動でやらない
http://bit.ly/w34bFM
13年2月15日金曜日
Capistrano
Railsアプリのデプロイに利用されることが多いが、もちろんそれ以外にも利用可能。SSHで接続し、サーバに対して色々な操作を行うことが出来る。
13年2月15日金曜日
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年2月15日金曜日
13年2月15日金曜日
Webistrano
13年2月15日金曜日
Fabric
13年2月15日金曜日
よくあるデプロイ方法LBから切り離す
アプリケーションのデプロイ
スモークテスト
LB対象に戻す
アプリケーションのデプロイ
メンテ中ページに差し替える
アプリケーションのデプロイ
データベースのマイグレーション
スモークテスト
メンテ中ページから戻す
新規環境構築
アプリケーションのデプロイ
スモークテスト
LB切り替え
データベースの不可逆な変更を避けるようにアプリケーションを作りこんだ方が
良い場合が多い
13年2月15日金曜日
ビルドパイプライン
各種テストや静的解析、ステージング環境リリース、本番環境リリースなどを
一元的に管理できる。
13年2月15日金曜日
Action
13年2月15日金曜日
通常時のリリース
•テストが完了してからリリースまで1日以内?
•テストが完了してからリリースまで3日以内?
•テストが完了してからリリースまで1週間以内?
•それ以上かかる?http://bit.ly/wo4eyD
13年2月15日金曜日
障害発生時のリリース
•テストが完了してからリリースまで1日以内?•テストが完了してからリリースまで3日以内?•テストが完了してからリリースまで1週間以内?•それ以上かかる?
http://bit.ly/zeFv2G
13年2月15日金曜日
http://bit.ly/rZyM3H
障害時に1日でリリースできるのであれば、今のリリースプロセスには組織的なムダがある。
ワンクリックでデプロイできたとしてもリリースの意思決定に時間がかかったら
無意味!
13年2月15日金曜日
SummitDevelopers組織のアジリティを高める
• 変化しないとゆるやかに死ぬ
• 自分たちで変えていく。できることは沢山あるはず!
http://www.flickr.com/photos/eole/4350200158/
13年2月15日金曜日
まとめ
•ビジネスのために継続的に成果を届ける•そのためにはAgileなやり方が必要•テストの自動化は必須•常に出荷可能な状態に保つ•デプロイや環境構築も自動化•改善をずっと続ける
13年2月15日金曜日