2017年振り返り

TOP10ランキング

2017年も終わりました。皆様いかがだったでしょうか。2017年に最も読まれた記事をちょっとだしてみます。ランキングにはid:shibayanのランキングを使わせてもらっています。私はリアルタイムプレビューをよく使うので、それがTOPになっていたので、それだけ除外しました。

2017 年の人気記事ランキング生成

1. Word 2016の游明朝Light 12ptで行間が不正に広い(修正されました)
2. Windows 10に.NET Framework 3.5を追加する
3. Windows 10のbash on Windowsを試す
4. Windows 10英語版にオフラインで言語パックを追加する
5. Windows Server 2012のWSUSをPowerShellで管理する。
6. Visual Studioに統合されるデータベース開発ツール- SSDT
7. Visual Studio Team Servicesを会社で使う場合の考慮事項
8. Surfaceからプロジェクターに出力する
9. Visual Studio Team Servicesに接続して開発する(6日目)
10. Windows 8/10でデスクトップヒープを調べる

やっぱりトラブル解消系がよく参照されるんですね…。VSTSの記事がようやく二つ入っているのがせめてもの救いです。

メディア系

Bash on Windows改め、Windows Subsystem for Linuxの記事をBuildInsiderさんで続けて書かせていただきました。

www.buildinsider.net

個人的にはちょいちょい便利に使っているWSLですが、Linuxはむかーしやってたくらいですが、ずいぶん変わっているものだと思ってやってます。

TFSの本も出ないし、書いてみるかーということでKDPで書いてみました。

Team Foundation Server 2017 コンプリート ガイド セットアップ編 Team Foundation Server 2017コンプリートガイド

ほんとはそろそろ全部終わっているはずだったんですが(汗)。ソースコード管理と作業項目をどう書き分けようかと思っているとイベントとかアドベントカレンダーが入ってしまって延びてます。

とりあえず次はTFS 2018のセットアップ編を書いてから二つ並行して書こうかなと思います。

イベント

関西ではイベントもあまりないので、自分で開催することにしました。Azure Global Bootcamp /w OzCodeでOzCodeの皆さんの日本ツアーと合同でできたのはいい思い出です。

connpass.com

このときは集客面でちょっと焦ったんですが、秋に開催した.NET Confではほぼ予定通りの集客ができてほっとしました。

connpass.com

TFSUGとしてはイベントできてないですね…しかし、次のAzure Global Bootcampも控えているので、ちょっとどうかなーという感じです。3月は渡米も予定されています。

今年も一人アドベントカレンダー頑張った感じですが、もう次はいいかな(^^;。

2018年もよろしくお願いします。原稿やイベントのお声がけはいつでも待ってます。

Visual Studio Team Services CI/CDアドベントカレンダー：CI/CDまとめ(25日目)

はじめに

これはVisual Studio Team Service アドベントカレンダー25日目の記事です。

qiita.com

なんとか完走できました。というか、これは最後のポエム的なエントリーです。

VSTSとCI/CDについて

VSTSのCI機能は早くからありましたが、CDに関しては、少し後からという感じでしたね。もともとRelease Managementという買収した製品があり、それをTFSに組み込み、さらにはVSTSに持っていくというところから始まったので、最初のリリース機能はおまけみたいなものでした。

だんだんと改良を続けてきて今に至るわけですが、まだまだもっとこうなればいいなーと思うところはあるものの、当初からしたら随分良くなったと思います。

Webへの傾倒

最近のVisual Studio Team Services/Team Foundation Server/Visual Studioのリリースを見ていると、Webへ舵を切っているように見えます。実際、Test ManagerやFeedback Clientはサポートこそされているものの、Visual Studio 2017標準ではインストールされません。

MSの昨今の方針を示すように、クライアントもクロスプラットフォームのために.NETオブジェクトモデルから、REST APIを押しています。もちろん、.NET Coreでもいいのでしょうけど、あのオブジェクトモデルを.NET Coreに移行させるとなると、既存のライブラリ群からの移行が大変そうです。

Python製のVSTS-cliも出てきたし、Web拡張機能を使うにもRESTの方が都合がいいでしょう。これはこれで正しいように思います。

github.com

今後はモバイル用のビューの不足ですね。Work itemなど一部はサポートを始めましたが、まだまだ不足しています。かと言って、そう簡単に作れそうもない気もしますし、必要かと言われれば…うーん。

エージェントについて

CIに使うビルドサーバーを管理したくない、というのはその通りだと思いますが、反面外に出せないライブラリやコンパイラーを使うために独自のエージェントを立てる道が用意されているのはハイブリッドを得意とする、MSらしいなと思います。

ただ、ちょいちょい？と思うことはあります。昨日までは1分で終わるようなソリューションのビルドにある日突然7−8分かかったりとか。今回だいぶビルド無償枠を使ったのですが、この不思議なポーズ(?)現象のおかげで、無為に使われてしまいました。

後、これは致し方ないのですが、スプリント単位でVSのエージェントが更新されるものの、15.5がリリースされるちょっと前に15.4にしました！というのはもうちょっとなんとかならないものかと。

VSのビルドツール類がコンテナーになって、VS Hosted AgentがWindows Server 2016ベースになれば解消するのでしょうか。

ビルド/リリース時のキャッシュ

NuGetパッケージのリストアやDockerコンテナーのpullでもうちょっとキャッシュされないかなぁとは思います。パッケージリストアで1-2分、docker pull も結構早いのですが(特にazure container registry使うと)、他のCIサービスがキャッシュしているように見えるので、この辺の改善もされるといいなとは思います。

Azureいらないようで、実はいる

同じ会社のサービスだから当然と言えば当然なのですが、Azureと一緒に使うとより便利です。パッと思いつく限りで。

• Application Insights, Monitorなどを使ったリリースゲート
• Key Vaultを使った機密性の高いデータの格納
• Azure AD(AAD)を認証に使うとAADのグループがそのままチームになる
• DevTest Labsと連携してテストエージェントの展開

まだ試せていないですが、VSTSをAzure ADで認証して、クライアントはAzure AD, Azure AD Domain Servicesを使っていると、WinRMのpublicプロファイル問題も解消できるんでしょうかね。

App CenterとVSTSとの住み分け

これどうなるんでしょうね。当面、別々に運用するようですが、当然連携するところもあります。ただ、ビルドするのは間違いなく、App Centerのビルド定義の方が楽ですね。

TestとCI/CD

今回ほとんど紹介できませんでしたが、CI/CD 時にSeleniumなどで自動化テストを行うと言ったことも可能です。

あとは本番前のいわゆるシステムテスト(負荷テストなど)もできますね。機能的にはほとんど変わってないはずなので、昨年のカレンダーを見ていただいてもいいと思います。

今回できなかったところ

ネタとしてはあったんですが、私の検証不足や執筆ペースの都合で諦めたものも結構あります。

• AWS との連係(拡張機能を入れるだけですが)
• もっと他にいろんなパターンのデプロイ
  • LogicApp / Functions
  • Hadoopなど
  • AWS(Lambda/S3/EC2)
  • Cognitive系
  • データベース上級編
  • 大規模並列デプロイ
  • JavaやJavaScript, PHP, Pythonなどの他プラットフォーム
• Docker(これはちょっとハマり中)
• VSTSビルドタスクを作ってみる
• Release Gateの他のパターン
• モバイル開発(Xamarin, Swift, Kotlinなどバックエンドを含めて)

TFS本と並行してできればと思っています。

終わりに

今年もカレンダーなんとか完走できました！読んでくれて、ちょっとでもVSTSに興味を持ってもらえれば嬉しいです。

来年は他に書く人がいそうだったらやりましょう。

Visual Studio Team Services CI/CDアドベントカレンダー：App Centerとの連携(24日目)

はじめに

これはVisual Studio Team Services アドベントカレンダー24日目の記事です。

qiita.com

最近モバイル開発もよく聞くようになっていますというか、全盛時代ですね。私自身はあんまり…なのですが、一通りくらいはやっておかないとなぁということで、App Centerとの連携を試してみることにします。

サインアップ

サインアップはGitHub/MSアカウント/Facebook/Googleもしくは独自アカウントで可能です。私はMSアカウントでやってます。

VSTSとの接続

VSTSとの接続にはAPI Keyを使います。App Center側で専用のAPI Keyを作り、VSTSのチームプロジェクトに登録します。

API TokensからNew API tokenをクリック。

わかりやすい名前と、アクセス権を設定します。VSTSからApp Centerに発行する必要があるので、Readではダメなので、Full Accessを選択します。

API Keyとなるランダム文字列が生成されるのでコピーします。次はVSTS側の作業です。

ServicesからNew Service Endpointをクリックして、Visual Studio App Centerをクリック。

App Centerのtokenに先ほどコピーしたAPI Tokenをペーストして、OKを押します。

ロゴの色が古いですが、気にせずこれでOKです。

App Centerのプロジェクト作成

App Centerはアプリ単位ではなく、バイナリー単位でプロジェクトを作成します。Visual Studioでソリューションを作った場合、複数のプラットフォーム向けのプロジェクトが一つになりますが、App Centerは別なので気を付けてください。

iOS/Xamarinでプロジェクトを作ります。

ビルドにVSTSにあるソリューションを使おうとする場合、Visual Studio Team Servicesを選んで接続すればいい…と思うのですが、ここから接続すると、なぜかAzure ADで認証するVSTSが自動的に選ばれてしまいました。まとめるとこうです。

• Windows 10はAzure AD(Office 365)に接続(SSOではない)している
• MSアカウントでも接続している
• Azure ADで認証しているVSTSもある(去年のアドベントカレンダーで作ったから)
• しかし、VSTSはMSアカウントのものを使いたい
• 認証でなぜかAzure AD側のVSTSが自動的に選ばれた

うがー本来OAuthでMSアカウント側のVSTSに接続したかったのですが、頓挫しました。ちなみに、issue trackerからVSTSに接続する場合、ちゃんとMSアカウントのVSTSが選択できました。なんだそれ。

こんな風にissue trackerにはMSアカウントのVSTSが選択できます。ちなみに、Azure ADのVSTS側から、App Centerの認証を取り消してしばらくまってください。

この現象はEdgeだと発生するので、Azure ADを使っている人がMSアカウントのVSTSに接続するときはChromeやFirefoxを使うことを推奨します。

VSTSでのビルド定義

VSTSのビルド定義にはApp Centerでテストする、App Centerに登録するといったタスクが用意されています。

Xamarin.iOS/Xamarin.Androidのテンプレートがあるので、そこから作っていきます。このへんはXamarinになれた方のドキュメントを見たほうがいいと思います。

App Centerへのデプロイですが、ちょっとややこしいですね。App CenterのURLに含まれる appcenter.ms/{username}/app/{appname} の{username}/{appname} 形式になります。

docs.microsoft.com

この辺はまだよくわからないです…

App Centerでビルド

認証キャッシュが切れたようなので、Chromeで再度接続してみたら、MSアカウント側のVSTSに接続できました。やってみたらさらに簡単ですね。

Configurationがデフォルトdebugでした。VSTSではReleaseがデフォルトなのに意外と思ってしまいました。

VSTSのビルドタスクではリリースノートが必須項目だったのですが、App Centerにはないですね。apkのサインとかいろいろ楽になっています。

手動でビルドしてみます。

ログを見る限り、VSTSのLinux Hosted Agentが動いているようです。おそらくOSごとに違うエージェントが動いているのでしょう。

こんな感じであっさりビルドできてしまいました。XCodeなどは試せていませんが、おそらく同程度にできるのでしょう。

ビルド時間はVSTSと同様に240分無償のようですが、これ別計算なんですかね…VSTSと同じエージェント使っているんだから、VSTSの枠でやってくれたら料金も一緒になっていいんじゃないかなとは思います。

Visual Studio Team Services CI/CDアドベントカレンダー：ビルド/リリースで使う環境変数を見る(23日目)

はじめに

これはVisual Studio Team Services アドベントカレンダー23日目の記事です。

qiita.com

ビルド・リリースで実行するエージェントで参照できる値がいくつか定義されています。

docs.microsoft.com

ここに載ってはいますが、実際にどう定義されているのかという情報を眺めてみましょう。

方法

非常に簡単です。ビルド定義を作って、PowerShellで定義済み環境変数を列挙して表示すればいいだけです。

こんな風にPowerShell Scriptのインラインタスクで[environment]::GetEnvironmentVariables()を実行するだけです。もちろん、ソースのpullが発生しないように、昨日同様、Don't sync sourceにチェックを入れてください。

実行するとこんな感じです。スクロールすると、どんな値が定義されているか調べられるでしょう。

これを見て、実際にどんな値が定義されているか確認してみてください。

今日は簡単ですがこの辺で。