kkamegawa's weblog

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

Visual Studio Team Services 2017/9/15の更新

Visual Studio Team Services 2017/9/15のSprint 123の更新のリリースノートの翻訳を行いました。オリジナルはこちらから読んでください。

docs.microsoft.com

今回からdocsプラットフォームに移行したんですね。ja-jpはありますが、機械翻訳もないし、翻訳されないんでしょうか…。

今回から待望のマルチフェーズビルドが入りました。これはずっとほしかった(拡張機能作りかけてた…)。バックエンドの.NET Core(やフル.NET)はWindowsエージェントでビルドして、フロントエンドはmacOS/Linuxでやるというシナリオが挙げられていますね。

残念ながらWindowsでのJavaScriptフロントエンドのサポートはよくないので、これは便利そうです。

個人的なユースケースではC++のツール類をビルドして、NuGetパッケージを作るときがすごく助かるのです。シングルフェーズで作ると長くなるし、よくない。artifactを別に保存しておいて、そちらから使えると便利になりそうです。

Web Testってできなかったんでしたっけ…知らなかった。とはいえ、Update 4ってまだプレビューなんじゃ、そして、Update 5って影も形もないような?

バーンダウン/バーンアップウィジェットも便利そうです。この手のものはオンプレミスに負けていたので、ここも強化していくんでしょうかね。

ではまた三週間後。

Translate to Japanese to VSTS release notes from h …

Visual Studio Team Servicesでre:view原稿のCDを行う

kkamegawa.hatenablog.jp

CIやったから、次はCDもやります。

f:id:kkamegawa:20170908071132p:plain

Releasesからリリースを作成します。ArtifactsのところのAddをクリックすると、ビルドで作成されたartifactの選択画面が表示されます。

Default versionは通常latest(最新ビルド)を指定してください。

Source aliasはちょっとわかりづらいのですが、複数のArtifactsを使用する際に区別したいときに使います。通常、ビルド名を使いますが、わかりやすい名前で省略しても構いません。

f:id:kkamegawa:20170908071126p:plain

パイプラインのタスクにはビルドと同じものが大体使用できます。ここではVSTSの内蔵エージェントを使うので、WindowsのAzCopyが指定できます。ストレージのkeyとかいちいちとってこなくてもVSTSのタスクがよろしくやってくれます。

Blob prefixにはAzure Blobのフォルダ名となる値が指定できます。ここではビルド時に生成されたビルド番号を指定しましたが、Gitであればコミットハッシュでもいいでしょう。コミットハッシュを使えば度のコミットに対応した成果物なのか一目でわかりますね。

f:id:kkamegawa:20170908071119p:plain

で、リリースを実行すると、こんな風にBlobにコピーされます。713というのがこの時のビルドNoになります。継続的デリバリーなので、ビルド成功したタイミングで常時デプロイしてもかまいません。しかし、今回はKindleに提出するときの原本として保持しておきたいので、提出原稿がビルドで生成されたことを確認してから、手動でリリース(Create Release)して、Blobへのコピーするようにしたいと思います。

こういうのを分割できるのと、Windowsの機能が余り悩まなくても使えるので、ビルドとリリースを分割しておくとおすすめです。

あとVSTSのアカウントにVS Enterpriseサブスクリプションを登録しておけば、その人数分並列度が上がります。例えば誰かが原稿をビルドしていても、ほかの人がリリース作業するとか、複数人での同時ビルドもできるようになります。

例えば、私のアカウントには9人分の知り合いのMSDNサブスクリプションが入っているので、最大10並列(一つは最初からある分)になります。

Azure コンテナー レジストリを使う

azure.microsoft.com

Azureのサービスの1つ、コンテナーレジストリサービスを使って自前のイメージを管理しましょうという話。Docker hubでもいいのですが、広く公開するものでもないし、あちらは無料だと一つだけ(9/7現在)なので。

今回はクロスプラットフォーム用のAzCopyイメージをAzureコンテナーレジストリに登録します。なんでかというと、まだ公式イメージがないから自前で用意するしかないからです。

f:id:kkamegawa:20170907065258p:plain

Azureポータルからさくっとコンテナーレジストリを作ります。Azureストレージアカウントも作られます。ここで「管理者ユーザー」を「有効にする」を選んでおきます。

ユーザー名とパスワードが表示されます。このユーザーとパスワードでdocker loginします。

f:id:kkamegawa:20170907065309p:plain

パスワードがあるので、docker pullしても、認証がないよと言われます。

docker login ログインサーバー

ユーザーとパスワード聞かれるので、このブレードにあるユーザー名とパスワードを指定すると、ログインできます。

docker pull ログインサーバー/imagename

これで普通にpullもできました。お値段はストレージアカウントの料金と転送料だけなので、自分で作った公開しなくてもいいかイメージを管理するために便利です。

もちろんVSTSでも使えます。

f:id:kkamegawa:20170908071137p:plain

DockerタスクでContainer Registry TypeをAzure Containerを選んでください。Servicesに登録しているAzureサブスクリプションからコンテナーレジストリを登録しているサブスクリプションを選択してください。

Windows Server InsiderでのWSL

WSL = Windows Subsystem for Linux。いわゆるBash on Windowsです。

ちょっと時間が取れたので試してみました…と書こうとしたら、Insider Preview 16278が公開されるというタイミングの悪いものになってます。検証は16267でやってます。

blogs.windows.com

バージョンの更新

  • 今のところISOメディアでのみの提供のようです。
  • 前バージョンのプレビューからアップグレードはできますが、「何も引き継がない」というオプションしか選べません(16278も同じ)。
  • なので、インストールごとにWSLの環境も構築しなおしです。Server Coreとはいえ、自動化しないと結構やってられなさそう。

WSLのインストール

 現在OpenSUSE, Ubuntu, SLESと提供されています。Windows 10と違って、ストア経由ではなく、直接ダウンロード用のURLからappx(!)パッケージをダウンロード、PowerShellのexpand-archiveコマンドレットで展開します。なので、好きなフォルダに展開、インストールができます。

PowerShell
Invoke-WebRequest -Uri https://aka.ms/wsl-ubuntu-1604 -OutFile ~/Ubuntu.zip -UseBasicParsing
Expand-Archive ~/Ubuntu.zip c:\distro\Ubuntu

exeファイルが一つあるので、そのまま実行すればOK。

複数インストール

SLES, Ubuntu, OpenSUSEの同時インストールもできます。もちろんフォルダはわけてね。

Windowsのコマンドプロンプトからbash.exeを実行すると、WSLが起動します。この時の使われるディストロは最初にインストールしたものが使われるようです。

二番目以降にインストールしたディストロを起動したい場合、明示的にフォルダに移動してからubuntu.exeなどのセットアップに使ったexeを実行します。

消した場合

二番目以降にインストールしたディストロを消すのはいいのですが、最初にインストールしたディストロのインストールフォルダを消した場合、bash.exeではWSLが起動しなくなります。

一度WSLを消してから再度入れ直すのがよさそうです。

PowerShell
disable-WindowsOptionalFeature -FeatureName Microsoft-Windows-Subsystem-Linux

コメント欄で教えていただきました。消さなくても

ubuntu.exe /clean

wslconfig /u

コマンドで登録の解除をすればいいそうです。

lxrunコマンド

Windows 10ではlxrun /uninstallでBash on Windowsの削除ができましたが、Windows Serverでは実行しても無意味なコマンドのようです。

f:id:kkamegawa:20170906065926p:plain

lxrun /uninstall しても、bash.exeで最初のディストロが起動します。OS再起動しても問題ありません。

Visual Studio Team Services 2017/8/28の更新

遅くなりましたが、VSTSの8/28のSprint 122のリリースノートの翻訳を行いました。オリジナルのリリースノートはこちらから読んでください。

www.visualstudio.com

今回から待望のGitのforkが入りました。レポジトリの作成権限が必要になるはずですが、ブランチだけではカバーできないような運用もできますね。TFS 2018にも入っていますが…例によって過剰な翻訳入っているので、フィードバックしています。

https://developercommunity.visualstudio.com/content/problem/106489/over-localize-forking-repos-name-in-tfs-2018-rc1ja.html

地味にビルド定義の一時停止も希望していた機能です。

Bitbucketの連携もちょっとびっくりしましたけど、便利に使えそうです。

ではまた三週間後。

ranslate to Japanese to VSTS release notes from ht …

Visual Studio Team ServicesでRe:VIEWのCIを実施する

はじめに

TFS2017本をRe:VIEWを使って書いているのですが、ローカルビルドでやっていました。ビルド環境が安定しないのと、Windows Subsystem for Linuxでpdf生成までやろうとすると、ディスク食うのでやってみたかったDockerとの連携をすることにしてみました。

VSTSビルドエージェントを作る

最初はVSTSのLinux Hosted Agentを使おうとしたのですが、残念ながらLinux Hosted AgentにGit-LFSが入っていないようで、原稿のpullができませんでした(報告済み)。
(8/25追記)今日最新のHosted Agentが更新されたようで、Git LFSも入っています。試したらちゃんとHosted Agentでビルドできました。したがって、この手順は不要です。ビルド時にLinux Hosted Agentを選択してください。

そこで、Azure(じゃなくてもいいんだけど)にUbuntu 16.04 LTSを立てて、ビルドエージェントを作ります。VSTSビルドエージェントのdockerイメージが提供されているので、素直に使います。

https://store.docker.com/community/images/microsoft/vsts-agent

f:id:kkamegawa:20170820200923p:plain

こんな感じのシェルスクリプトを作って起動させます。

docker run -d --hostname ubuntsu001 \
  -e VSTS_ACCOUNT={vsts account} \
  -e VSTS_TOKEN={PAT} \
  -e VSTS_WORK='/var/vsts/$VSTS_AGENT' \
  -v /var/vsts:/var/vsts \
  -v /var/run/docker.sock:/var/run/docker.sock \
  -it microsoft/vsts-agent

PAT(Personal Access Token)は最長一年なので、気を付けてください。期限切れの通知もありません。

VSTSエージェントをdockerで実行します。/var/run/docker.sock をマウントさせるのはほんとはまずいらしいのですが、VSTSエージェントはsshなどでログインさせる必要がないので、大丈夫のはずです。

qiita.com

Dockerレジストリへの接続設定

最初にDocker拡張機能を追加します。

marketplace.visualstudio.com

f:id:kkamegawa:20170820200904p:plain

拡張機能を追加すると、dockerビルドタスクが使えるようになります。コンテナイメージを都度pullする場合、管理ページからdocker.comへの接続を作ります。

f:id:kkamegawa:20170820200858p:plain

DockerIDとパスワードを指定します。

Re:VIEW文書をビルドする

本のPDF/epubごとにビルドタスクを作ります。

f:id:kkamegawa:20170820200916p:plain

  • DisplayName:タスクの表示名です。好きな名前でどうぞ
  • Container Registry Type: Azureコンテナレジストリか、それ以外か
  • Docker Registry Connection:上で作成したdocker.comへの接続を選択します
  • Action:pullしたイメージを実行するので、"Run an image"
  • Image Name:vvakameさんが提供してくれてる、vvakame/reviewを指定します。

f:id:kkamegawa:20170820200909p:plain

  • Volumes: マウントするボリュームを選択します。$(Agent.BuildDirectory)配下にTeXフォントキャッシュ(?)を指定します。ビルドで使用する$(Build.SourcesDirectory)をマウントしておきます。
  • Command: ビルドに指定するコマンドを指定します。
/bin/sh -c "cd $(Build.SourcesDirectory)/1_setup && review-pdfmaker config.yml"

ソースリポジトリからpullしたソースが$(Build.SourcesDirectory)にあるので、その下/1_setupでPDFを作ります。

この記事中に出てくる$()で囲まれている文字列は、VSTS内で定義されている値です。どんな値が定義されているかはこちらに載っています。

www.visualstudio.com

例えば、Gitのコミットハッシュやブランチ名などを使うのもいいでしょう。

$(Build.SourcesDirectory)などのこの記事中の値はすべてVSTSでデフォルト定義されているものしか使っていませんが、例えばデータベースへのパスワードなどはvariablesハブで定義した独自の値を使うこともできます。

実際データベースのパスワードのような機密性の高い値はvariableへの直書きではなく、variable groupsに定義して、さらにAzure KeyVaultに保存しましょう。

ビルドのvariablesはビルド内しか使えませんが、variable groupsに登録しておけば、ビルドとリリースの両方で使えます(今回はリリースを使っていませんが)。

成果物にする

Re:VIEWでは特に指定しなければ、ソースフォルダ直下に作成します。このままではすぐに消えてしまうので、どこかに取っておきます。ここではVSTSの中に保持しておきます(これもデフォルトでは一定期間で削除されます)。

www.visualstudio.com

www.visualstudio.com

f:id:kkamegawa:20170820212349p:plain

まず、成果物として、VSTS内に保存したいファイルだけをソースファイルからステージングフォルダへコピーします。次で説明するPublish to Artifactタスクがフォルダ丸ごとのコピーしかできないためです。

  • Source Folder:$(Build.SourcesDirectory)を指定します。
  • Contents:コピーしたいファイルを選択します。minmatchパターンが使えます。
  • Target Folder:$(Build.ArtifactStagingDirectory)を指定します。

f:id:kkamegawa:20170820212642p:plain

Publish ArtifactタスクでVSTS内に保存します。

  • Path to Publish:先ほどコピーした$(Build.ArtifactStagingDirectory)を指定します。
  • Artifact Name:成果物の名前です。dropを慣例的につけてます。
  • Artifact Type:Serverを指定すると、VSTSに保存します。File Shareを指定すると、UNCのファイル共有になります。実際はAzure Storageのファイル共有になるでしょう。

f:id:kkamegawa:20170820212345p:plain

ビルドが成功すれば、このようにartifactsに格納されます。

成果物の原稿を他人と共有する(追加)

VSTSは無料で5人まで無制限のGitリポジトリとしてアクセスできます。ただ、epub/pdfだけアクセスできればいいという場合、ライセンスを使うのももったいない話です。

そういう場合、ビルドタスクで各種クラウドストレージやGitHubに送るという方法が考えられます。

例えば、ビルド成果物をGitHub Releaseに送る拡張機能。

marketplace.visualstudio.com

AWSのS3などに送るための拡張機能。

marketplace.visualstudio.com

標準機能でもあるのですが、ビルドできたことをSlackへ通知するための拡張機能(VSTSへのアクセス権がある人はメール通知もできます)。

marketplace.visualstudio.com

www.visualstudio.com

#MS Teamsは現時点では残念ながらAzure ADで運用しているVSTSじゃないと使えません。

最初はMS FlowやLogic Appを使って通知および、ファイルコピーしようと思ったのですが、VSTSのコネクタにはビルド成果物へのアクセスがないので、REST APIを使うしかないようです。

www.visualstudio.com

個人的にはAzureのBlobストレージへのコピーをやろうとしているのですが、Azure CLI 2.0のコマンドがよく理解できなくて止まってます…。Windows上のエージェントだったらPowerShellやAzCopyを使ったコピーが楽にできるのですが。

#.NET CoreベースのAzCopyにはまだ公式Dockerイメージがないようなので。自分で作るしかないか…。

終わりに

dockerをあまり理解しておらずやってたので、結構試行錯誤しました。これでCIができました。VSTSのhosted agent使えばビルド時にdockerイメージをpullすることもできるはずです。

Git LFSが入っていないことに気づくまで、何回かHosted Agentでやったのですが、vvakame/reviewイメージのダウンロードは大体30秒かからないようです。でも、毎回だとちょっときついですね。

Windows Server 2016 Insider 16257のWindows Subsystem for Linuxを試す

待っていた、Windows Subsystem for Linux(WSL)をサポートしたWindows Server 2016 Insider 16275が公開されました(サポートそのものは16237かららしい)。

blogs.windows.com

Announcing Windows Server Insider Preview Build 16257 - Windows Experience Blog

実機に入れてみたので、簡単に試してみましょう。

WSLを追加

f:id:kkamegawa:20170810171747p:plain

PowerShellのコマンドレット、Enable-WindowsOptionalFeatureを使って有効にします。その前にGet-WindowsOptionalFeatureで入っているかどうか確認してみます。StateプロパティがDisabledなので、入っていませんね。

Enable-WindowsOptionalFeature -Online -FeatureName Microsoft-Windows-Subsystem-Linux

再起動するとインストール完了です。

Ubuntuを追加

f:id:kkamegawa:20170810171550p:plain

Windows 10 Insider 16257ではストアからダウンロードしますが、現在のWindows Server InsderではWebからとってきます。Ubuntuを入れていますが、OpenSUSEとSLESにも対応しています。PowerShellのInvoke-WebRequestコマンドレットでとってきます。

Invoke-WebRequest -Uri https://aka.ms/wsl-ubuntu-1604 -OutFile ~/Ubuntu.zip -UseBasicParsing

OpenSUSEの場合

Invoke-WebRequest -Uri https://aka.ms/wsl-opensuse-42 -OutFile ~/opensuse.zip -UseBasicParsing

SLESの場合

Invoke-WebRequest -Uri https://aka.ms/wsl-sles-12 -OutFile ~/sles.zip -UseBasicParsing

ここからはUbuntuで説明します。

f:id:kkamegawa:20170810171555p:plain

Expand-Archiveコマンドレットでzipを展開します。%USERPROFILE%直下に展開していますが、好きなところで構わないはずです。Windows 10の場合、%LocalAppData%\LxSSでした。

zipファイルを展開すると、こんな感じです。ubuntu.exeを実行すると、インストールが始まります。

f:id:kkamegawa:20170810171800p:plain

最初にUbuntu用のユーザーを作ります。これはWindows 10と同様に、Windowsのユーザーとは別管理です。

f:id:kkamegawa:20170810185210p:plain

インストール後、aptコマンドで更新しておきましょう。これでインストール終わりです。プログレスバーが乱れているのはリモート接続だからか、Insiderだからか…まぁいいでしょう。

f:id:kkamegawa:20170810171755p:plain

Ubuntuが入っています。

使ってみる

f:id:kkamegawa:20170810173524p:plain

Windows 10と同様に、Windows側のパスもWSLのパスとして登録されていますね。Windows 10と同様に、dirコマンドの結果をパイプでWSL側のgrepに渡せます。もちろん、そのままgrepと実行しても起動できないので、注意してください。

f:id:kkamegawa:20170810185142p:plain

ちなみに、bash.exeを実行した場合、ubuntu.exeを経由せず実行できます。複数のLinux環境入れた場合、どれが優先されるんでしょうね?

消した場合

f:id:kkamegawa:20170810171751p:plain

Enable-WindowsOptionalFeatureで追加できますが、Disable-WindowsOptionalFeatureでWSLを消すこともできます。Linuxモジュールは別管理のようで、Disable-WindowsOptionalFeatureで消した後、ubuntu.exeを実行すると、こんなエラーになります。

もちろん、再度Enable-WindowsOptinalFeatureでWSLを追加すると、ユーザー環境などはそのまま引き続き使用できます。確認してないですが、lxssコマンドもありました。

今後

とりあえずdocker入れたので、WSL側のdockerからWindowsのDockerコンテナ動くかとか、VSTS/TFSのビルドエージェント経由でWSLがどうやって動かせばいいのかとか、試してみたいと思います!