20120721 chefの下準備 #devlove

2012/07/21 #devlove CChheeffの下準備楽しいCCooookkiinnggのその前に!!!! アジャイルコーチ RRyyuuttaarroo YYOOSSHHIIBBAA

吉羽龍太郎 Ryutaro YOSHIBA アジャイルコーチ Web: http://www.ryuzee.com Twitter: @ryuzee 認定スクラムプロフェッショナル認定スクラムマスター認定スクラムプロダクトオーナー Microsoft MVP for Visual Studio ALM

Scrum Boot Camp

2013/1/15-‐16 at Akihabara UDX Scrum Regional Gathering Tokyo 2013 http://bit.ly/LtunLe

このセッションでは開発や運用における大きな方向�性の話をします。その理解なくして、俺が楽だから○○使うぜ！とか開発チームの奴らは××だなぁ！とか環境構築チームが△△なせいだ！とか言うのは不毛の極み。

会場調査•  全員起⽴立立してください•  ユニットテストを書いていない⽅方は着席•  結合テストを⾃自動化していない⽅方は着席•  継続的インテグレーションサーバを使っていない⽅方は着席•  デプロイを⾃自動化していない⽅方は着席•  環境構築を⾃自動化していない⽅方は着席最後まで起立されている方は帰って大丈夫ですｗ

一日にしてならず http://bit.ly/vPmiFJ

NNoo SSiillvveerr BBuulllleett† http://bit.ly/vj0b0v

http://bit.ly/sygcE9自分たちのプロセスは自分たちで進化させるしかない！

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

IITT投資は業務効率化から戦略実現へ

以前の競争http://bit.ly/rioQDZ

現在の競争競争の速度の変化

迅速な意思決定が必要 http://bit.ly/pccwAN

意思決定をもとに素早く具現化する必要 http://bit.ly/r1ziWL

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

変化への対応“事前に綿密” にたてた計画を “長期間遵守” して大丈夫なのか？

変化への対応“変化が起こる” ことを前提に “頻繁に軌道修正” することが必要 http://bit.ly/oX9ImQ

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

価値がなくなれば滅びるhttp://bit.ly/qJg8EX

マインドイノベーション http://bit.ly/nrDcZf

プロセスプロダクトイノベーションイノベーション http://bit.ly/qpjFXr http://bit.ly/ornfUo

２．継続的デリバリ

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

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

継続的デリバリー継続的デリバリー繰り返し型の継続的継続的開発インテグレーションデプロイ継続的デリバリーとは、ソフトウェア全体のライフサイクルを通じて常にソフトウェアが本番環境にリリース可能であるということを意味する。すなわちどのビルドもボタン一発で、完全に自動化されたリリースプロセスを通じてリリースする。それによってビジネス側がビジネス状況に応じてリリース判断できるようになる。

継続的デリバリー継続的デリバリー繰り返し型の継続的継続的開発インテグレーションデプロイ Scrum Scrum＋XP Lean u  要求に順位付け u  xUnit等による u  Just in Timeで u  タイムボックステスト⾃自動化顧客が必要なもによる制御 u  テスト駆動開発のを必要なとき u  検査と適⽤用によ u  コーディング規に。る継続的改善約 u  サイクルタイム u  透明性の確保 u  ペアプロ等を測定し改善す u  ⾃自⼰己組織型チー u  常時出荷可能なる。ム品質を保持 u  ビジネス活動そ u  技術的プラク u  主に技術的プラのものティスの定義なクティスから構 u  全体最適し成される

継続的デリバリ http://bit.ly/tFrqbzユーザーとプロジェクトチームの間に固いフィードバックループを作る

継続的デリバリ http://bit.ly/uLQaml継続的なフィードバックプロセスは、競争優位性やムダの削減につながる

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

継続的デリバリの8原則2 全てを自動化する

継続的デリバリの8原則3 難解なことや苦痛なことを繰り返し行い自動化の方法を考える

継続的デリバリの8原則4 全てをソースコード管理システムで管理する

継続的デリバリの8原則5 完了は「リリースされたこと」を意味する

継続的デリバリの8原則6 品質を作りこむ

継続的デリバリの8原則7 すべての人にリリースプロセスに対しての責任がある

継続的デリバリの8原則8 継続的に改�善する

継続的デリバリの4プラクティスl バイナリは一度だけビルドする l すべての環境にデプロイするのに完全に同一のメカニズムを使う l デプロイメントでスモークテストを実施する l 何か問題が起こったらラインを止める

　　どの再断現面可で能もか？ http://bit.ly/uVQu5I

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

Convention OverConfiguration

３．バージョン管理

ソースコードのバージョン管理理•  いわずもがな。全ての起点はここにある•  コードの共同所有の原則への理理解•  このソースコードは本番環境または開発環境などで同じように動作しなければならない•  テストを書く習慣、コミット前に他のテストも含めて通してからコミットする習慣

設定ファイルのバージョン管理理•  環境によって異異なる設定値（接続先データベース情報など）が書かれた設定ファイルもバージョン管理理する•  開発環境⽤用、ステージング環境⽤用、本番環境⽤用などに分けて定義し、容易易に切切り替え可能にする•  本番環境に配置する際に、アプリケーションの各所を書き換えなければ動作しないという状況は避ける

バージョン管理は開発者のしつけ 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ではフレームワークの定義のみで、テスト⾃自動化については触れられていない.しかしアジャイル開発においてはテスト⾃自動化は必須⼩小規模リリースのたびに⼿手動でテストするとスプリント後半になるにつれてテストコストが膨らむ⾃自動化しないとソフトウェア規模に応じて、テスト⼯工数の占める割合が増加していく（＝価値への投資が減少）

テストの4象限ビジネス⾯面（ビジネス的品質）【⾃自動と⼿手動】【⼿手動】※1 機能テスト探索索的テストストーリーテストシナリオテストプロトタイプユーザビリティテストシミュレーションユーザー受⼊入テストチアルファ版、ベータ版製品ー第２象限第３象限ムをを批⽀支【⾃自動化】【ツール】評援単体テストパフォーマンステストコンポーネントテスト負荷テストセキュリティテスト第１象限第４象限技術⾯面（技術的品質）※1 ATDD等では⾃自動化

テストの4象限第1象限　チームを⽀支援する技術⾯面のテストテスト駆動開発などアジャイル開発の中⼼心。第2象限　チームを⽀支援するビジネス⾯面のテスト顧客の視点からのハイレベルの機能テストなど。第3象限　製品を批評するビジネス⾯面のテストユーザー受⼊入テスト、探索索的テストなど。第4象限　技術⾯面のテストを使った製品の批評パフォーマンステスト、セキュリティテストなど。「アジャイルテスト ―⾼高品質を追求するアジャイルチームにおけるテストの視点―」増⽥田聡⽒氏http://codezine.jp/devsumi/2010/report/07/ 　より引⽤用

ツール・⼿手法のマッピング(例例) ビジネス⾯面（ビジネス的品質）【⾃自動と⼿手動】【⼿手動】機能テスト探索索的テスト Selenium ストーリーテストシナリオテスト Cucumber プロトタイプユーザビリティテスト Rspec シミュレーションユーザー受⼊入テスト FitNess … チアルファ版、ベータ版製品ー CI推奨第２象限⼀一部CI可能第３象限ムをを批⽀支【⾃自動化】【ツール】評援単体テストパフォーマンステスト Jmeter コンポーネントテスト TDD 負荷テスト WebScarab xUnit セキュリティテスト RatProxy PMD, CPD … ValGrind … CI必須第１象限 CI推奨第４象限技術⾯面（技術的品質）

テスト⾃自動化の進め⽅方プロダクトバックログレガシーコードにおいスプリントて、製品コードの開発バックログをとめて自動化のみへ投資するのは現実的に難しいので、投資割合テスト⾃自動化バックログをきめて、予めバックログに組み込むことが望ましい

問題修正にかかる時間フェーズ修正までの時間要求や設計 5分コードやユニットテスト 15分結合テストやシステムテスト 1時間ベータテスト 2時間リリース後 1⽇日

５．継続的インテグレーション

継続的インテグレーションの導入� と利用促進の７ステップ http://bit.ly/soiCFy

http://bit.ly/rVAW901 ビルドサーバを用意する

2 夜間ビルドを行う http://bit.ly/rubXiA

3 http://bit.ly/s3W9aF 夜間ビルド＋コミット時のユニットテスト

4 http://bit.ly/rYN42H メトリクスの取得

5 http://bit.ly/rOloeO テストに対する信頼性と依存性の確立

6 http://bit.ly/sP6BvN 自動化された受け入�れテスト＋デプロイ自動化

7 http://bit.ly/uc3x59 継続的なデプロイ

CIサーバの構築•  プロジェクト初期の段階でコードがなくても構築する•  コードのメトリクスや静的解析は初期から継続的に実施する⽅方が効果がある•  常にグリーン(Jenkinsなら⻘青)の状態を保ち、エラーがある状態に慣れない•  常にグリーンに保つにはアトミックな単位での作業、マイグレーションとの連携、チームのコミットに対する態度度が⽋欠かせない

Jenkinsでの例例

第１象限での⾃自動評価プロジェクトの特性や要員構成等に応じて決めるテスト件数と結果(単体、結合) PMD警告件数Checkstyle警告件数カバレージ

チーム活動の評価コード⾏行行数コミット時間アクティビティ

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

DBスキーマのバージョン管理理データベースのスキーマの状態とリリースの状態を関連付けることによって再現可能にする

既存のアプローチの問題 http://bit.ly/vbtqZcü  sqlスクリプトファイルは管理理が煩雑ü  sqlスクリプトは⾃自動実⾏行行に向かないü  ロールバックやデータ移⾏行行の考慮もしづらいü  複数のsqlスクリプトの実⾏行行順序の制御が難しい

問題の例例 SQLの実⾏行行順序によって状態が変わってしまう1.sql 1→2の順に実⾏行行すると….alter table users add column lastlogin datetime after name;2.sqlalter table users add column disabled 2→1の順に実⾏行行すると….boolean default false after name;

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

データベースの変更更管理理$ ls -‐‑‒11301223401_̲addchangelogs.php 前後関係は、ファイル1313445291_̲addinformation.php 先頭の数字の⼤大⼩小で判1317489252_̲addpriorities.php 断される。1318776293_̲addprojects.php （規約）1318889397_̲addremainingtimes.php1320243212_̲addresolutions.php1321049290_̲addsprints.php1321509396_̲addschemamigrations.php1322392147_̲ﬁx_̲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

マイグレーションの状態mysql> mysql> mysql> mysql> mysql> select * from migration_version; +---------+ | version | 現在30個⽬目のマイグレー+---------+ ションファイルまで登録| 30 | 済であることを指す+---------+ 1 row in set (0.08 sec) mysql> mysql>

マイグレーション実⾏行行コマンド１つで最新のバージョンに更更新したり、特定のバージョンに戻すことができる # 最新のバージョンへ更更新 $ 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 本番環境と開発環境の各種バージョンをあわせる

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

仮想化と⾃自動化（Vagrant）

Vagrantのインストールと起動$ sudo gem install vagrant $ sudo vagrant box add lucid32 h<p://ﬁles.vagrantup.com/lucid32.box $ sudo vagrant init $ sudo vagrant up わずか４ステップで、仮想インスタンスが起動する!!!!

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

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機能を使うことで、ミドルウェアのバージョンアップの検証や、構成の変更更の検証を気軽に⾏行行えるようになる。

Sandboxモード ■sandboxモードに⼊入る（仮想マシンを再起動しても有効） sudo vagrant sandbox on ■sandboxを開始時点にロールバックする sudo vagrant sandbox rollback ■sandboxモードの終了了（commitしていないものは消える） sudo vagrant sandbox oﬀ ■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)

８．デプロイ自動化

http://bit.ly/vd1Nin プロジェクト最初に、((デプロイするものがなくても))デプロイを自動化する

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

デプロイが失敗した場合にロールバックできるようにする http://bit.ly/vFzaU9

デプロイが途中で失敗した場合、その先を手動でやらない http://bit.ly/w34bFM

CapistranoRailsアプリのデプロイに利利⽤用されることが多いが、もちろんそれ以外にも利利⽤用可能。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

http://www.ryuzee.com	1567
http://jedipunkz.github.com	1226
http://d.hatena.ne.jp	833
http://devloveblog.wordpress.com	631
http://172.24.18.51	136
http://blog.livedoor.jp	110
http://jedipunkz.github.io	35
http://snip-snap.posterous.com	34
http://webcache.googleusercontent.com	30
http://localhost	18
http://bukumatube.com	6
https://si0.twimg.com	6
http://www.techgig.com	4
https://twimg0-a.akamaihd.net	4
http://127.0.0.1	1
http://www.twylah.com	1
https://twitter.com	1
http://snipsnaptmae.wordpress.com	1

20120721 chefの下準備 #devlove

by Ryuzee YOSHIBA on Jul 21, 2012

Accessibility

Categories

Upload Details

Usage Rights

18 Embeds 4,644

Statistics

20120721 chefの下準備 #devlove Presentation Transcript