VSTS/TFSの継続的インテグレーションとデータベース接続と単体テスト

データベース接続を動的に作る

最近、id:ishikawa-tatsuya さんのLambdicSQLというSQLをラムダでかいちゃおう、というOSSをid:odashinsukeさんと一緒にやってます。いろいろなデータベースに対応する(予定)ですが、とりあえず三人のスキルセットがそろっているSQL Serverを最初にやっています。

github.com

今までは個人でビルドしていましたが、CIやってみようかということで、個人的にVSTSのビルド定義を作ってみました。テストには当然SQL Serverを使うのですが、個人でやるときはそれぞれのSQL Server(LocalDBでもいいはずです)を使えばいいものの、CIとなるとちょっと困る。

接続情報はほかの人には教えたくないこともあり、LambdicSQLではProjectフォルダの下にdb.txtというファイルを作って、接続情報をそのまま平文で書いておくことになっています(もちろんgitignoreには定義済み)。

ではCIのときはどうするか？ということですが、こんな感じでやってます。

まず、普通にVisual Studioのビルドテンプレートを作ります。次にPowerShellのタスクでインラインスクリプト(inline script)を追加します。new-item(別に要らないけど)とadd-contentコマンドレットで、db.txtにSQL Databaseへの接続情報を書いています。

接続情報はそのまま隠すので、variableに独自で文字列を定義して、そのまま書いています。ほんとはタイムアウトとか変更できるように、サーバー名とユーザーID, パスワードだけ隠せばいいんですが。

テストを選別する

とはいえ、毎回すべてのテストが必要なわけでもありません。特にLambdicSQLにはデータベースをcreate/dropするテストもあります。SQL Databaseを作成するたびに2.33円(デフォルトのStandard S0の場合)かかるのはお財布にも優しくありません。

そこでこんな風に、TestCategoryやPriority属性をつけておきます。

テストエクスプローラーで「特徴」を選択するとこんな風にPriority1(CreateDrop以外)とPriority2(CreateDropDatabase)が区別できます。

ビルドのTest AssembliesタスクのTest filter criteriaにPriority=1と指定すると、Priority属性が1のテストだけ実行されます。

VSTSでASP.NET CoreアプリのCI/CDを行う

はじめに

以前、VSTSとAzure App ServivesのCI/CDの話を書きました。

kkamegawa.hatenablog.jp

今はちょっとやり方が変わっているので、改めて紹介します。VSTSで書いていますが、基本はJenkinsやTFSでも変わりありません。

Build定義作成

VSTSのビルドテンプレートからVisual StudioもしくはASP.NET(Preview)を選んでください。

dotnet restoreコマンドでもいいのですが、せっかくテンプレートに入っているNugetタスクを使います。重要なポイントとして、必ず、3.5以上を選択してください。ここでは4.0にしています。

NuGet 4.0はHosted VS2017であれば入っています。

Visual Studioタスクで使用するVisual Studioを必ずVisual Studio 2017にします。

Azure App Serviceへのデプロイにwebdeployを使うので、dotnet publishコマンドを使用します。引数に以下の値を指定します。

publish -c $(BuildConfiguration) -o $(Build.ArtifactStagingDirectory)

これで、ビルド構成(Release, Debugなど)でビルドした結果を -o で指定された出力先にコピーします。ArtifactStagingDirectoryでエージェントの中間生成領域です。

WebDeployはzipファイルなので、ArtifactStagingDirectoryに出力した内容をzipファイルに圧縮します。

生成されたzipファイルをリリース機能でデプロイするための領域にコピーします。

Optionsの中にあるAgentsで必ずHosted VS2017を選んでください。これで準備完了です。

Release機能を使う

リリース定義を作成し、App Serviceへのリリース用の環境を作ります。ここではJapan Westを作りました。

注意点として、Stagingスロットを作っていない場合、一度App Serviceをstopで止めてから入れ替えしないといけないようです。確かこれはASP.NET Coreのissueにも挙がっていた気がします。

止めて、デプロイしてから再度startタスクを実行します。容量にもよりますが、それなりに時間がかかるので、Staging作ってswapさせたほうがいいように思います。

成果物の受け渡しに関しては、以前の記事などを参照してください。

Visual Studio Team Services 2017/4/19の更新

VSTSの4/19のSprint 116(のはず)のリリースノートの参考訳を作ってみました。オリジナルはこちらから読んでください。

www.visualstudio.com

Gitのコミットグラフ、node.jsの複数バージョンの検証、ログの強化、iOS/Google Playへのリリース機能強化、拡張機能をリリースしている人にはダッシュボードの強化となかなか便利そうなものがそろっています。Gitのコミットグラフは私のテナントにも来ていたので、使ってみましたが、なかなかみやすくなっています。

ではまた三週間後。

translate to Japanese to VSTS release notes from h …

VSTS/TFSで並列リリースを行う

www.visualstudio.com

VSTSにはビルドとリリース機能があり、それぞれ継続的インテグレーションと継続的デリバリーを支援します。これらにはMSが提供するエージェント(Hosted Agent)と自前で用意するエージェント(Private Agent)の二種類があります。

エージェントはそれぞれキューと呼ばれる単位で実行が制御されます。一つのキューに対して一つのジョブしか投入できません。

www.visualstudio.com

このページ内の図がわかりやすいですかね。そして同時に投入できるキューはライセンスで制限されています。Build and ReleaseのResource limitsで確認できます。

初期状態では一つのパイプラインのみ使用できます。追加する場合、Marketplaceで購入します(Changeをクリック)。Marketplaceで購入できますが、MSDNの場合、サブスクリプションの上限解除を設定しないと購入できないので、注意してください。請求はAzureにまとめられます。

Office 365やAzureを組織で導入していて、既存のVSTSのサブスクリプションの支払いをOffice 365の組織アカウントに変更したいという場合、やや大変な手順で変更しないといけないので、注意してください。

www.visualstudio.com

パイプラインが2以上になると並列デプロイができるようになりますので、ここではVSTSが提供しているHosted/Hosted VS2017/Hosted Linuxを使ってやってみましょう。まず、Azure Web Appを複数のリージョンに作成しておきます。エージェントを切り替えるには"Run on agent"をクリックします(ここちょっとわかりづらい)。

Japan EastへのデプロイにはHotedを選択します。

Japan WestへのデプロイにはHosted VS2017を選択しています。

Create Releaseを実行すると並列でのリリースが開始されます(IN PROGRESSになってます)。

終わるとこんな感じ。一つFAILEDになってますが、それはHosted Linuxエージェント使ったからです(.NET Coreアプリなんでできると思ったけど甘かった)。

ちなみにオンプレミスのTFSでも(リリースのUIはちょっと違いますが)大体同じです。こちらはVisual Studio Enterprise保有者の数および、VSTSと同様にMarketplaceで購入した数が上限になります。

…というデモをこの前のGlobal Azure Bootcamp @ Kansaiでやりたかったんです(時間切れ)。