test-kitchenはopscodeが提供するChefのレシピをテストするための仕掛けで、Vagrantを使って複数のOSやOSのバージョンを立ち上げレシピをテストすることができる。(Vagrant以外も使える) テストはminitestやcucumberなどを使って記述する。 テストの流れは以下のようになる。 設定ファイルに記載されたOSをVagrantで起動する（既にOSが起動している場合はそのまま利用する。ひな形となるbaseboxが存在しない場合は、設定ファイルに記載された入手元からbaseboxをダウンロードする）Vagrant側とレシピが共用され、レシピが実行されるレシピ実行後、テストが実行されるテストが終了すると、OSの設定が複数あれば次のOSを使ってテストするでは早速設定を行なってみよう。まず１つのレシピをテストする場合だ。 1つのレシピをテストする場合まずトップディレ

環境構築の自動化のツールとして一番注目されているのがChefです。 Recipeと呼ばれるインストールや設定のためのスクリプトを書いておき、それを使って新しいサーバを速攻で作ったり、Chef Serverを使えば複数のサーバ群に対して環境を一定に保つことが可能です。 ChefのRecipeは単なるrubyのスクリプトです。そしてrecipeでよく起こる問題として以下のようなものがあります。 外部サイトからtarballを取得してインストールしているような場合に、配布元の移転や、新バージョンの公開と旧バージョンの配布停止によって、recipeがコケるphpでよく使われるライブラリの配布形態であるpearのチャンネル情報が追加になったりURLが変更になる。インストールすれるパッケージがバージョンアップされ、依存関係が増えたりする。上記のようなことがあるので、recipeを定常的に動作確認してい

プロダクトオーナーは、Scrumで進める上で必須の役割です。プロダクトオーナーがプロダクトの成否やプロジェクトの成否を分けることもよくあります。良いプロダクトオーナーは開発チームと一緒に働き、開発チームの成果を検証したり、開発チームに十分に準備の出来たプロダクトバックログ項目を渡します。そういったプロダクトオーナーとしてやるべきことをまとめたので以下に公開しておきます。

みなさんこんにちは。@ryuzeeです。 プロダクトバックログアイテムの優先順位を決めるにはいくつかの方法があります。 Backlog Prioritization Techniquesにて、いくつかのやり方が説明されていましたので抜粋・意訳にてご紹介します。 どれを使うかは、そのプロダクトが自社製品かどうか、その製品の新規性の有無、開発の体制などなど、コンテキストに依存するところがあるので、どれが一番良いというのはありません。 ただ、分かりやすいという点では、狩野モデルは良いと思っています。 MoSCoW法M　絶対必要S　できれば実装すべきC　他への影響がなければ実装できるとよいW　今回は実装しないが将来に実装するかもそれぞれの要求に対してMからWまでのタグをつける。 Mは優先順位がもっとも高く、Wは最も低いということになる。 ビジネス価値に基づく判断それぞれの要求は潜在的なビジネス上の

みなさんこんにちは。@ryuzeeです。 継続的デリバリー（Continuous Delivery）の定義を改めて整理してみました。 まず1つめの定義は以下の通りです。 Continuous DeliveryとはリリースのスケジュールをIT部門が握るのではなく、ビジネス部門が握るということだ。 Continuous Deliveryを実装するということは、全体のライフサイクルを通じて常にソフトウェアが本番環境にリリース可能であるということを意味する。すなわちどのビルドもボタン一発で、完全に自動化されたリリースプロセスを通じて、秒とか分の時間で利用者にリリース可能である、ということだ。 Jez Humble Continuous Deliveryとは何か？ユーザーとプロジェクトチーム（顧客やプロダクトオーナーも含む）の間に固いフィードバックループを作ることは、結局のところ、試験的な変更や新し

みなさんこんにちは。@ryuzeeです。 僕がチームやチームメンバーに対して期待したり言いたいことを好き勝手に書いてみたいと思います。 もちろん、僕の感覚に合わない人も多いかもしれませんが、僕個人の考えということでご容赦いただければと思います。 こういうのは言語化することが非常に重要だと思っています。 給料をもらえるのは、自分が会社に所属しているからではなく、その先にお金を払ってくれるお客様がいるからだ、ということを理解しようしたがって、お客様の期待に応えられるようにふるまうことは責任であることを理解しようお金をもらう以上プロなので、プロとしてふるまうようにしようプロとして無理なものは無理と言おう会社は自分の将来の面倒を見てくれるわけではないことを理解しよう他でも通用するスキルを身につけよう。それが自分のためであることを理解しようプロとして自分に投資しよう。勉強は会社のためにやるのではなく

著作 SCRUM BOOT CAMP THE BOOK 著者／訳者：西村直人 永瀬美穂 吉羽龍太郎 出版社：翔泳社( 2013-02-13 ) 定価：￥ 2,520 スクラム初心者に向けて基本的な考え方の解説から始まり、プロジェクトでの実際の進め方やよく起こる問題への対応法まで幅広く解説。マンガと文章のセットでスクラムを短期間で理解できます。スクラムの概要を正しく理解したい人、もう一度おさらいしたい人にオススメ。 CakePHPで学ぶ継続的インテグレーション 著者／訳者：渡辺 一宏 吉羽 龍太郎 岸田 健一郎 穴澤 康裕 出版社：インプレス( 2014-09-19 ) 定価：￥ 4,320 Webアプリケーション開発における継続的インテグレーションについて、CakePHPのサンプルをベースにして、その概要から使用ツール解説、導入方法、メンテナンスまでを解説 Chef実践入門 ~コードによる

継続的デリバリーの8つの原則1. ソフトウェアのリリースやデプロイのプロセスは繰り返し可能であり信頼性が高い必要がある。このことは2つめの原則にたどり着く。 2. 全てを自動化する！手動のデプロイは決して繰り返し可能で信頼性が高いことには成り得ない。 あなたは繰り返し行う全てのタスクを自動化することについて本気で投資する必要がある。そしてこうすることによって信頼性に繋がっていくのだ。 3. なにか難しかったり苦痛なことがあったら、それを何度もやってみる表面的には、ばかげた話のように聞こえるかもしれない。しかし基本的にこれが意味していることは、苦痛であることを頻繁に行うことは、あなたがそれを改善し、多分自動化する方向に導いてくれるはずだ。そして最終的には苦痛がなくなり容易に行うことができるようになるだろう。 データベースのスキーマをデプロイすることを例にとってみてみよう。もしこれがトリッキー

みなさんこんにちは。@ryuzeeです。 継続的インテグレーションの導入に関する分かりやすい記事があったので抜粋・意訳にてご紹介します。 原文はJohn Ferguson Smart氏のブログ記事「The Seven Phases of Introducing Continuous Integration into Your Organization」です。 継続的インテグレーションは全部かゼロかといった類のものではない。事実、CIの組織への導入はいくつかの明確な段階を経て進んでいくのだ。それぞれの段階は技術的な構造もそうだが、それ以上に重要であるであろう開発チーム自体のプラクティスや文化のインクリメンタルな改善を含んでいる。 以下の章では各段階についておおよその全体像を示すことにしよう。 第1段階 ビルドサーバがない初期の段階ではチームはなんらの中央ビルドサーバも持ちあわせていない。ソフ

1. ふりかえり（レトロスペクティブ）をしないか、間違ったふりかえりをするふりかえりをせずして、どうやって物事をよりうまくできるようにすることができるというのだろうか？ ふりかえりは、全てのチームメンバーがうまく行ったこと、もっとうまくできるだろうことについて議論できるという点で必要不可欠だ。 そしてもちろん言うまでもなく、失敗から学習しなければならない。もしそういったことが行われていない（形式的なふりかえり）なら、ふりかえりは役に立っていない。 2. ダメなプロダクトオーナープロダクトオーナーはいつでもプロジェクトのために時間を使えるようでなくてはならない。 プロダクトオーナーはスプリントプランニングやふりかえりに参加しなければならない。 また一方でプロダクトオーナーはスプリント中のタスクは見積りしてはならない。見積りはチームの責任なのだ。 プロダクトオーナーはビジネス上の優先順位に基づ

みなさんこんにちは。@ryuzeeです。 前回の投稿の続きです。 今度はMichael Dubakov氏が5 Right Reasons to Apply Kanbanということで、正しい導入理由5個について説明していますので、抜粋・意訳にてご紹介します。 カンバンを導入する正しい理由5個 1. いつでもリリースできるようにするスクラムやXPではイテレーションの途中でリリースすることはできない。 カンバンであればいつでもリリースできるかもしれない。 ユーザーストーリーの準備ができたたら、それをリリースする。 このような開発プロセスを作ることは挑戦的だろう。 このような開発プロセスでは、フィーチャー単位でソースコードレポジトリのブランチを管理し、頻繁にマージや結合やテストを行う必要がある。 ただこうすることで頻繁にリリースすることができるようになるのだ。 これはやってみる価値がある。 プロダ

みなさんこんにちは。@ryuzeeです。 アジャイルな開発を行っているチーム（やっていなくても構いませんが…）のアセスメントを行う方法について考えてみました。 あくまで一例でこれが最適とは限りませんが、コーチとしてリアルなプロジェクトの具体的なところではない原点の部分を軸にしてチームの成熟度を把握できるようになりたいなぁということで、アジャイルマニフェストの12の原則をベースにして考えてみました（今後継続的に足していったり、現場で試してみる予定です）。 1. 顧客満足を最優先し、価値のあるソフトウェアを早く継続的に提供します。プロとして顧客のために行動できているか正しいことを行っているかどうかを常に意識しているか顧客のためとは顧客の言う事をすべてやることではないことを理解しているか価値は提供する側が決めるものではないことを理解しているか顧客にとって価値がなかったらどうなるか理解しているか2

著作 SCRUM BOOT CAMP THE BOOK 著者／訳者：西村直人 永瀬美穂 吉羽龍太郎 出版社：翔泳社( 2013-02-13 ) 定価：￥ 2,520 スクラム初心者に向けて基本的な考え方の解説から始まり、プロジェクトでの実際の進め方やよく起こる問題への対応法まで幅広く解説。マンガと文章のセットでスクラムを短期間で理解できます。スクラムの概要を正しく理解したい人、もう一度おさらいしたい人にオススメ。 CakePHPで学ぶ継続的インテグレーション 著者／訳者：渡辺 一宏 吉羽 龍太郎 岸田 健一郎 穴澤 康裕 出版社：インプレス( 2014-09-19 ) 定価：￥ 4,320 Webアプリケーション開発における継続的インテグレーションについて、CakePHPのサンプルをベースにして、その概要から使用ツール解説、導入方法、メンテナンスまでを解説 Chef実践入門 ~コードによる

以前に作っておいた大きめなリリースをする際にチェックしておくべきことのリストが役に立ちそうなので公開しておきます。 僕の場合は普段はワンクリックデプロイが多いんだけど、かなり大掛かりな変更をするケースが年に数回あったりするので、その際にこういうリストを使ってリリース計画をチェックしています。(もちろん大掛かりなリリースでもワンクリックでできるのに越したことはないし、そもそもビッグバンリリースにならないようにできるだけ小さい単位で頻繁にリリースできるに越したこともない) 体制当日の体制は決まっているか夜間立会いの場合、日中の営業時間の対応体制は決まっているか翌営業日以降の体制は決まっているか連絡担当と作業担当は分離されているか作業担当はペア作業になっているか。作業者と確認者を定めているか顧客の連絡先を抑えているか顧客の連絡順番を抑えているか、お客様の当日の所在を抑えているか顧客への連絡タイミ

2011年12月20日に品川の日本マイクロソフト本社をお借りして、ワンクリックデプロイ勉強会を開催しました。 当初内輪でやろうと思っていたのですが多くの方にご参加いただきありがとうございました。 また、もろもろセッティング頂いた@katzchangと日本マイクロソフトの長沢さんありがとうございました。 以下にセッション資料を公開します。 例によって短文での感想を。 セッション開始前にちゃんとRed Bullを飲んでおいたので元気だった最初の会場へのヒアリングで既にワンクリックデプロイをしている人がいるか調査したところいなかった。まぁWebサービス系でやっているところは増えては来ているもののまだ定着フェーズではなさそうな感じユニットテストやJenkinsはかなりの現場で使われている個人的な今日の名言は、「障害発生時に１日でリリースできるなら、普段のリリースも１日にできるはずだ」というやつ。物