absj31この広告は、90日以上更新していないブログに表示しています。Togetter(写真:講演終盤、ワンクリックデプロイを実演中の@Ryuzee氏。)開催までの経緯まずはこちらのつぶやきやり取りを。...という様な感じでつぶやきのやり取りがなされ、この日に晴れて『ワンクリックデプロイ勉強会』が開催されました。開催場所は日本マイクロソフト品川本社。私自身この日が2回目のマイクロソフト本社での勉強会だったのですが、開始前のモニターには何とTV画面が。Nagasawa(TwitterID:@tomohn)さんの会場利用に関する諸々説明等を踏まえつつ、本編の講演開始です。YOSHIBA既にスライド資料が上がっておりますので、詳細内容についてはスライド御参照下さい。こちらのエントリはざっくりメモ&参照情報の展開程度に留めておきます。今回の勉強会に先立ち、予習的エントリとして@Ryuzeeさんのブログにて以下の記事がUP・紹介されておりましたのでこちらでもご紹介。Ryuzee.com(自動化は)一日にしてならず。/『銀の弾丸は無い』。皆さんが現場のコンテキストに合わせてやるしかない。自分たちのプロセスは自分たちで進化させるしかない。現在の競争:不安定、変わりやすい高速の変化に対応しなければならない。※ビジネスの迅速な意志決定が必要。意志決定を元に素早く具現化する必要がある。ビジネスモデルの賞味期限が短縮→1個のビジネスモデルで食える期間は短くなっている。事前に綿密に計画を立てて長期間遵守という形の維持難しくなってきている。変化が起こることを前提に頻繁に軌道修正することが必要。変化に対応出来なければマーケットから見捨てられる。価値が無くなれば滅びる(買収される)。継続的イノベーションの創発が必要。Hiranabe以下のイノベーションがそれぞれ環境として求められている。Tanablog2.継続的デリバリ現在海外で本出ています。本読んだ人?→居なかった。金融ならそうは行かない?じゃあ障害・バグならどう?1日で行ける?冷たい事を言えば、1日でリリース出来る。→仕掛けとしては1日でリリース出来るフローが存在している。Flickrのデプロイ:すごい回数。ワンクリックでデプロイ出来たとしても、リリースの意志決定に時間が掛かったら無意味。戦うべきところが他にあるのかもしれない。(組織など)継続的デリバリー:繰り返し型開発/継続的インテグレーション/継続的デリバリーがあって成り立つ。継続的デリバリーとは何か?ビジネス部門がリリーススケジュールを握ることが出来る。常に本番環境にリリース可能ボタン一発で。ユーザーとプロジェクトチームの間に固いフィードバックループを作る。継続的なフィードバックプロセスは競争優位性や無駄の削減に繋がる。継続的デリバリの8原則1.SWのリリースやデプロイは繰り返し可能であり、信頼性が高い必要がある。(※人間は信頼性が低い。)2.全てを自動化する3.難解な事や苦痛な事を繰り返し行い、自動化の方法を考える。4.全てをソースコード管理システムで管理5.完了は【リリースされた事】を意味する6.品質を作り込む7.全ての人にリリースプロセスに対しての責任がある8.継続的に改善する継続的デリバリの4プラクティス1.バイナリは1度だけビルドする2.全環境デプロイするのに完全に同一のメカニズムを使う3.スモークテストの実施4.何か起こったらラインを止めるどの断面でも再現可能か?→再現可能でないと行けない。リリースした際に、前のバージョンに即座に戻せるか?(※コードだけでなく、データベースなども含む)リリースのプロセスは毎回同じ手順。yourself)・・・自動化した方が圧倒的に楽。Configuration(設定より規約)・・・標準のものに乗っかった方が圧倒的に楽。Scrumとの関連性Scrum自身はこの件(自動化等)に関してはあまり触れていない。Doneの定義に従ってチームが諸々自動化すればよい。3.バージョン管理いわずもがな、全ての起点はここにある。全ての環境分分けて定義し、容易に切り替え可能にしておく本番環境配置の際に、アプリの各所を書き換えなければ動かない、という状況を避ける。バージョン管理は開発者の『躾』。4.テスト自動化テストしてないものを目をつぶってデプロイしてはいけない清水の舞台から飛び降りない神に祈ってリリースなんてもってのほか。一日何回もリリースしようと思ったら、人手で全体をテストするのは無理。テスト自動化の損益分岐点は相当早期にある感覚@Ryuzeeさん曰く、『手動で一回なら自動化する価値はある』アジャイルでの品質の作りこみスプリント終了=テスト終了スプリントレビューでビジネス要件の適合性も検証出来るScrumではテスト自動化については触れられていないが、アジャイル開発においてはテスト自動化は必須。自動化しないとテスト工数の占める割合が増加、価値への投資が減少してしまう。第3象限に関しては手動でやらざるを得ない。人手でやるのは探索的、ユーザビリティテストあたり。投資割合を決めて、予めバックログに組み込むことが望ましい。一定割合を投資し続けて対応。レガシーコードにおいて自動化のみに投資するのは厳しい。早く見つけた方が結果として時間も短く済む。リリースの判断基準:チームによって異なる(当然)早くリリースなのか品質優先なのか5.継続的インテグレーション継続的インテグレーションの導入と7つのステップ[1.ビルドサーバを用意する]大概が余っているPCでやっている。何だかんだで人的コストが結局一番高くつく。可能であれば早い、信頼性のマシンを用意すべき。[2.夜間ビルドを行う][3.夜間ビルド+コミット時のユニットテスト]※結果が帰ってくるまでに素早い反応が必要。※5〜10分以内に終わるのが望ましい。※ちなみにRyuzeeさんが関わっているとあるプロジェクトでは、1分で2000件のテストを流している。[4.メトリクスの取得][5.テストに対する信頼性と依存性の確立]CIに対する依存。[6.自動化された受け入れテスト+デプロイ自動化][7.継続的なデプロイ]CIサーバの構築コードが無くても作るべきメトリクスや静的解析も初期から途中からでは極めて難しい。常にグリーンの状態を保ち、エラーがある状態に慣れない。赤に慣れている場合、プロセスに問題がある。常にグリーンを保つには、アトミックな単位での作業が必要。(等々・・・)CIアンチパターン以下のエントリに記載アリ。Ryuzee.com帰り際コミットしてそのままCIの結果を見ずに帰るような奴は死刑だ!ずっとCIでのチェック内容が変わらない、プロセスが変わらない進化すべき、ずっと変わらないってのは何かがおかしい。6.マイグレーションの利用CIだけだとデプロイ自動化にまでは至らない。リリース時難しいのはDB。マイグレーションという自動化機構を使うべき。DBのスキーマの状態とリリースの状態を関連づける事によって再現可能にする。既存のアプローチの問題SQLスクリプトファイルを用いた手法だと、諸々管理が面倒、制御が難しい。マイグレーション(例)PHP:doctrineを使う。Moreオープンソースのマイグレーションツールは色々ある。ミドルや設定インストールの自動化いつでもクリーンな動作環境を作れるように自動化によって、後はアプリをデプロイすればすぐ動作する状態に。本番・開発環境の各種バージョンを合わせる事。バージョンアップの際も、この自動化機構を使う。Welcomechef/chef-solo:インストール自動化chefとは:Ruby製のシステム管理ツールインストールファイル=レシピ。バージョンを指定してパッケージをインストールする事も可能。公式エンジニアブログcookbook(37signals)様々なレシピが利用可能。GitHubその他の選択肢としてpuppet等も。8.デプロイ自動化プロジェクトの最初に、(デプロイするものが無くても)デプロイを自動化する。プロジェクトの間ずっとデプロイスクリプトを使う事で、プロセスがテストされ続ける。デプロイが失敗したらロールバック出来るように作り込む途中で失敗した場合、その先を手動でやらない。CapistranoプロビジョニングではRuby製のツールをよく使っている。(@Ryuzeeさん曰く)SSHで接続し、サーバに対して色々な操作を行う事が出来る。OIAXWebistranocap-をwebから叩く。Ryuzee.com9.テクニック基本的には自動化、ツールやスクリプトを使う。ビルド(デプロイ)パイプラインという考え方。SCMへのコミットをトリガーにする。最後の枠はとある簡単なWebアプリ(FizzBuzz結果表示)を題材にした『ビルドパイプライン』の実演デモ。ビルドパイプラインについては以下のRyuzeeさんエントリが詳しいです。Ryuzee.comソースの改修・コミットから各種ステージング環境でのテスト実施まで、勉強会のタイトル通り『ワンクリック』で流れるように作業が進んで行く様を見ているだけでも充分に楽しめる内容でした。一連の流れがデモで間近に見れたことでイメージもぐっと掴みやすくなった気がします。講演冒頭で『デプロイ自動化は、そんなに遠くないところにある』の告知文に対しツッコミが入っていたように、割と『結構遠い』感も実感したワンクリックデプロイ(&各種ビルド自動化)。ポイントを押さえ段階的に積み上げていけば決して難しくない道のりである事も今回の勉強会で知る事が出来ました(途中から組み込むよりも初期段階から繰り返し使い続ける事の有用性・重要性も)。現場の環境に対してワンクリックデプロイ(&諸々自動化)を組み込んでいくのはハードルが高そうなので、まずは個人的な開発プロジェクトでも立ち上げてその初期段階からこれら機構を組み込んでいくのが取っ付きやすそうではあるかも。年末年始、少しでもそこいらに着手出来ると良いなぁ〜。Togetter※この日の勉強会を以て、2011年の勉強会参戦は終了となります(一応予定では)。2011年参加した勉強会回数は今回分を入れて計71回。365÷71=約5日間に1回、勉強会に参戦(且つレポートUP)していた事になります。参戦レポートも書き記して行ければと思います。来年も何卒、宜しくお願い致します。(2013年08月〜12月)月別アーカイブはてなブログをはじめよう!absj31さんは、はてなブログを使っています。ブログを報告するスターをつけました引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。