読者です 読者をやめる 読者になる 読者になる

kkamegawa's weblog

Visual Studio,TFS,ALM関係のことについていろいろと書いていきます。Google Analyticsで解析を行っています

Insider Preview 14936でBoWが16.04へ更新

BoW Linux Windows10

今日Windows 10 Insider Previewが14936に更新されました。

blogs.windows.com

Bash on Ubuntu on Windowsも16.04に対応したそうですが、BoWの中身を自動更新してくれないので、do-release-upgradeで更新します。

サードパーティーのリポジトリは無効にされているそうなので、software-propertiesであとよろ、ということだそうですね(そりゃそうだ)。ぼちぼち更新します。結構時間がかかるようなので、時間に余裕があるときにやりましょう。PPA設定していたの、gitと.NET Core位だったかな…。

(追記) Bash on WindowsでnginxなどのIPv6をバインドしているソフトが動かないというバグが直っているそうです。

github.com

ASP.NET Coreもこれが原因で動かなかったので、直っているかな。

TFS "15" RC2インストール

TFS

はじめに

TFS "15" RC2が公開されました。今回から日本語版が提供されています。まだインストーラーに一部英語が残っていますが、報告しているので正式版までには直るでしょう。

www.visualstudio.com

go-liveライセンスなので、本番に入れてもサポートが受けられます。今回からバックアップデータを使って、試験環境に入れるという機能がサポートされました。今までもできたのですが、異なるマシンに復元する手順は結構大変だったので、こういう機能があるとうれしいですね。

事前準備

今回からコード検索がサポートされていますが、検索にはElastic Searchを使っているので、検索機能を入れる場合、Java VMが必要になります。Java 8を入れておきましょう。Elastic Searchそのものの設定はTFSのインストール時に行われるので、気にする必要はありません。

アップグレード開始

実際にアップグレードしてみましょう。ちなみにTFS 2015 Update3からのアップグレードを行っています。サポートされているのはTFS 2012からだそうです。

f:id:kkamegawa:20160927215023p:plain

f:id:kkamegawa:20160927215024p:plain

アップグレードか新規かの選択です。

f:id:kkamegawa:20160927215025p:plain

アップグレード対象のデータベースを選択します。必ずバックアップを取ってからやりましょう。

アップグレードテスト

f:id:kkamegawa:20160927215026p:plain

ここが従来と違います。運用環境のアップグレードか、バックアップデータを使用して、異なるマシンに入れてみるアップグレードテストかを選択できます。ここではアップグレードでやってみます。

f:id:kkamegawa:20160927215027p:plain

App Tierの設定

f:id:kkamegawa:20160927215028p:plain

SSHを有効にしています。必要なければ特に有効にする必要はありません。仮にWindows 10 Anniversary Updateにインストールして、Bash On Windowsを有効にしている場合、SSHのポートが重複するので気を付けてください。

f:id:kkamegawa:20160927215029p:plain

Webサイトの設定でhttpsなどの設定を行います。TFS 15ではhttps推奨なので設定します。ちなみにPAT(Personal Access Token)アクセスするには、httpsを構成していないと使えません。PATでのアクセスが必要になるシナリオとしてパッと思いつくものはこのくらいでしょうか。

  • Windows以外のビルドエージェントを使う
  • Windowsでもワークグループ環境などでいちいち同じアカウントを作りたくない
  • WebHookなどでアクセスする

f:id:kkamegawa:20160927215030p:plain

f:id:kkamegawa:20160927215032p:plain

Active Directoryを使っている場合はエンタープライズCAを構築しておくと楽です。ワークグループ環境などで安全に渡せる場合はIISの自己証明書作成機能を使って作りましょう。

作成し、自己署名入りの証明書をエクスポートします。

検索機能

f:id:kkamegawa:20160927215031p:plain

Elastic Search関係の設定です。アカウントの設定および、どこにサービスのインストールを行うかという程度です。

レポート機能

f:id:kkamegawa:20160927215033p:plain

f:id:kkamegawa:20160927215034p:plain

f:id:kkamegawa:20160927215035p:plain

f:id:kkamegawa:20160927215036p:plain

この辺りまでは以前のバージョンと変わりません。

アップグレード実行

f:id:kkamegawa:20160927215037p:plain

f:id:kkamegawa:20160927215038p:plain

無事成功です。お疲れさまでした。今回は処理時間なども表示されます。

コード検索

ちょっとやってみます。

f:id:kkamegawa:20160928063250p:plain

method:MainとかやればMainという名前のメソッドが検索できますね!

Visual Studio Team Services 2016/9/21の更新

ALM DevOps Git ReleaseManagement SonarQube VSTS VSO

VSTSの9/21分のリリースノート翻訳を行いました。オリジナルはこちらから読んで下さい。

www.visualstudio.com

今回からリリースノートを載せているサイトのプラットフォームが変わったんですかね。URLが軒並み変わっていて、上記のように埋め込みタイプが使えるようになりました。

今回は複雑な文章もなく、意外と楽に翻訳できて助かりました(^^;。Gitのリポジトリをインポートできるようになったのは嬉しいかもしれません。いや、クライアントでもできるのですが、でかいリポジトリを一度全部ダウンロードして、pushというのは大変ですしね。

Xcode関係のところは知らないので、間違っていたら教えてください。ではまた三週間後。

translate to Japanese toVSTS release notes from ht ...

.NET CoreアプリをVSTSで継続的デリバリー(Windows/Linux編)

はじめに

継続的インテグレーションができたので、今度は継続的デリバリーを構築します。WindowsとLinuxそれぞれ環境を設定します。

ビルド成果物を関連付け

f:id:kkamegawa:20160921213300p:plain

リリースを行うには何らかの成果物(Artifacts)と関連付ける必要があります。一般的にはVSTSのビルド定義を関連付けると、自動的にビルド成果物をリリース対象として扱うことができます。Primaryに設定した成果物が生成されたタイミングでリリースを自動的に実行することもできます(Triggerで設定します)。

リリース環境を設定

リリース環境を構築します。リリース先サーバーの台数ではなく、リリース先がどういう環境になっているか、ということでわけます。わかりやすいのは検証環境(Staging)とか本番環境(Production)ですね。
環境ごとに承認者を設定することもできます。検証環境には承認なしでリリースしていいけど、本番には承認が入るから止めるとかそういったことができます。既定は承認なしでそのままリリースが行われます。
f:id:kkamegawa:20160921213255p:plain

上記のキャプチャでは"Staging","Production","Linux Production"がそれぞれリリース環境となります。

デプロイスクリプト

注意事項として、デプロイ用のスクリプトはソースリポジトリに含まれ、なんらかの成果物に含まれている必要があります。
トラブルが起きる例といえば、CI/CDを設定している環境に、スクリプトを実行するためにはリポジトリにコミットが必要です。しかし、そのコミットのためだけに、CI/CDが自動的に実行されてしまいます。
特定の成果物にしかデプロイ用のスクリプトは依存しないので、同じリポジトリでバージョン管理するというのもわからないではないです。
こういうのはリリース用のスクリプトリポジトリとかで別管理したほうがいいかもしれません。

Azure App Serviceを停止/起動

f:id:kkamegawa:20160921213255p:plain

フル.NETのときは大丈夫だった印象しかないのですが、.NET CoreではAzure App Serviceにデプロイするとき、アセンブリのdllが使用中だといって更新できない状況になりました。

2016-09-16T06:13:03.3986858Z WebSite 'dotnetconfosaka(Staging)' found.
2016-09-16T06:13:25.7633522Z ##[error]Web Deploy cannot modify the file 'CoreWebApp.dll' on the destination because it is locked by an external process. In order to allow the publish operation to succeed, you may need to either restart your application to release the lock, or use the AppOffline rule handler for .Net applications on your next publish attempt. Learn more at: http://go.microsoft.com/fwlink/?LinkId=221672#ERROR_FILE_IN_USE.

よって、テンプレートそのままではなく、一度App Serviceを停止するタスクを先頭に用意します。

param([string]$startOrStop, [string]$AppName , [string]$Slot)
if($startOrStop -eq "start"){
  Start-AzureWebsite -name $AppName -Slot $Slot 
}else{
  Stop-AzureWebsite -name $AppName -Slot $Slot 
}

サンプルそのままですが。こんな感じでデプロイ前に停止、デプロイ後に起動を行うスクリプトをソースコードリポジトリに登録しておいて使用します

Azure App Serviceへのデプロイ

App Serviceを停止したらデプロイです。デプロイには事前にサブスクリプションを登録しておきます。ClassicとResource Managerがありますが、Resource ManagerではSPNを作るなどちょっとめんどうです。VSTSを組織アカウントで運用している場合、SPNの登録は省略できます。詳しくはこちらをどうぞ。

www.visualstudio.com

f:id:kkamegawa:20160921213256p:plain

ここではStagingへのデプロイを行うので、Stagingスロットを指定しています。デプロイそのものはかわりません。

ProductionスロットでAzure App Serviceを入れ替える

ステージングとプロダクションを入れ替えるPowerShellスクリプトをリポジトリに登録しておきます。

param (
   [string] $AzureWebsiteName,
   [string] $From,
   [string] $To
)
Switch-AzureWebsiteSlot -Name $AzureWebsiteName -Slot1 $From -Slot2 $To -Force -Verbose

f:id:kkamegawa:20160922072133p:plain

App Serviceの名前、From、Toを指定して、スロットを切り替えます。

Linuxへのデプロイ

Linuxにしかないツールを使う場合、Linuxでビルドエージェントが実行されている必要があります。

sshでのコピー

今回はLinuxも同じリリースでデプロイしています。sshで成果物をコピーします。

f:id:kkamegawa:20160921213258p:plain

実行権限付与

コピーしただけでは実行権限がないので、sshで特定の実行権限を追加して、NuGetパッケージの復元、サービスの実行を行います。

f:id:kkamegawa:20160921213259p:plain

フォルダに実行権限付与して、NuGetパッケージの復元、再起動を行います。

#!/bin/sh
cd /var/www/
chmod +x corewebapp
cd corewebapp
supervisorctl stop corewebapp:
/usr/bin/dotnet restore
supervisorctl start corewebapp:

実行終了

リリースが成功すればこのように、VSTSのポータルで確認できます。Logsで詳細なログも表示されます。

f:id:kkamegawa:20160922072134p:plain

まとめ

LinuxとWindowsそれぞれ異なる方法を使いますが、リリーストリガーはReleaseという機能で統一的に扱うことができるので、比較的お手軽にCI/CDを構築することができるので、よければ使ってみてください。

.NET CoreアプリをVSTSで継続的インテグレーションする(Linux版)

.NET ALM ASP.NET DevOps Linux VSO VSTS

Linuxビルドエージェントを構成する

.NET - Powerful Open Source Development

Linuxのディストリビューションごとに手順が違うので、注意してください。私はUbuntu Server 16.04 LTSでやっています。

ビルド定義を作る

Windows版と同じ感じで作ります。

f:id:kkamegawa:20160919120826p:plain

違うのはZipパッケージの作成と、リリース用PowerShellスクリプトの代わりにシェルスクリプトが用意されていることですね。タスクはほとんどUtilityにある、Shell Scriptを使用します。

シェルスクリプトとタスクの単位

dotnet restore/buildのように連続するタスクは一つのシェルスクリプトで実施してもかまわないのでしょうが、個人的にはビルドタスク単位で別にしたほうがわかりやすいかと思います。

作成したシェルスクリプトはSolutionフォルダ内に適当なシェル用のフォルダを作って入れておくといいでしょう。

NuGetパッケージのリストア

NuGetパッケージのリストアに必要なシェルはこのようになります。

#!/bin/sh  
/usr/bin/dotnet restore  

パッケージリストア用のシェルスクリプトはテストプロジェクトでも使用できるので、使いまわしてください。

プロジェクトのビルド

ビルドに必要な最低限のシェルはこのようになります。

#!/bin/sh
/usr/bin/dotnet build -c $BUILDCONFIGURATION

$BUILDCONFIGURATIONはVariablesに定義された値です。Variablesでは大文字小文字があるように見えますが、bashではこの定義済みの値は全て大文字として定義されています。

f:id:kkamegawa:20160919141406p:plain

テストプロジェクトの実行

テストプロジェクトにあるテストを実行するにはこのようなスクリプトを実行します。テストプロジェクトを実行する前に必ずNuGetパッケージのリストアタスクをテストプロジェクトのフォルダで実行してください。

#!/bin/sh
/usr/bin/dotnet test -xml Test-Result1.xml

Windowsのビルド定義のところでも書きましたが、-xmlオプションでXMLファイルにテスト結果を出力します。複数のテストプロジェクトの結果をマージする場合、この引数はシェルスクリプトの引数として外出できるようにしてください。

パッケージを出力する

特定のプロジェクトをWebサーバーへデプロイするための最低限のスクリプトはこのようになります。

#!/bin/sh
/usr/bin/dotnet publish src/{プロジェクト名} --configuration $BUILDCONFIGURATION --output $PUBLISHOUTPUT  --framework $NETCOREVERSION

$PUBLISHOUTPUTは出力先フォルダを定義した値です。これもWindows版と同様に、システムに.NET Coreがインストールされているという前提のパッケージです。

Windows版にも書きましたが、必ず--configurationでreleaseと指定して、Release版をデプロイしてください。

場合によってはここで一気にデプロイまでやってもいいのですが、別にしています。

まとめ

Windows版と同様ですが、タスクごとにシェルスクリプト作らないといけないのが少し面倒かもしれませんね。外部にビルドサーバーが必要になるし、どうしてもLinuxでなくてはならないビルドを行う以外はHostedエージェントを使ったほうがいいように思います。
次はリリースについて紹介します。

.NET CoreアプリをVSTSで継続的インテグレーションする(Windows版)

.NET ALM ASP.NET Azure DevOps Linux VSO VSTS VisualStudio

はじめに

昨日dotnetConf関西で行ったセッション資料ではCI/CDの細かいやり方はのせていませんでしたので、ブログで詳細の解説を行います。 CIそのものはメニューのBuild & Releaseから構築します。この記事では新しいUIで説明していますが、以前のUIでもあまり関係ありません。
長くなったので、Linux版は別にします。

VSTSとビルドエージェント

VSTSには内蔵のビルドエージェント(Hosted Agent)があります。Hostedは今のところWindowsのエージェントのみになっているので、LinuxやMac環境でビルドする場合、独自のビルドサーバーを用意する必要があります。
ビルドエージェントは一台までであれば無料で接続できます。httpsのoutboundだけ通信できていればいいので、Firewallがある環境でも大体大丈夫です。

有料($15/月)支払って、一つのプールに二台以上のビルドエージェントを運用すると、並列でビルドができるようになります。並列可能ということ以外にも、エージェントを占有するので、占有しているエージェントではリポジトリのクローンが頻発しなくなるはずです。
原則1台1エージェントですが、登録するときにエージェントの名前を変えれば、一台のサーバーに複数のエージェントが登録できます。例えば、TFSとVSTSそれぞれ登録するとかもできます。サーバーの性能次第ですが、複数のVSTS/TFSを使っているときは試してみてください。

エージェントの対応OS

  • .NET CoreがサポートするWindows
  • Ubuntu 14.04/16.04(サービスとして動かす場合は16.04必須)
  • Red Hat Enterprise Linux 7.x
  • OS X 10.10/10.11

TFS 2015に接続する場合、WindowsではTFSに付属しているエージェントを使ってください。TFS "15"ではPAT(Personal Access Token)をサポートするので、.NET Core版のエージェントが使用可能になります。
VSTSのエージェントはソースも公開されています。

github.com

Windows(Hosted)で.NET Coreアプリをビルドする

では、実際にビルド定義を作ってみましょう。ASP.NET Core MVCアプリケーションを作ってコミットしておきます。
Visual Studioのテンプレートを使ってもいいですが、大部分を削除することになります。

NuGetの復元タスクを追加

f:id:kkamegawa:20160919120827p:plain

Add build stepからUtilityにあるCommand Lineを追加します。

NuGetパッケージを復元する
Tool: "c:\Program Files\dotnet\dotnet.exe"
Arguments : restore Working Folder : Project.jsonのあるフォルダ

ビルドタスク

ビルド用のCommand LineをAdd build stepで追加します。

Tool: "c:\Program Files\dotnet\dotnet.exe"
Arguments : build -c $(BuildConfiguration) Working Folder : Project.jsonのあるフォルダ

※:BuildConfigrationはVariablesでreleaseと作っておいてください(Visual Studioのテンプレートから作った場合は作られています)

f:id:kkamegawa:20160919141406p:plain

テストプロジェクトのNuGetパッケージを復元する

テストプロジェクトのNuGetパッケージ復元のCommand LineをAdd build stepで追加します。

Tool: "c:\Program Files\dotnet\dotnet.exe"
Arguments : restore Working Folder : テストプロジェクトのProject.jsonがあるフォルダ

テストの実行

テスト実行用のCommand LineをAdd build stepで追加します。

Tool: "c:\Program Files\dotnet\dotnet.exe"
Arguments : test -xml TestResult.xml Working Folder : テストプロジェクトのProject.jsonがあるフォルダ

Visual Studioでビルドする場合と異なり、プロジェクト単位でdotnet restoreを実行する必要があるので気を付けてください。

-xml にはテスト結果を出力するxmlファイルを指定します。テストプロジェクトごとに異なる名前にしてください。後で集計することができなくなります。

dotnetコマンドはフルパスで指定しなくても実行できますが、ビルド時に警告が出るので、フルパスを指定するほうが無難です。

テスト結果をVSTSにアップロード

f:id:kkamegawa:20160919120828p:plain

Add build stepで"Publish Tests Results"タスクを追加して、ビルド結果をVSTSにアップロードします。VSTEST以外にもXUnit,NUnit,JUnit(Javaなので.NET Coreには関係ないですが)などに対応しています。

f:id:kkamegawa:20160919142327p:plain

テスト結果をVSTSにアップロードすると、このようにテスト結果の品質を追跡することができます。

LnuxもしくはOS/Xでビルドする場合、出力するXMLファイル名の大文字小文字に気を付けてください。

コードカバレッジも取れるはず…Visual Studioでは取れていますが、VSTSでは集計されていません。これは少し調査します。

パッケージの出力

パッケージ出力用のCommand LineをAdd build stepで追加します。

f:id:kkamegawa:20160919120829p:plain

出力パッケージを作ります。具体的にはproject.jsonで定義されているpublishの動作が実行されます。

docs.microsoft.com

Tool: "c:\Program Files\dotnet\dotnet.exe"
Arguments : publish src/{プロジェクト名} --configuration $(BuildConfiguration) --output $(PublishOutput) --framework $(NETCoreVersion)

注意点として、publishコマンドはデフォルトでデバッグ版を出力しています。--configurationで明示的にrelease版(ここではvariablesで指定しています)を指定してください。Azureではデバッグ版実行できない(エラーになる)はずなのですが、なぜかデバッグ版をデプロイしてもApp Serviceで動いてしまってます。長い間気づきませんでした。

Framework Runtimeは組み込むか、システムインストールを使用するかはご自由に。今回はシステム組み込みのランタイムを使用する前提でやっています。

f:id:kkamegawa:20160919142328p:plain

bin\$(BuildConfiguration)\ にあるアプリケーションの実体をコピーするタスクです。このタスクは非.NET CoreのASP.NET前提のタスクのようで、フォルダ構成をそのままコピーしてくれません。

IIS(Azure App Service)にデプロイする場合、これで問題ないのですが、Linuxにデプロイするとこのタスクでは実行時に「\bin\$(BuildConfiguration)\netcoreapp1.0\モジュール名」が存在しないというエラーになります。

特別にタスクを作るか、project.jsonのpublishOptionsにbin/releaseを含めるしかないように思います。今回はproject.jsonに入れています。あと、各種jsonファイルも入っていない場合、Linux(たぶんOS/Xも)実行失敗するので、jsonファイルを忘れないようにpublishOptionsに入れましょう。

  "publishOptions": {
    "include": [
      "wwwroot",
      "Views",
      "Areas/**/Views",
      "appsettings.json",
      "project.json",
      "bin/release",
      "web.config"
    ]
  }

リリース作業用PowerShellスクリプト追加

f:id:kkamegawa:20160919120830p:plain

ここはApp ServiceにリリースするためのPowerShellスクリプトをリリース成果物としてコピーするタスクですビルド時にデプロイするなら不要です。

WebDeploy用zipファイル作成

f:id:kkamegawa:20160919120831p:plain

IIS(Azure App Service)にwebdeployでデプロイする場合、zipパッケージを作っておく必要があります。webdeployを使わない場合は不要です。

VSTSにリリース成果物を登録

f:id:kkamegawa:20160919120832p:plain

最後に成果物をVSTSにコピーします。特定のファイル共有にコピーするか、VSTSに保存します。ファイル共有はUNCでVSTSもしくはビルドエージェントからアクセスできる必要があります。

UNCで共有フォルダにコピーする場合、独自のビルドエージェントからになるでしょうね。

.NET Coreでの継続的インテグレーションと継続的デリバリー資料公開

ALM ReleaseManagement VSO VSTS DevOps

connpass.com

このセッション資料を公開しました。連休中にもかかわらず、お越しいただいた皆様ありがとうございます。

(英語版を作ってみました)

.NET Coreのプロジェクト構造については理解していたつもりだったんですが、CI/CDを作るにあたりやってみたらいろいろはまりました。詳細はぼちぼち書いていきます。

(追記)
もう少し詳細な手順っぽいものを別記事として書き起こしました。

kkamegawa.hatenablog.jp

kkamegawa.hatenablog.jp

kkamegawa.hatenablog.jp