Jenkins で ASP.NET のWebアプリケーションをデプロイする

Jenkins を使って自動ビルドや自動テストを走らせていたので、デプロイも Jenkins からできるようにしてみました。

ちなみに ASP.NET MVC のプロジェクトにて行いました。おそらく WebForms でも同じようにできると思います。

必要なもの

Jenkins で Visual Studio のソリューションやプロジェクトをビルドするには、Jenkins の MSBuild プラグインがあると便利です。Jenkins のプラグインマネージャから簡単にインストールできます。

また、デプロイには MSDeploy を利用しますので、デプロイ先の環境に MSDeploy がインストールされている必要があります。

パッケージの作成

MSDeploy でデプロイするためのパッケージを MSBuild で簡単にパッケージを作ることができます。“ビルド手順の追加” から “Build a Visual Studio project or solution using MSBuild” をこんな感じで追加して設定。

ターゲットを “Package” にすると、MSDeploy を利用して配置するためのパッケージが ”obj\Release\Package” のようなパスに作成されます。

ちなみにターゲット “Package” が必要なので、パッケージの作成は .NET Framework 4 の MSBuild で行う必要があります。たぶん…

ステージングとかプロダクションとかそれぞれの環境に応じたビルド構成(Staging, Production, etc)や構成変換ファイル(Web.Staging.config とか)がある場合は、Configuration=Staging とかでビルドすればOKです。

MSDeploy

MSDeploy については、こちらのMSDNの記事(http://msdn.microsoft.com/ja-jp/library/dd483479(v=vs.100).aspx)が詳しいです。

先ほどの MSBuild で作られたパッケージの中に、”プロジェクト名.deploy.cmd” というコマンドファイルが生成されています。(obj\Release\Package\Sample.Mvc.deploy.cmd みたいな)
これを実行すると配置が実行されます。が、その前に配置先の設定や接続文字列を設定したりする必要があります。

※ ちなみに “プロジェクト名.deploy-readme.txt” みたいなファイルが一緒に生成されています。非常に丁寧な解説が載っていますのでぜひ目を通して下さい。

配置先と接続文字列の設定

先ほどのコマンドファイルと同じディレクトリに、”プロジェクト名.SetParameters.xml” という下のようなXMLファイルが作られます。デプロイのための設定などはこのファイルを利用して指定します。

配置先は、”IIS Web Application Name” パラメータで指定します。value を配置先のアプリケーションにします。接続文字列も同じように設定してやります。

このパラメータファイルの設定ですが、私はあらかじめステージング用とかプロダクション用などそれぞれ用意しておいて、MSDeploy を走らせる前に上書きしています。

MSDeploy の実行

パラメータファイルが用意できたら、あとはこんな感じで実行するだけです。

Sample.Mvc.deploy.cmd /Y

この/Yパラメータを指定すると、実際にパッケージがデプロイされます。/T パラメータなど指定することで、パッケージをデプロイせずにシミュレートだけを行ったりできます。(詳しい解説が上記の deploy-readme.txt に載っています

MSDeploy の実行を Jenkins に設定する

上記の MSDeploy の実行手順を Jenkins に設定しましょう。
ビルド手順を追加からWindowsバッチコマンドの実行を追加します。

たぶんこんな感じの内容になると思います。

とても簡単です。あとは Jenkins でビルドを実行すればめでたく配置されるはずです。

最後に

このようにデプロイを自動化することで、継続的インテグレーションが捗ります。
ASP.NET でのこういった記事が少ない気がしたので書いてみました。(もしかして当たり前すぎるんでしょうか…)

私の環境では、ステージングにはビルドマシンからアクセスできるため、紹介したような方法でデプロイしていますが、プロダクションは別のネットワークにあるため直接デプロイできません。

なので、プロダクション用のパッケージを作ってZIPファイルで圧縮してダウンロードできるようにし、実際のデプロイではそれをプロダクション環境に持って行って解凍、先ほどのコマンドファイルを実行しています。

ビルドトリガでSCMをポーリングしてやれば、コミットした内容がすぐにデプロイされるのでいろいろな環境を素早く最新の状態に保てます。

Jenkinsさんのおかげで面倒なビルドやデプロイの作業から開放されてずいぶん楽になりました。これからも Jenkins さんと仲良くやって行きたいと思います。

イベント・ソーシング

たまたま「イベント・ソーシング」について知る機会があり、調べて試してみました。
非常に興味深い考え方です。

イベント・ソーシングを知る from Shuhei Fujita

実際に動作するコードを書いてみようと、軽い気持ちでやってみたところなかなか難しくて時間がかかってしまいました。途中で別の作業をしなければならなくなったので、一旦中断...

ちなみに以下の記事が大変わかりやすいです。

• Why Event Sourcing?
• Greg Young流CQRS - Mark Nijhof - Digital Romanticism
• state ソーシング、 event ソーシング 【スタイルの選択肢】 | システム設計日記

また、以下に DDD, CQRS, Event Sourcing のサンプルがあります。こちらのサンプルを参考に実際にコードを書いてみています。

• https://github.com/MarkNijhof/Fohjin

[C#]エンティティのEqualsとGetHashCode

しばらくの間、曖昧な理解のまま Equals と GetHashCode を実装していたので、反省。

まず、Equals と GetHashCode の実装については、以下の記事が参考になります。

• Equals メソッドの実装 - MSDN
• Equals および等値演算子 (==) 実装のガイドライン - MSDN

概ね理解しているつもりだったんですが、今日ハッシュのコレクションを扱うときに、コレクション内のある要素を削除(Remove)しようとしても、削除できない(Contains(item) が false になってしまう)、というバグが出たので調べていたら、こちらの記事に行き当たりました。

• [Effective C#] 項目10 GetHashCode() の罠に注意すること | まさくらのブログ

1. 2 つのオブジェクトが等しい (== 演算子の定義によって等しい) 場合、それらのオブジェクトからは同じハッシュ値が生成されなければならない。同じハッシュ値が生成されない場合、コンテナからオブジェクトを探しだすためのキーとしてハッシュコードを使用することができない。
2. 任意のオブジェクト A に対して、A.GetHashCode() は各インスタンス毎に異なる値でなければならない。A のどんなメソッドが呼ばれたとしても、A.GetHashCode() は常に同じ値を返さなければならない。これによって、オブジェクトが格納されている正しいバケツを常に見つけだすことができる。
3. ハッシュ関数は任意に入力された複数の整数値に対し、ランダム分布となる返り値を返す必要がある。この性質により、ハッシュベースのコンテナへ効率的にオブジェクトを格納できる。

この実装ポリシーのうち、2番を思いっきり無視していました。つまり、ハッシュのコレクションを生成したあとに、コレクション内のある要素の GetHashCode の演算に利用してるプロパティが変化して、ハッシュ値が変わってしまったようです。

また、以下の様な記事もありました。

• CA1046: 参照型で、演算子 equals をオーバーロードしないでください - MSDN

 

エンティティにおける、Equals と GetHashCode の実装

今回このハッシュのコレクションというのは、いわいるエンティティのコレクションだったわけですが、その実装が以下のようなもの。

public class User
{
    public int Id { get; set; }

    public string FirstName { get; set; }

    public string LastName { get; set; }

    public override bool Equals(object obj)
    {
        var other = obj as User;
        return 
            other != null && 
            FirstName == other.FirstName && 
            LastName == other.LastName;
    }

    public override int GetHashCode()
    {
        return 
            (FirstName ?? string.Empty).GetHashCode() ^ 
            (LastName ?? string.Empty).GetHashCode();
    }
}

テーブルのほうはこんな感じです。

CREATE TABLE Users (
    Id INT IDENTITY PRIMARY KEY,
    FirstName NVARCHAR(50) NOT NULL,
    LastName NVARCHAR(50) NOT NULL,
    UNIQUE (FirstName, LastName)
)

Id が人工キーで、スキーマ上のメインの識別子になります。自然キーとして FirstName と LastName が利用できる(実際には名前は被るので使えないと思いますが…例です)ので、FirstName と LastName に一意キー制約を付けてあります。

この Equals 及び GetHashCode の実装では、以下のガイドラインの推奨に従って、人工キーではなく自然キーによる等価比較の実装を行なっています。(ちなみに ORM は NHibernate です

• 第4章 永続クラス (4.3. equals() と hashCode()の実装)

ビジネスキーの等価性 を使って、 equals() と hashCode() を実装することをお勧めします。ビジネスキーの等価性とは、 equals() メソッドが、ビジネスキー、つまり現実の世界においてインスタンスを特定するキー（自然 候補キー） を形成するプロパティだけを比較することを意味します。

このとき、FirstName と LastName が変化する場合、上記のような実装だとハッシュ値が変わってしまってポリシー違反を起こします。

なので、FirstName と LastName が変化する属性としての側面をもつ場合は、Equals と GetHashCode の実装に使うとマズイということになります。(FirstName と LastName が不変ならオッケーなんですが

このような場合は、素直に変化しない(はずの) Id を用いたほうがよさそうです。

public class User
{
    public int Id { get; set; }

    public string FirstName { get; set; }

    public string LastName { get; set; }

    public override bool Equals(object obj)
    {
        var other = obj as User;
        return
            other != null &&
            Id == other.Id;
    }

    public override int GetHashCode()
    {
        return Id.GetHashCode();
    }
}

本来なら自然キーでの実装のほうが、なにかと扱いやすいのですが仕方ないですね。

ちなみにこの例でも、Id のセッタが公開されてしまっているので、キチンと実装する場合は、Id が不変になるように工夫したほうがよさそうです。

[C#]Enumに振る舞いを

Enumにプロパティとかメソッドとか、豊富な振る舞いを持たせたい時どうすればいいんだろうという疑問です。

拡張メソッドを使う

public enum AircraftType
{
    Fighter,
    Attacker,
    Bomber
}

public static class AircraftTypeHelper
{
    public static string DisplayName(this AircraftType value)
    {
        return _displayNames[value];
    }

    private readonly static IDictionary<AircraftType, string> _displayNames = new Dictionary<AircraftType, string>()
    {
        { AircraftType.Fighter, "戦闘機" },
        { AircraftType.Attacker, "攻撃機" },
        { AircraftType.Bomber, "爆撃機" }
    };
}

 string displayName = AircraftType.Fighter.DisplayName();

こんな感じに拡張メソッドを使うと、プロパティは無理だけど、それなりに振る舞いをつけることができます。

素直にクラスで実装する

public class AircraftType
{
    private AircraftType(AircraftTypeValue value)
    {
        value = value;
    }

    private enum AircraftTypeValue
    {
        Fighter,
        Attacker,
        Bomber
    }

    public static readonly AircraftType Fighter = new AircraftType(AircraftTypeValue.Fighter);
    public static readonly AircraftType Attacker = new AircraftType(AircraftTypeValue.Attacker);
    public static readonly AircraftType Bomber = new AircraftType(AircraftTypeValue.Bomber);

     private readonly AircraftTypeValue _value;

    public override bool Equals(object obj)
    {
        var other = obj as AircraftType;
        return other != null && _value == other._value;
    }

    public override int GetHashCode()
    {
        return _value.GetHashCode();
    }

    public override string ToString()
    {
        return _value.ToString();
    }
}

こんな感じでシングルトンで実装する方法です。Equals とか ToString なんかの基本的なメソッドの実装は内部に隠してある Enum に丸投げ。

これならプロパティでもなんでも追加できます。(当たり前だけど...)

    public string DisplayName
    {
        get { return _displayNames[_value]; }
    }

    private readonly static IDictionary<AircraftTypeValue, string> _displayNames = new Dictionary<AircraftTypeValue, string>()
    {
        { AircraftTypeValue.Fighter, "戦闘機" },
        { AircraftTypeValue.Attacker, "攻撃機" },
        { AircraftTypeValue.Bomber, "爆撃機" }
    };

    string displayName = AircraftType.Fighter.DisplayName;

どっちがいいんだろう

拡張メソッドを使う方はまんま Enum を使うので手軽ですね。でも拡張メソッド以上のことはできないので、複雑な振る舞いを持たせたりするのには向いていないですね。

シングルトンでの実装は、自由にプロパティでもメソッドでも追加できるので柔軟性はあります。でも、実装がちょっと面倒です。

また、Enum をそのまま使うと FlagsAttributes でビット演算できたりして重宝することもあります。

個人的には後者(シングルトン)を使うことが多いのですが、振る舞いなんかがあまりない純粋な列挙値だったら普通に Enum を使います。あと、ビット演算したいときとか…

ケース・バイ・ケースなのかな？

[ASP.NET MVC]検証周りの設計

ASP.NET MVC では、ModelState を利用してビューに検証結果を表示したり、コントローラ側からエラーを追加したりできます。

ModelBinder を使えば、DataAnnotation で面倒な検証作業を省略でき、エラーを ModelState に手動で追加する必要もなく、とても素晴らしいフレームワークです。

でも、実際に作ってみると躓く(というか躓いた)のが、モデル内部の検証結果をどのようにビューへ伝達するか、でした。

ASP.NET MVC の検証機構と、モデルでの検証

まず ModelBinder や ModelState はあくまでも、コントローラとビュー側の仕組みです。うまく設計されたMVCアーキテクチャであれば、モデルは単体で独立していて、コントローラやビューに依存していないはずです。

そうなると、モデルはしっかり内部に検証機構を備える必要があります。コントローラやビューが変わっても、ちゃんと動作する必要がありますから。

ASP.NET MVC は ビューとコントローラについてはフレームワークとしてサポートしていますが、モデルについては開発者が自身で設計していかないといけません。

どうしたか

検証自体の実装は省略します。DataAnnotation を使ったり、オリジナルの検証機構を実装したりしてみました。個人的には DataAnnotation がいいと思います。基本的な検証なら用意された検証属性を使うだけで実装できますし、カスタム検証属性を作れば、多様なケースに対応できます。

肝心なのは検証結果をいかにビューまで伝達するかです。私が最初に試したのは…

ModelState をモデルに渡す

最初はよくわからずにこうなりました。ModelState をビューとコントローラ、モデルまで一貫した検証結果のコンテナとして利用しました。

しかし ModelState は ASP.NET MVC の仕組みの一つなので、それをモデルに入れてしまうのはなんとも言えない気持ち悪さ、ビューやコントローラへの依存が生まれてしまいます。

検証結果のコンテナを自前で作る

次は自前で検証結果を扱うコンテナを用意しました。モデルが返してくるこの独自の検証結果のコンテナを、コントローラ側で ModelState にマップしてビューへ伝達します。

この方法は最初うまくいったように思いました。でも大きな問題が。すごく面倒です。

また、最終的には ModelState を利用するので、ModelState を意識せざるを得なくなり、最初の試みとだんだん大差なくなってしまいました。

モデルは特別なことをしない

最終的にどうなったかというと…

例外結果のコンテナの仕組みをモデルから全部排除しました。モデルで検証に失敗したら単に例外をスローするだけです。つまり、モデルでの検証はデータを守る最後の砦としてのみ機能させるということです。

その代わり、ModelBinder による検証を充実させ、モデルでの処理の際、極力検証に失敗しないように作ることにしました。ユーザの通常の操作の範囲なら、ModelBinder による検証で十分拾えると思います。

ModelBinder による検証が充実していれば、モデルでの検証が失敗するケースは、特殊なケースになります。例えば悪意ある操作などです。

そんな特殊なケースまで丁寧に検証結果を表示したりする必要はないということにしてしまいました:)

こうすることでモデルの作りがシンプルに保たれ、モデルは必要最小限の仕事に集中すればよくなり、随分すっきりしたように思います。

まとめ？

結局モデルの検証結果を伝達するのをやめるという、なんとも身も蓋もない結論になってしまいましたが、個人的にいろいろ試したところでは、これがいちばんしっくりきました。

ModelBinder は非常に優れた仕組みなので、カスタムバインダや検証属性を作って有効活用しましょう！

[L2S]EntitySet.Removeでレコードを削除する

Linq to SQL - Using EntitySet.Remove to delete records | Joe Stevens' Blog

LINQ to SQL のデザイナでそれらしい設定が全くなかったので、「もしかしてレコード削除したいときは、DeleteOnSubmit をちまちま呼ばないといけないのか、ウゲー。」とか思っていたら、ちゃんとあった。

.dbml を右クリックでXMLエディタから開いて、XMLを直接編集することで設定できた。

うーん、機能自体はあるのにデザイナに無いなんて。

Windows Live Writer

Windows Live にはこういうのもあったんですね。試しに使って投稿してみる。

無料ブログの編集はWriter - Windows Live on MSN

この記事を読んで知りました。他にも便利そうなツールがたくさん。

Scott Hanselmanの開発者とパワーユーザーのための究極のWindowsツールリスト2009