[Software] aiNote Standard Edition RC 1 リリース
aiNote Standard Edition RC 1 が9月25日にリリースされました。
楽しい機能が満載ですので、ぜひ試してみてください。
ダウンロードは以下の aiNote 製品ページからどうぞ。
http://www.archway.co.jp/home/ainote.aspx
機能紹介ビデオはこちらから。
複数のアジャイルチームでのバージョン管理(再)
以前にも書いたが、チームが自律的で各コードラインポリシーとそのポリシーを壊さないようにするためのルールに従って作業できるなら、このやり方はうまくいく。自分たちの環境にもっと適合するようにカスタマイズすることだってできるだろう。
ただ、記事中の回帰テストについては誤解を生むかもしれないので、少し僕なりの考えを書いてみたいと思う。
回帰テストには、同時開発時の他のチームの変更分のテストは必ずしも含まれている必要はない。ここでの回帰テストのスコープは「自分たちのチームの変更が既存の全ての回帰テストを通過することで何も壊していないことを保証する」こと。各開発チームの変更の統合については、開発ブランチからトランクに公開された時点で、すべての回帰テストも公開されるので、ここでCIがぶん回っていれば問題なし。
開発ブランチでは、以下のような2本立てのCIサイクルを回すとよいだろう。
- 夜間ビルド
回帰テストは自動化されたテストが基本。これには機能テストツール(WebアプリならSeleniumのようなWebテスティングツール)を使用する。自動化された回帰テストには、シナリオテスト、QAサイクルで報告されたバグまたは顧客やユーザーから報告されたバグを再現するテスト（デバッギングテスト）を含める。このような回帰テストには長い時間を要するので、全ての自動化された単体テストも含め、CIサーバーで夜間ビルドをスケジューリングして実行する。
- 日次ビルド
日次ビルド（チェックイン毎にビルドされる）時には、システムの要となるテスト（全ての単体テストのサブセットとなる場合が多い）をスモークテストとして実行することで、ビルドの結果に対するフィードバック速度を確保する。
また、手動のテストは、リリース作業で実施するといいだろう。リリースサブチームは、リリースブランチからステージング環境にリリース予定のソフトウェアを公開する。QAチームは、このステージング環境のソフトウェアに対して手動でのテストを実行する。リリースブランチはこの期間中は凍結される。QAチームの作業が完了すると、リリースサブチームはリリースブランチを再度アクティブにして、QAチームから報告されたバグに対するデバッギングテストを作成してからバグ対応を実施する。
あと、最後にひとつだけ。
むやみにブランチは増やすべからず。
そのコードラインの目的が明確ではないか、コードラインポリシーが十分にシンプルでないのなら、ブランチの必要性を疑うべし。
＃あとで書いた
実は、この内容はNAnduさんの記事にコメント書こうとしたんだけど、書けなかったのでこっちに書いているうちに長くなっちゃったものです(w
NUnit 2.4.7
以前に紹介した RowTest Extension for NUnit が NUnit 2.4.7 に組み込まれています。
NUnitインストール先\bin\nunit.framework.extensions.dll を参照設定に加えると使用できます。MSTestのようにDBに接続してとまではいきませんが、これでデータドリブンテストが可能になります。
using NUnit.Framework; using NUnit.Framework.SyntaxHelpers; using NUnit.Framework.Extensions; namespace LearningNUnit.Tests.ConstraintModel { [TestFixture] public class ExtensibilityTest { [RowTest] [Row(1000, 10, 100.0000)] [Row(-1000, 10, -100.0000)] [Row(1000, 7, 142.85715)] [Row(1000, 0.00001, 100000000)] [Row(4195835, 3145729, 1.3338196)] public void データドリブンテストが成功すべき(double numerator, double denominator, double result) { Assert.That(numerator / denominator, Is.EqualTo(result).Within(0.00001)); } } }
実行結果
#後で書いた
RowTestの場合は、ExpectedException属性が無視されてしまうようだ。よく考えてみると仕方がないように思える。
LINQ勉強会 in 関西 第１回 開催のお知らせ
LINQ勉強会 in 関西 第１回 (勉強会サイトの登録メンバーのみ参照可)
今回の開催場所は西宮市民会館(アミティホール) 特別室１になりました。
勉強会
日時:2008年04月26日(土) 13:00〜17:00(受付開始 12:45)
場所:西宮市民会館(アミティホール) 特別室１
費用:500円
定員:18名
懇親会
日時:2008年04月26日(土) 17:30〜19:30
場所:旬鮮の房 はたごや 阪神西宮駅店
費用:3000円前後
締切
勉強会
締切日時:2008年04月25日(金) 24:00:00
懇親会
締切日時:2008年04月25日(金) 24:00:00
勉強会の内容
今回から LINQ 勉強会をスタートします。第一回は、LINQ の概要と、基礎となる C# の言語機能について資料、ハンズオンをもとに学習します。アジェンダは以下の通りです。
勉強会の参加について
NAgile勉強会に参加するには、勉強会サイトへのメンバー登録が必要です。メンバー参加希望は nagiler@gmail.com まで。下記の内容に必要事項を記載してメールして下さい。
===== NAgile勉強会参加希望 ===== ハンドルネーム： 氏名： ML参加用メールアドレス： ================================
[NAgile]Team BuildとWeb Deployment Projectsを利用したデプロイ
デプロイ時に本番環境とステージング環境で Web.config の内容を書き換えたいというニーズは多い。これは Visual Studio 2008 Web Deployment Projects を利用することで簡単に実現できる。
ただし、Team Foundaion Server 2008 の Team Build でデフォルトの設定のまま Web Deployment Projects を使用してビルドを行うと、エラーが発生してしまう。
ここでは、Web Deployment Projects を利用して、ステージング環境と本番環境で構成を切り替える方法および Team Build でビルドを成功させるための手順を簡単に説明しておく。
まず、簡単な Hello World アプリケーションを作成する。ボタンクリック時には、Web.config セクションから文字列を取得してラベルに表示するようなものだ。このプロジェクト名は Hello.Web とする。
続きを読む複数のアジャイルチームでのバージョン管理
InfoQの以下の記事はとても興味深い。
アジャイルチームごとに、専用の開発用ブランチを持ち、オーナーとポリシーを設定する。このチームごとのブランチのポリシーは「単体テストが完了していること」。そして、メインラインのポリシーは「いつでもリリース可能であること」。
このポリシーを実現しているのが、毎日のメインラインからチームごとのブランチへのマージ（キャッチアップ）とストーリーが完了した場合のみメインラインにパブリッシュするというシンプルなルールだ。各チームごとのブランチのオーナーは、ポリシーとルールが守られていることに責任を負う。
リリースブランチはパッチが必要となった場合のみ作成されて、不具合はこのリリース（メンテナンス）ブランチで対処される。フィーチャブランチはメインラインからブランチ分けされるのではなく、チームごとのブランチからブランチ分けする。
メインラインとリリースブランチをリリース用コードラインとし、各チームごとのブランチを作業用コードラインとすることで、「いつでもリリース可能」を実現するといったアイデアが素晴らしい。
ストーリー完了の定義＝リリース可能、すなわちメインライン ＝ DONEブランチ という考え方にもシビれるね。メインラインのコミットログとコミット回数を見れば、スプリント（イテレーション）でどのストーリーが実装されたのかがわかるなんて、とてもCoolだし。そしてアジャイルなチームであるなら（毎日マージしなければいけないということよりも、いつでもリリース可能にするためにポリシーを壊さないことに重きをおけるなら）、間違いなくこのやり方はとてもうまく機能するだろう。
