Azure と VSTS で継続的デプロイ (2017)

以前に Azure と GitHub で継続的インテグレーション
Azure と Visual Studio Online (Git) で継続的インテグレーションなどの記事を書きましたが、
情報が古くなっているため、現在の環境で改めて検証しました。

現在の Azure Web App でバージョン管理システムからの継続的デプロイ (Continuous Deployment, CD) を構成する方法としては、

  • [デプロイ オプション] を設定する
  • [継続的配信] を設定する (ただしプレビュー)

の 2 種類があり、いずれかを選択することになります。

image

いずれの方法でも、バージョン管理システムとして Visual Studio Team Services (VSTS) も GitHub もサポートしています。
この 2 つの主な違いは、

  • [デプロイ オプション] では、リポジトリ内に含められる Web アプリケーションは 1 つ。
  • [継続的配信] では、対象の .sln を指定できるため、リポジトリ内に Web アプリケーションが複数存在してもよい。
    その他にも、細かい設定ができる。

です。

 

[デプロイ オプション] を設定する方法については前回の Azure と GitHub で継続的デプロイ (2017) で書きました。
今回は Visual Studio Team Services (VSTS) の Git リポジトリに対して [継続的配信] を設定してみます。

まず VSTS の Git リポジトリに Web アプリケーションを commit/push します。
今回は例として、ASP.NET MVC Web アプリケーションとします。
リポジトリに bin フォルダーなどを含める必要はありません。

image

 

次に、Azure で Web App を作成します。

image

作成が完了したら、その Web App の [継続的配信] を構成していきます。

image

ソースとして VSTS を選択し、アカウント、リポジトリ、ブランチを選択します。

image

 

基本的な設定はこれだけです。設定完了と同時に、ビルドとデプロイが開始されます。

image

以降も、ソースコードを変更してリポジトリに commit/push するだけで、自動的にビルドとデプロイが実行されます。 
開発時には、開発用のブランチおよび Web App を利用するとよいでしょう。

image

VSTS のリポジトリの [Services] で、Azure Web App と連携していることを確認できます。

image

 

VSTS の Web 画面で、ビルド定義の表示・編集ができます。詳細の設定はここでできます。
なお、Visual Studio 上での表示・編集はできなくなっているようです。

主に使われる設定としては以下が挙げられるでしょう。

  • ビルド定義の名前の変更
  • .sln ファイルのパスの指定
  • ブランチの変更
  • 継続的デプロイか、手動デプロイか (Enable continuous integration)
  • ビルド番号の形式

image

image

image

ビルドで生成された実行ファイルは [Artifacts] で取得できます。

image

[Release] から、過去のバージョンを選択して再デプロイすることもできます。

image

 

注意点:

  • VSTS 以外の Git (GitHub など) でも同様の手順で構成できますが、
    ビルド定義を VSTS のリポジトリに保存するため、VSTS のアカウントが必要です。
  • 管理者権限を与えられた別の Azure アカウントだと、エラーが発生して [継続的配信] を設定できませんでした。

 

前回:Azure と GitHub で継続的デプロイ (2017)

参照
Build and deploy to an Azure Web App

Azure と GitHub で継続的インテグレーション (旧版)
Azure と Visual Studio Online (Git) で継続的インテグレーション (旧版)

広告

Azure と GitHub で継続的デプロイ (2017)

以前に Azure と GitHub で継続的インテグレーション
Azure と Visual Studio Online (Git) で継続的インテグレーションなどの記事を書きましたが、
情報が古くなっているため、現在の環境で改めて検証しました。

現在の Azure Web App でバージョン管理システムからの継続的デプロイ (Continuous Deployment, CD) を構成する方法としては、

  • [デプロイ オプション] を設定する
  • [継続的配信] を設定する (ただしプレビュー)

の 2 種類があり、いずれかを選択することになります。

image

いずれの方法でも、バージョン管理システムとして Visual Studio Team Services (VSTS) も GitHub もサポートしています。
この 2 つの主な違いは、

  • [デプロイ オプション] では、リポジトリ内に含められる Web アプリケーションは 1 つ。
  • [継続的配信] では、対象の .sln を指定できるため、リポジトリ内に Web アプリケーションが複数存在してもよい。
    その他にも、細かい設定ができる。

です。
Web アプリケーションが 1 つしか含まれていないリポジトリをシンプルに運用したいのであれば、[デプロイ オプション] でよいでしょう。

 

以下では GitHub のリポジトリに対して [デプロイ オプション] を設定してみます。
なお、GitHub 以外の Git (VSTS など) でも同様の手順で構成できます。
[継続的配信] については次回の Azure と VSTS で継続的デプロイ (2017) で書いています。

まず GitHub のリポジトリに Web アプリケーションを commit/push します。
今回は例として、ASP.NET MVC Web アプリケーションとします。
リポジトリに bin フォルダーなどを含める必要はありません。

image

リポジトリはパブリックでもプライベートでもかまいませんが、
自分が所有しているリポジトリでなければならないため、他の人のリポジトリであれば fork しておきます。

 

次に、Azure で Web App を作成します。

image

作成が完了したら、[デプロイ オプション] を構成します。
ソースとして GitHub を選択すると、アカウント承認の画面が現れます。
さらにリポジトリとブランチを選択します。

image

 

必要な設定はこれだけです。設定完了と同時に、ビルドとデプロイが開始されます。
[継続的配信] では数分かかるのに対して、かなり早く完了します。

image

以降も、ソースコードを変更してリポジトリに commit/push するだけで、自動的にビルドとデプロイが実行されます。
開発時には、開発用のブランチおよび Web App を利用するとよいでしょう。

image

過去のバージョンを選択して再デプロイすることもできます。

image

GitHub のリポジトリの [Settings] – [Webhooks] で、Azure Web App と連携していることを確認できます。

image

 

次回:Azure と VSTS で継続的デプロイ (2017)

参照
Azure App Service への継続的なデプロイ

Azure と GitHub で継続的インテグレーション (旧版)
Azure と Visual Studio Online (Git) で継続的インテグレーション (旧版)

カテゴリー: ALM, クラウド. タグ: , . 2 Comments »

SIR 感染症モデルのシミュレーター

// この投稿は ライフゲーム Advent Calendar 2017 の 19 日目の記事です。

2017年11月11日の稲葉寿先生還暦記念祝賀研究集会「数理人口学・数理疫学・構造化個体群モデル」で講演してきました。
そのときに発表したシミュレーション ツールを紹介します。

数理生物学で「SIR 感染症モデル」という数理モデルがあり、

S(t): 未感染者の人口
I(t): 感染者の人口
R(t): 回復者の人口

としたとき、

S’ = θR – βSI
I’ = βSI – γI
R’ = γI – θR

のような微分方程式系で表されるものを指します。ここで、各定数は

β: 感染率
γ: 回復率
θ: 免疫喪失率

を表します (このように免疫喪失を考慮する場合は SIRS ともいう)。

このモデルをもとに、感染症の伝播を視覚的に表現するセルオートマトンを WPF で作成しました。
各ファイルは GitHub にあります。

EpidemicSimulator.exe を実行し、右下のトグルスイッチを押せばシミュレーションを開始できます。
感染率などのいくつかのパラメーターは実行時にリアルタイムに変更できます。

S と I が隣り合っているとき、一定の割合で感染が発生するようになっています (したがって、数式で表した状況とは厳密には異なります)。
また、I と R は一定の割合でそれぞれ R と S に移動します。

実行前に設定するパラメーター:

  • 高さ
  • SIR の初期人口比

実行中も設定できるパラメーター:

  • 感染率
  • 回復率
  • 免疫喪失率
  • Looping Map: マップの端でループするかどうか
  • ターンの時間間隔

Epidemic Simulator

 

実装方法については技術的に目新しいところはありませんが、特徴としては以下が挙げられます。

(1) シミュレーションの演算は UI スレッドではなく、バックグラウンド スレッドで実行
(2) 各フレームで画像データを生成して、Image コントロールで表示

(1) については、重い処理を UI スレッドで実行するとアプリケーションがフリーズしてしまうため、
各フレームで非同期的にデータのスナップショットを取得しています。
技術的な説明は、以前に

で書いた通りです。

バージョン情報
.NET Framework 4.5
ReactiveProperty 3.6.0
ToggleSwitch 1.1.2

参照
稲葉寿先生還暦記念祝賀研究集会「数理人口学・数理疫学・構造化個体群モデル」

カテゴリー: ツール, 数学. タグ: . Leave a Comment »

Surface Book で Kinect v2 が認識されない

ある時の Windows Update 以降、
Surface Book に Kinect v2 (Xbox One Kinect センサー) を USB で接続しても認識されなくなりました。

Kinect Sensor is not recognized on a Surface Book によると、
「Surface USB Hub Firmware Update driver」の変更が原因であるとしています。

また、この記事には回避策が載っています。以下ではその手順を実行した様子について書いていきます。
ただし、「問題調査中」とあり、これは一時的な措置のように見えます。

 

手順

[regedit] を実行してレジストリ エディターを起動します。

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Class\{36fc9e60-c465-11cf-8056-444553540000}

に移動します。

Kinect-v2-Firmware-1

[LowerFilters] をダブルクリックします。値の編集画面が現れます。
元の値は「SurfaceUsbHubFwUpdate」です。これを削除して空文字列にします。

Kinect-v2-Firmware-2

Kinect-v2-Firmware-3

[OK] をクリックすれば完了です。

Kinect-v2-Firmware-4

すぐに認識しない場合は、PC を再起動したり Kinect v2 の電源を入れ直せば認識されるはずです。

参照
Kinect Sensor is not recognized on a Surface Book

カテゴリー: 周辺機器. タグ: , . Leave a Comment »

メソッドチェーンでアスペクト指向プログラミング

透過プロキシでアスペクト指向プログラミング (1) では、ログ出力やデータベース トランザクションなどの横断的関心事を、

public class NorthwindBusiness : MarshalByRefObject
{
    [TraceLog]
    [TransactionScope]
    public short SelectUnitsInStock()
    {
    }
}

のように、属性として記述することができました。
今回は属性を使わずに、LINQ と同様にメソッドチェーンを使って横断的関心事を記述してみます。

まず、戻り値を持つ (Func<TResult> に相当する) 処理を IProxyable<TResult> インターフェイスとして定義して、
後ろにメソッドチェーンを追加することで処理を上書きできるようにします。

これを実行すると出力は次のようになり、元の処理の前後に処理が追加されていることがわかります。

Before
Body
After

次に、戻り値を持たない (Action に相当する) 処理を表す IProxyable インターフェイスを、
IProxyable<TResult> インターフェイスの特別な場合とみなして継承させます。

あとは、ログ出力やデータベース トランザクションなどの横断的関心事を拡張メソッドとして作成すれば完成です。

実行結果です:

ProxyableConsole

 

使い道としては、

  • .NET で透過プロキシを使いたくないとき (処理速度を上げたい、など)
  • .NET の属性のような仕組みを持たない別のプラットフォーム

などの場合が考えられるでしょう。

前回:透過プロキシでアスペクト指向プログラミング (2)

作成したサンプル
ProxyableConsole (GitHub)

バージョン情報
C# 7.0
.NET Framework 4.5

参照
アスペクト指向プログラミング

カテゴリー: .NET Framework, データベース. タグ: . 1 Comment »

透過プロキシでアスペクト指向プログラミング (2)

前回の記事で、NorthwindBusiness クラスの透過プロキシを生成するときに、

var nw = CrossCuttingProxy.CreateProxy<NorthwindBusiness>();

というコードを記述していましたが、
MarshalByRefObject の代わりに ContextBoundObject クラスを継承させると、通常のコンストラクターを利用することができます。
ただし、クラスに属性を付ける必要があります。
次のように実装します。

以上で、

var nw = new NorthwindBusiness();

と記述できるようになりました。
なお、上記のコードには現れていませんが、
コンストラクターが呼び出されたときに、CrossCuttingProxy クラスの Invoke メソッドが呼び出されます。

 

前回:透過プロキシでアスペクト指向プログラミング (1)
次回:メソッドチェーンでアスペクト指向プログラミング

作成したサンプル
CrossCuttingConsole (GitHub)

バージョン情報
C# 7.0
.NET Framework 4.5

参照
RealProxy クラス
アスペクト指向プログラミング (Wikipedia)

透過プロキシでアスペクト指向プログラミング (1)

前回のインターフェイスに対する透過プロキシでは、RealProxy クラスを利用してインターフェイスに対する透過プロキシを生成し、
その実装クラスが存在していなくてもメソッドに処理を割り当てることができました。

改めて、透過プロキシ (transparent proxy) の主な特徴を整理すると次のようになります。

  • 対象となる型は、MarshalByRefObject を継承したクラス、またはインターフェイス
  • 各メンバーが呼び出されたときの挙動を上書きできる

今回は MarshalByRefObject を継承したクラスの既存の処理を透過プロキシで拡張して、
アスペクト指向プログラミング (AOP) を実践してみます。

一般的にアプリケーション設計においては、
ログ出力やデータベース トランザクションなど、いろいろなビジネス ロジックに共通する横断的関心事があります。
例えばデータベース トランザクションであれば、以前にファントム リードとその解決方法などで書いている通り、
ビジネス ロジックごとに TransactionScope に関する同じようなコードを繰り返し記述することになります。
この部分をアスペクト (側面) として分離し、属性として記述できるようにすることで再利用性を高めることを目指します。

まず次のコードで示す通り、RealProxy を継承した CrossCuttingProxy クラスと、アスペクトを表す属性を定義します。

ログ出力を表す TraceLogAttribute クラスとデータベース トランザクションを表す TransactionScopeAttribute クラスを用意し、
既存の処理の前後に割り込むようにしてそれぞれの処理を追加しています。

以上のようにすれば、ビジネス ロジックを次のように記述するだけで済むようになります。

実行結果です。ログが出力されています:

CrossCuttingConsole

 

前回:インターフェイスに対する透過プロキシ
次回:透過プロキシでアスペクト指向プログラミング (2)

作成したサンプル
CrossCuttingConsole (GitHub)

バージョン情報
C# 7.0
.NET Framework 4.5

参照
RealProxy クラス
アスペクト指向プログラミング (Wikipedia)