ワンクリックデプロ 101

http://bit.ly/vHXFbO

吉羽龍太郎

ゕジャルコーチ http://www.ryuzee.com/

Special Thanks

@katzchang 凄腕プログラマー

@tomohn 凄腕エバンジェリスト

え？マジでマジで？

会場調査

• 全員起立してください

• ユニットテストを書いていない方は着席

• 結合テストを自動化していない方は着席

• 継続的インテグレーションサーバを使っていない方は着席

• デプロイを自動化していない方は着席

• 環境構築を自動化していない方は着席

最後まで起立されている方は帰って大丈夫ですｗ

http://bit.ly/vPmiFJ

一日にしてならず

http://bit.ly/vj0b0v

No Silver Bullet

http://bit.ly/sygcE9

自分たちのプロセスは自分たちで進化させるしかない！

１．ビジネスをとりまく 環境の変化

IT投資は業務効率化

から戦略実現へ

以前の競争

http://bit.ly/rioQDZ

現在の競争

競争の速度の変化

迅速な 意思決定が必要

http://bit.ly/pccwAN

意思決定をもとに素早く 具現化する必要

http://bit.ly/r1ziWL

ビジネスモデルの賞味期限が短縮

変化への対応

“事前に綿密”

にたてた計画を

“長期間遵守”

して大丈夫なのか？

変化への対応

“変化が起こる”

ことを前提に

“頻繁に軌道修正” することが必要

http://bit.ly/oX9ImQ

変化に対応できなければマーケットから 見捨てられる

価値がなくなれば滅びる

http://bit.ly/qJg8EX

継続的な イノベーション の創発

http://bit.ly/nLACes

“イノベーションは「知」の創造プロセスであり、知の創造は単に理論だけではなく、実践を通して知識を磨き、知恵にするものである”

“企業の優れた業績は研究開発投資の増加に要因があるのではなく、組織の イノベーション・プロセスの質による”

野中郁次郎氏の発言要旨

http://www.slideshare.net/InnovationSprint2011/2011-6794551

プロセス イノベーション

http://bit.ly/qpjFXr

プロダクト イノベーション

http://bit.ly/ornfUo

マインド イノベーション

http://bit.ly/nrDcZf

コンウェの法則

“Organizations which design systems are constrained to produce designs which are copies of the communication structures of these organizations.”

http://bit.ly/oIUrUI

２．継続的デリバリ

毎日何回も本番環境にデプロイできているか？ 顧客に頻繁に価値を届けられているか？

ワンクリックでデプロイできたとしても、リリースの意思決定に時間がかかったら無意味！

http://bit.ly/rZyM3H

XP 技術面を高める

Scrum 価値あるものから継続的に

製品を届ける

Lean 企業活動自体の全体最適化

チーム

マネージャ

経営者

繰り返し型の 開発

継続的 ンテグレーション

継続的 デプロ

継続的デリバリ

企業での価値創造

Strategic Impact

Adapta

bility /

Agility

継続的デリバリとは何か？

“継続的デリバリとはリリースのスケジュールをIT部門が握るのではなく、ビジネス部門が握るということだ。継続的デリバリを実装するということは、全体のライフサイクルを通じて常にソフトウェアが本番環境にリリース可能であるということを意味する。すなわちどのビルドもボタン一発で、完全に自動化されたリリースプロセスを通じて、秒とか分の時間で利用者

にリリース可能である、ということだ。”

Jez Humble

http://bit.ly/tFrqbz

継続的デリバリ

ユーザーとプロジェクトチームの間に

固いフィードバックループを作る

継続的デリバリ

継続的なフィードバックプロセスは、 競争優位性やムダの削減につながる

http://bit.ly/uLQaml

継続的デリバリの8原則

ソフトウェアのリリースやデプロイのプロセスは繰り返し可能であり信頼性が高い必要がある。

継続的デリバリの8原則

全てを自動化する

継続的デリバリの8原則

難解なことや苦痛なことを繰り返し行い自動化の方法を考える

継続的デリバリの8原則

全てをソースコード管理システムで管理する

継続的デリバリの8原則

完了は「リリースされたこと」を意味する

継続的デリバリの8原則

品質を作りこむ

継続的デリバリの8原則

すべての人にリリースプロセスに対しての責任がある

継続的デリバリの8原則

継続的に改善する

継続的デリバリの4プラクテゖス

バイナリは一度だけビルドする

すべての環境にデプロイするのに完全に同一のメカニズムを使う

デプロイメントでスモークテストを実施する

何か問題が起こったらラインを止める

どの断面でも

再現可能か？

http://bit.ly/uVQu5I

リリースした際に、前のバージョンに即座に戻せるか？これはコードだけでなくデータベース等も含む

http://bit.ly/tgbmyr

Convention

Over

Configuration

Scrumとの関連性

• 多くの大規模組織は、ソフトウェアのデプロイメントメソッドが貧弱であり、それ故にソフトウェアを世に送り出すことが困難な状況にある。

• Scrumは妨害事項リスト等を使うことで、妨害事項を明らかはできるが、Scrum自体ではそれを解決できず、Scrumそれ自体はどのようにそれを解決するかの指針も持ち合わせていない

Doneの定義

何ができたら

完了なのかを

決める

Doneの定義

• チームとして定めた「出荷可能な製品」を作成 するために実施しなければいけないことの一覧。

• 例えば、コードを書く、ユニットテストする、 統合テストをする、リリースノートを書く

• ストーリーでのDoneの定義、スプリント単位 でのDoneの定義、リリース単位でのDoneの 定義をすることを推奨。

• Doneの定義はチームの成熟度や時間に よって変わっていくが、Doneの定義 なくしてのScrumはあり得ない。

３．バージョン管理

ソースコードのバージョン管理

• いわずもがな。全ての起点はここにある

• コードの共同所有の原則への理解

• このソースコードは本番環境または開発環境などで同じように動作しなければならない

• テストを書く習慣、コミット前に他のテストも含めて通してからコミットする習慣

設定フゔルのバージョン管理

• 環境によって異なる設定値（接続先データベース情報など）が書かれた設定ファイルもバージョン管理する

• 開発環境用、ステージング環境用、本番環境用などに分けて定義し、容易に切り替え可能にする

• 本番環境に配置する際に、アプリケーションの各所を書き換えなければ動作しないという状況は避ける

バージョン管理は

開発者のしつけ

http://bit.ly/utD8aA

４．テスト自動化

テストしていない

ものを目を瞑って

デプロイしてはい

けない

http://bit.ly/rAOG9h

清水の舞台から

飛び降りない

http://bit.ly/tnB8i0

デプロイするたびに人手で全体をテストするのは無理

http://bit.ly/shZMnK

ITアーキテクト「機能テストの自動化について考える」 より引用 http://www.itarchitect.jp/print/?menu3=24601

テスト自動化の損益分岐点は相当早期にある感覚

ゕジャルでの品質の作りこみScrumの場合

Cancel Gift wrap

Return

スプリント 2~4週間

返品

スプリントゴール

スプリントバックログ

出荷可能な製品の

積み上げ

プロダクトバックログ

クーポン ギフト包装

クーポン

キャンセル

24時間

単体テスト、結合テスト、受け入れテストがスプリント単位(もしくはリリース単

位)で行われる.

ゕジャルでの品質の作りこみ

スプリント終了時には「テスト」が完了.スプリントレビューで顧客のビジネス要件への適合性も確認できる

http://www.flickr.com/photos/kakutani/2761992149/

ゕジャルでの品質の作りこみ Scrumではフレームワークの定義のみで、テスト自動化については触れられていない.しかしゕジャル開発においてはテスト自動化は必須

小規模リリースのたびに手動でテストするとスプリント後半になるにつれてテストコストが膨らむ

自動化しないとソフトウェア規模に応じて、テスト工数の占める割合が増加していく（＝価値への投資が減少）

【自動と手動】 機能テスト ストーリーテスト プロトタイプ シミュレーション

【手動】※1

探索的テスト シナリオテスト ユーザビリティテスト ユーザー受入テスト アルファ版、ベータ版

【自動化】 単体テスト コンポーネントテスト

【ツール】 パフォーマンステスト 負荷テスト セキュリティテスト

第１象限

第２象限 第３象限

第４象限

技術面（技術的品質）

ビジネス面（ビジネス的品質）

チームを支援

製品を批評

テストの4象限

※1 ATDD等では自動化

第1象限 チームを支援する技術面のテスト テスト駆動開発などアジャイル開発の中心。

第2象限 チームを支援するビジネス面のテスト 顧客の視点からのハイレベルの機能テストなど。

第3象限 製品を批評するビジネス面のテスト ユーザー受入テスト、探索的テストなど。

第4象限 技術面のテストを使った製品の批評 パフォーマンステスト、セキュリティテストなど。

テストの4象限

「アジャイルテスト ―高品質を追求するアジャイルチームにおけるテストの視点―」増田聡氏 http://codezine.jp/devsumi/2010/report/07/ より引用

自動化されたテストの要件 自動化されたテストは以下の条件を満たしている必要がある。

繰り返し可能 (Repeatable) 何回でも繰り返し実行できること。また実行ごとに結果が変わらないこと

独立性 (Independent) 環境や外部のコンポーネントに依存しないこと テストケースの実行順序に依存しないこと

自己検証 (Self validation) テストが成功したか、失敗したかはプログラムが判断する。 （人手で判断しない）

簡単実行 (Easy) テストの準備に大量の時間や人手がかかるようにしない

【自動と手動】 機能テスト ストーリーテスト プロトタイプ シミュレーション

【手動】 探索的テスト シナリオテスト ユーザビリティテスト ユーザー受入テスト アルファ版、ベータ版

【自動化】 単体テスト コンポーネントテスト

【ツール】 パフォーマンステスト 負荷テスト セキュリティテスト

第１象限

第２象限 第３象限

第４象限

技術面（技術的品質）

ビジネス面（ビジネス的品質）

チームを支援

製品を批評

ツール・手法のマッピング(例)

TDD xUnit

PMD, CPD …

Jmeter WebScarab RatProxy

ValGrind …

Selenium Cucumber

Rspec FitNess …

CI推奨

CI推奨 CI必須

一部CI可能

テスト自動化の進め方 プ

ロダ

クト

バッ

クロ

グ

テス

ト自

動化

バッ

クロ

グ

スプリントバックログ

レガシーコードにおいて、製品コードの開発をとめて自動化のみへ投資するのは現実的に難しいので、投資割合をきめて、予めバックログに組み込むことが

望ましい

問題修正にかかる時間

フェーズ 修正までの時間

要求や設計 5分

コードやユニットテスト 15分

結合テストやシステムテスト 1時間

ベータテスト 2時間

リリース後 1日

５．継続的

インテグレーション

http://bit.ly/soiCFy

継続的インテグレーションの導入と利用促進の７ステップ

ビルドサーバを 用意する

http://bit.ly/rVAW90

http://bit.ly/rubXiA

夜間ビルドを 行う

夜間ビルド＋ コミット時の ユニットテスト

http://bit.ly/s3W9aF

メトリクスの取得

http://bit.ly/rYN42H

テストに対する信頼性と依存性の確立

http://bit.ly/rOloeO

http://bit.ly/sP6BvN

自動化された受け入れテスト＋デプロイ自動化

継続的なデプロイ

http://bit.ly/uc3x59

CIサーバの構築

• プロジェクト初期の段階でコードがなくても構築する

• コードのメトリクスや静的解析は初期から継続的に実施する方が効果がある

• 常にグリーン(Jenkinsなら青)の状態を保ち、エラーがある状態に慣れない

• 常にグリーンに保つにはアトミックな単位での作業、マイグレーションとの連携、チームのコミットに対する態度が欠かせない

Jenkinsでの例

CIゕンチパターン

• 頻繁にSCMにコミットしない

• テストコードを書かない

• テストコードと製品コードを同時にコミットしない

• 定時ビルドのみでコミットビルドがない・夜間ビルドしかない

• 帰り際にコミットしてそのままCIの結果を見ずに帰る

• CIでテストを通すために手作業の準備が必要

• メインラインのみで大きなブランチをCI対象にしていない

• 様々な種類のテストをまとめて行っている

• ビルドの失敗に気付かない

• ビルドに失敗しても放置している

CIゕンチパターン

• ビルドの失敗に気づいても、修正コード以外のコードをコミットする

• 何も変更していないのにビルドが落ちたり落ちなかったりする

• 頻繁にビルドが失敗しているので、失敗するのが普通だと思う

• CIからの通知メッセージが大量すぎる

• CIが落ちても何も通知しない

• CIサーバのリソースが貧弱

• ビルドが肥大化して結果が出るまでに時間がかかる

• 本番環境やステージング環境と大幅に環境が異なる

• コードの静的解析をCIで行わずに人手で行う

• CIサーバがおかしくなったときに直せる人がいない

• ずっとCIでのチェック内容が変わらない、プロセスが変わらない

第１象限での自動評価 プロジェクトの特性や要員構成等に応じて決める

テスト件数と結果(単体、結合) PMD警告件数

Checkstyle警告件数 カバレージ

チーム活動の評価 コード行数 コミット時間

ゕクテゖビテゖ

6．マイグレーションの利用

DBスキーマのバージョン管理

データベースのスキーマの状態とリリースの状態を関連付けることによって再現可能にする

既存のゕプローチの問題

sqlスクリプトフゔルは管理が煩雑

sqlスクリプトは自動実行に向かない

ロールバックやデータ移行の考慮もしづらい

複数のsqlスクリプトの実行順序の制御が難しい

http://bit.ly/vbtqZc

問題の例

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の順に実行すると….

マグレーション(PHPの場合)

データベースの変更管理

$ 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

前後関係は、フゔル先頭の数字の大小で判

断される。 （規約）

マグレーションの状態

mysql> mysql> mysql> mysql> mysql> select * from migration_version; +---------+ | version | +---------+ | 30 | +---------+ 1 row in set (0.08 sec) mysql> mysql>

現在30個目のマグレーションフゔルまで登録済であることを指す

マグレーション実行

# 最新のバージョンへ更新

$ php doctrine_cli.php migrate

# 指定したバージョンへ更新

$ php doctrine_cli.php migrate 29

コマンド１つで最新のバージョンに更新したり、 特定のバージョンに戻すことができる

マグレーションフゔルをソースコードとしてバージョン管理し、CIのビルド定義の中にマグレーションコマンドを組み込むことで、自動的にDBの状態を連動させる

オープンソースのマイグレーションツールは色々ある！

７．環境構築自動化

なぜ環境構築の自動化が必要？

そもそも時間がかかる

数が増えれば単純作業の繰り返し

人手による単純作業はミスを誘発

ミスした場合でも検知する仕掛けが本番障害しかない

手順書がメンテナンスされないことがある

手順書の手順の妥当性の評価が難しい

手順の逆転により状態が変わりうる

ミドルや設定ンストールの自動化

いつでも

クリーンな

動作環境を作れるようにする

http://bit.ly/vMHRjL

ミドルや設定ンストールの自動化

この自動化によって後はアプリケーションをデプロイすればすぐ動作する状態にする

http://bit.ly/v30Zl7

ミドルや設定ンストールの自動化

本番環境と開発環境の各種バージョンをあわせる

http://bit.ly/ttwsmT

ミドルや設定ンストールの自動化

ミドルウェアのバージョンをあげる場合も、この自動化機構を使って行う

http://bit.ly/tkSfaO

仮想化と自動化（Vagrant）

Vagrantのンストールと起動

$ sudo gem install vagrant $ sudo vagrant box add lucid32 http://files.vagrantup.com/lucid32.box $ sudo vagrant init $ sudo vagrant up

わずか４ステップで、仮想インスタンスが起動する!!

Vagrantフゔルでの設定

Vagrantファイルで、ベースボックス名やVirtualBoxのGUI表示の有無、インスタンス名、メモリ容量、自動実行するChefのRecipeなどを指定できる

Vagrantのプラグンでの拡張

SaharaによるSandbox機能の導入

$ sudo git clone https://github.com/jedi4ever/sahara.git $ cd sahara $ sudo rake build $ cd pkg $ sudo gem install ./sahara-0.0.7.gem

Sandbox機能を使うことで、ミドルウェアのバージョンアップの検証や、構成の変更の検証を気軽に行えるようになる。

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

Chef/Chef-solo

Chefとは？

• Ruby製のシステム管理ツール

• 出来ること

– OSのパッケージのインストールや管理

– OSの設定やミドルウェアの設定

– サービスの起動・停止

– クーロンの設定

• 特徴

– Rubyでジョブや設定を記述する

– Chef自体はクライアント/サーバモデル

– Chef-soloを使えばローカル単体で動作

– Recipeが多数公開されている

バージョンを指定してパッケージをインストールすることも可能

Cookbook (37signals)

Cookbook(opscode)

その他の選択肢としてPuppet等

８．デプロイ自動化

プロジェクト最初に、(デプロイするものがなくても)デプロイを

自動化する

http://bit.ly/vd1Nin

プロジェクトのあいだ、ずっとデプロイスクリプトを使うことで、プロセスがテストされ続ける 開発環境・本番環境問わず、同じ方法でデプロイする

http://bit.ly/u27Oiz

デプロイが失敗した場合にロールバックできるようにする

http://bit.ly/vFzaU9

デプロイが途中で失敗した場合、その先を手動でやらない

http://bit.ly/w34bFM

Capistrano

Railsゕプリのデプロに利用されることが多いが、もちろんそれ以外にも利用可能。SSHで接続し、サーバに対して色々な操作を行うことが出来る。

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.

Webistrano

９．テクニック

ビルド(デプロ)パプラン

ビルド(デプロ)パプラン

• SCMへのコミットをトリガーにする

• 開発者のリズムを維持するために、最初にユニットテストや一部のスモークテストを行い素早く開発者にフィードバックする

• 時間のかかる結合テストや受け入れテストは、前工程が正常だった場合のみに行う

• これによってムダな時間を使わないようにする

• ユーザビリティテストや探索的テストのうち自動化できないものもプロセスとしてはパイプライン上に定義

• 最後にデプロイできれば、デプロイパイプライン

１０．デモ

デモ

• Vagrant＋Chef-soloによる環境構築

• Doctrineによる簡単マイグレーション

• Capistrano・Webisitanoによるワンクリックデプロイ

• Jenkins + Capistranoによるデプロイメントパイプライン