[アーカイブ] TFS でバディビルド (プライベートビルド) を行うたった一つの設定
<オリジナル投稿 2012年10月16日 本ポストの情報はオリジナル投稿時点のものです。マイクロソフトの正式な見解や製品の仕様を保証するものではないことをご了承ください。>
TFS の自動ビルドでは、継続的インテグレーション (CI: Continuous Integration) も実に容易に行えることはみなさん、もうご存知だと思います。設定箇所は、ビルド定義の一か所だけです。
「トリガー」で、「継続的インテグレーション」を選択するだけで、ソースコードをチェックインした際に、ビルドサーバーで自動ビルドと検証が走り、結果を開発者やチームに教えてくれます。
この進化形として、「ゲートチェックイン」があります。
これは、よくある継続的インテグレーションの動作である、
チェックイン (コミット) → リポジトリに変更が反映 → 自動ビルド → 自動検証 → OK/NG
のプロセスをたどりません。このプロセスだと、ソースコードの変更は、リポジトリに反映されたのちに自動ビルド→自動検証と進みますので、OK の場合は、問題ありませんが、NG だった場合は、影響がチーム全体、システム全体に及ぶ可能性がでてきてしまいます。リカバリ大変ですよね。気軽にチェックインできないですよねぇ～。
ゲートチェックインのプロセスは以下です。
チェックイン (コミット) → シェルビング → (シェルブセットとリポジトリの最新を)自動ビルド、自動検証 → OK/NG
OK: チェックイン = ビルド成功
NG: チェックインを拒否 ＝ ビルド失敗
要するにまさに、「品質ゲート」の役割を継続的インテグレーションに持たせることができます。
失敗した場合:
成功した場合:
この設定が、上述の「トリガーでゲートチェックイン」を設定するだけなわけです。便利ですね。
さて、本題です。開発者の心情としては、もっと頻繁に最新のソースコードと自分の変更をマージしてビルドし、確認したいものです。これらは、「バディビルド」や「プライベートビルド」と呼ばれる方法になります。これを実現したいときには、それ相応の覚悟が要りますね。それこそ、自身の環境に、最新コードを持ってきて、そこに変更コードをマージして、自身のマシンでビルドと検証するとか・・・。そんなことしている時間はもう開発者にはありません。
先に紹介したゲートチェックインは、ビルドプロセスでもご紹介したように、位置的な保管庫であるシェルブを活用しています。これ、実はそのままバディビルド/プライベートビルドに活用できます。
やり方は、いたって簡単です。ゲートチェックインを設定しているビルド定義でキューを配置します。「キューを配置 ＝ ビルドの実行」 と思ってください。
「新しいビルドをキューに配置」をクリックするとダイアログが起動されます。
実は、すべにこの時点で、バディビルドが行える環境になっています。「シェルブセット」で事前にシェルブしておいたシェルブを選択し、「キューに登録」ボタンを押すだけです。
これで、以下の結果となります。
ビルドとテストがOK: OKを記録し、何もしない（チェックインしない）
ビルドとテストがNG: NGを記録し、何もしない (チェックインしない)
継続的インテグレーションしたのと同じことを、自由自在にいつでも行えることになります。ポイントはこちらだけ！
「ビルド成功後に変更をチェックイン」にチェックが入っていません。これがポイントです。
逆に言うと、シェルブセットを指定し、このチェックボックスにチェックが入っていると、ビルドとテストが成功し場合のみ、採用され、チェックインもしてくれるわけです。
これをうまく使いこなすことで、開発者としての安心と信頼を手に入れることが言えるといっても言い過ぎではないのではないかと思います。
ついでに、このバディビルド (プライベートビルド)時のビルド成果物の格納場所を設定することもできます。
「個人のビルドの格納場所」に UNC パスで指定するだけです。
TFS は多くの人が、使える状況になってきていますので、こういうところで苦労するのではなく、もっと開発者らしいクリエイティブなところで苦労できるようになるといいですね。そのためにも、食わず嫌いせず、TFS を使ってみましょう。Javaでも使えますよ～。