kkamegawa's weblog

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

.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を構築することができるので、よければ使ってみてください。