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もやります。

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

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

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

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

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

で、リリースを実行すると、こんな風に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コンテナーレジストリに登録します。なんでかというと、まだ公式イメージがないから自前で用意するしかないからです。

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

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

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

docker login ログインサーバー

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

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

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

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

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では実行しても無意味なコマンドのようです。

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