Hosted VS2017エージェントを使ってXamarinプロジェクトを継続的インテグレーションする

@kkamegawa @xin9le Xamarin でC# 7.0な場合は、どうすればいいですか？ Hosted VS2017には、Xamarin入ってなさそうですし… https://t.co/SAhmUcoEly

— くぅ@ (@Fumiya_Kume) 2017年4月10日

追加でこういう質問を受けたので、調べてみました。結論から言えばできます。もちろん、C# 7の機能を使っていても、対応するNuGetパッケージを入れていれば大丈夫です(一緒に生成されるライブラリプロジェクトに追加して確認)。

一つだけ注意点として、NuGet Restoreタスクで使用するNuGetを明示的に3.5以上にしてください。ここでは4.0を指定していますが、Hosted VS2017であれば入っているので、大丈夫です。

テンプレートから作っただけのXamarin.Formsアプリですが、こんな風にビルドできます。どうも"Visual Studio 2017"のHosted Agentなので、元からXamarinをはじめ、VS 2017に入っている機能は全部入っているようです。

もう一つ、直接の問題ではありませんが、どうもHosted VS2017 AgentにはGit LFSが入っていないようです。フィードバックしていますので、そのうち治ると思います。

(2017/4/22更新)
4/19にVSTSの更新が入ったので、確認してみたところ、Hosted VS2017にGit LFS入ったようです。正しくビルドできました。

C# 7.0のプロジェクトをVSTSで継続的インテグレーションする

前振り

Visual Studio Team Services って C# 7 のビルドに対応してないの？ #もしや

— じんぐる (@xin9le) 2017年4月10日

という話があったので、ちょっと書いてみます。

C# 7.0プロジェクトを作る

こんな風にC# 7.0の新機能であるタプルを書いてみます。

引用:ufcpp.net

もちろん素のVS2017ではエラーになるので、NuGetでValueTupleを追加します。

ビルド定義作成

VSTSにプッシュしたら、VSTSのビルド定義を作ります。注意点は二つ。

• Hosted AgentにVS2017を選ぶ
• Visual Studio 2017を選択する。

Visual Studio 2017を選びます。

OptionsにあるエージェントからHosted VS2017を選びます。

ビルドしてみる

Hosted VS 2017では成功します。

普通のHosted Agentを選択すると失敗します。ちょっと前までVS2017というHosted Agentがなかったのですが、Side by Sideで動かすより、VS2017はしばしば更新されるから別にしたんでしょうかね。

Visual Studio Team Servicesに接続して開発する(6日目)

ようやく今日からVisual Studioをつないで開発を行います。

Gitリポジトリ

まず、VSTSにGitリポジトリを作成してからVisual Studioで接続します。

初期化

最初はこのような画面が表示されます。既存のローカルリポジトリがあればそれをpushしてもいいですが、最初にVSTSで作ってからクライアントにcloneすれば.gitignoreの手間が省けます。

一番下にあるor initialize with a README or gitignoreにあるinitializeをクリックすれば指定したgitignore形式で作ります。

注意点として、C#やVB.NETという設定はなく、Visual Studioになっています。

cloneするためのツールも多く対応しています。.NET開発以外にもPhpStormやRubyMineとかにも対応しています。

(あまりないかもしれませんが)GitHubなどの外部リポジトリから引っ越すこともできます。Requires authorizationにチェックすると、非公開な認証が必要なリポジトリもインポートできます。

VSTS側で初期化した直後の状態です。.gitigonoreなどがあるので、このままクローンしてください。

リポジトリのメニューを開いて、リポジトリ名のそばにある☆をクリックすると、該当リポジトリがお気に入りとして扱われ、アクセスしやすくなります。ほかの人が作ったリポジトリに素早くアクセスする場合に使ってください。

一つのチームプロジェクトには複数(上限は非公表)のGitリポジトリを作ることができます。ビルドツールチェインはリポジトリ単位になるので、ある程度は分割したほうが便利でしょう。この辺はほかのGitサービスと考え方は変わらないはずです。

Gitセキュリティ設定

歯車アイコンから、Securityハブを使用して、チームプロジェクトにアクセスできるユーザーもしくはグループを設定します。コードの編集権を付けるにはContributorsグループに追加します。

チームプロジェクト内のリポジトリごとに設定することもできます。

特定のブランチ(通常masterやリリース用のブランチ)にむやみやたらにpushされて、ビルドが通らなくなるというのはよくあることです。

そのような事故を防ぐためにブランチ単位でブランチポリシーという機能を使って、レビューやCIおよび、テストが通っていないコミットを拒否することができます。

まだビルドがないので、上記の画面ではビルドの指定ができていません(^^;。Require a new build if older than xx hoursというのは、Gitでは細かい単位でコミットを行うこともあります。

単なるtypoやCSSの色修正でビルドやテストを全部やっていたら時間がいくらあっても足りません。そこで、直近xx時間以内のビルドは許容する、という指定です。開発が活発になって、しょっちゅうコミットするような状態になったら検討したほうがいいでしょう。

ブランチポリシーでレビュワーの指定ができます。この人(たち)がレビューしないとマージが行われません。

ブランチの…をクリックすると、既定ブランチにするか、ブランチを誤って削除できないようにします。devとかpull request作った後も残っていてほしいブランチは指定するといいでしょう。

ブランチと作業項目を関連付ける

ブランチはfeature,Backlog, Taskのいずれでも作成できます。機能レベルであれば、Backlogあたりで作るのがいいかもしれません。この辺りはいろいろ試行錯誤してルールを作ってみてください。タスクやissue単位でブランチを作るのもいいでしょう。

ブランチ名は / で区切ると階層になります。ここでは「チーム/backlog/id」というルールで切ってみました。こうするとブランチ名が何に関連づいているかわかりやすいでしょう。

タスクに着手したので、タスクをIn Progressに変更します。

Visual StudioからVSTSへ接続する

チームエクスプローラーから「接続の管理」を使用して「チームプロジェクトへ接続」をクリックします。なお、VSTSがサポートするVisual StudioはVS 2008 SP1 GDR1を適用したもの以降だそうです。

www.visualstudio.com

とはいえ、CIツールとして使う場合、Visual Studio 2013以降じゃないと、新しいビルドツールがサポートしていないとかいろいろ困ると思います。さらに、チームプロジェクトのリポジトリをGitで作った場合、サポートされるのはVisual Studio 2015 Update 1以降となっていますので、本当に使おうと思った場合、Visual Studio 2015 Update3を検討してください。

さて、接続しましょう。ここもTeam Foundation Serverと書いていますが、気にせず「追加」をクリックします。なお、Visual Studio 2017ではこのUIがまた少し変わっています。

接続するサーバーを追加するので「サーバー」をクリックします。

VSTSにつなぐ場合、アカウント名.visualstudio.comを指定して、OKをクリックします。

接続に使うアカウント名を選択します。

追加されましたので、「閉じる」をクリックします。

接続するチームプロジェクトを選択します。ちなみにVisual Studio 2017ではここでGitとTFVCの選択がやりやすくなっていますが、VS2015ではTFVCが優先されるようなUIです。

接続すると、複製(git clone)します。基本的に作成したリポジトリのクローンを先に行ってください。

複製先のフォルダを指定します。既定値はDocumentsフォルダのRepsの下に作成となっていますが、昨今のJavaScriptライブラリをcloneすると、ファイル名が簡単に260バイト超えてしまいます。

こんな風にc:\とかに短いフォルダを作成して、その下にcloneしましょう。

Gitの設定

チームプロジェクト内にある、Gitの設定を行っておきましょう。グローバル設定(全Gitリポジトリに共通)と、リポジトリの設定(リポジトリ毎)の二種類があります。リポジトリの設定はVSTSでリポジトリを初期化するとVisual Studioに最適化されたGit設定(.gitignore)がダウンロードされているので、設定する必要はありません。

Gitのグローバル設定ではメールアドレスと、氏名だけは必ず設定しておきましょう。何も設定しないとWindowsのログオンアカウントが使用されてしまいます。

プロジェクトを作成する

git clone後、いよいよVisual Studioで作成します。

.NET のWebアプリケーションを作ります。

.NET Coreでやってみます。

Application Insightsも構成してみます。

App Serviceを設定して、完成。

まとめ

ようやく開発らしいところになりました。ここから先、ようやく開発関係の機能紹介を行います。

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

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

.NET - Powerful Open Source Development

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

ビルド定義を作る

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

違うのは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ではこの定義済みの値は全て大文字として定義されています。

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

テストプロジェクトにあるテストを実行するにはこのようなスクリプトを実行します。テストプロジェクトを実行する前に必ず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エージェントを使ったほうがいいように思います。
次はリリースについて紹介します。