Global Azure Bootcampを今年も開催できました。参加してくださった皆様、セッションを引き受けてくださった皆様、ソフトウェアのライセンスやランチを提供してくれたスポンサーの皆様、会場提供とセッションを引き受けてくださった日本マイクロソフト様ありがとうございました。
資料などはこちらに追加して行く予定です。
https://connpass.com/event/82263/
私のスライドは何故かSlideShareが受け付けてくれなかったので、SpeakerDeckにしました。
VSTSとAzure(Application Insights)使ったContinuous Monitouringのデモをするはずが、何故か関連するタスクが実行エラーになるということで、デモが中途半端に終わってしまい申し訳ありませんでした。
当日内容を変えるというのもなぁということで、突っ切ったのですが、うーん。今聞いているので、なんらかの返事があったらフォローアップします。
次のイベント早くても6月以降ですけど、夜と土曜日とどっちがいいですかね？
ではでは。
前からやりたいと思っていたことの1つが、Webサイトに問題があったときにVSTSに作業項目を登録するということでした。拡張機能とかWebhookでできるかな、と思っていましたが、いつの間にか標準でできるようになっていましたので紹介します。
Application Insightsの「作業アイテム」を選択します。Visual Studio Team ServicesとGitHubが選択できます。
承認するとOAuthのいつものウィンドウが表示されるので、承諾をクリックします。これはVSTS側でいつでも取り消せます。
担当者をとりあえず私に指定しいます。OKを押すと検証が実行され、問題なければ連携完了です。失敗する場合、プロジェクト名や区分名が間違っていないか確認してください。区分やプロジェクト名は大文字小文字を区別しないようです。
実際にどうやるのかやってみましょう。
Application Insightsのブレードに検索があります。ちょうど都合よく例外が起きているリクエストがあったので、クリックして表示します。
例外が起きてますね。普通のタスクツールであればこんな手順になるでしょうか。
何らかのエラーがあったらSlackに障害通知をしている例も多いと思います。このApplication Insightsでの連携を実施していると、「作業項目の作成」をクリックするだけでVSTS側にタスクがバグとして登録されます。
担当者に指定した人の作業項目クエリーに例外が発生したという作業が登録されています。これは実際振り分けるためのエスカレーションを実施する人を登録しておいて、そのあとで誰か実際に作業する人に振り分けるというのもありです。
作業項目を開いてみると、Application Insightsにあった例外コードがそのままコピペされています。VSTS以外にもGitHubのissueに対しても登録ができますので、どちらかを使っている人はApplication Insightsの作業項目の作成機能を使ってみてください。
たぶんApplication InsightsのWebhook使えば、例外発生時に自動的に登録するってこともできるんじゃないかと思っています。
これは2018/2/1時点の情報です。
たぶん日本マイクロソフトさんから翻訳が出るんじゃないかなあと期待しているのですが、重要な注意事項なので簡単に翻訳＆解説してみます。オリジナルも必ず読んでください。
VS Subscriptions and linking your VSTS account to AzureAD – Microsoft DevOps Blog
Visual StudioサブスクリプションはMSアカウントに紐づけるのが基本です。そして、AzureやVSTSのサブスクリプションもMSアカウントで使っている人が多いと思います。個人もしくは小規模団体であればこれでもいいでしょう。
しかし、大きな組織ではそうはいきません。会社で買ったVSサブスクリプションは会社のAzure ADに紐づけておきたいという話はよくあります。VSサブスクリプションを自分のMSアカウントに紐づけたまま、VSTSをAzure ADにくっつける場合の認証のパターンによってはちょっと厄介なことになります。
そのことを書いたのがMSから公開された前述のブログです。
VSTSかAzureを組織のAzure ADに紐づけていて、VSサブスクリプションが個人のMSアカウントなどの異なる認証にある場合、VSサブスクリプションを"Alternate Account"でAzure ADに紐づけてください。
関連付けされると、どちらもOKになります。
このシナリオではMSアカウント作成時にロックダウンされてしまいます。現在解決方法はなく、MS側が頑張って修正しています。今後、MSアカウントの"Alternate account"でAzure ADのVSTSにサインインできるようにするつもりです。
サブスクリプションの管理者はAzure ADのメールアドレスに関連付けます。
二番目のシナリオとよく似ていますが、こちらもサポートされていません。VSサブスクリプション側にフィードバックをもらっていて、Azure ADの外部認証で何とかできるように計画中。管理者が期待するメールアドレスに割り当てるのが一番いい解決方法になります。
この辺のドメインと認証の運用は過渡期ということもあり、非常にややこしいです。私もいろいろ便利そうなので、Azure ADベースでVSTSを運用したいのです。
しかし、サブスクリプションががんじがらめ＆失敗するとどうにもならないということもあり、気軽に試せないです…。必要であれば、MSのサポートに問い合わせてみてください。
注意点として、会社のAzure ADはVSサブスクリプションに対して関知しないといわれたら一番目のシナリオの解決が非常に困ることになるので、この辺の制度を認識してもらうところからでしょうかね。Azure AD関係の知識がないと理解してもらうのが難しいところです。
これはVisual Studio Team Service アドベントカレンダー25日目の記事です。
なんとか完走できました。というか、これは最後のポエム的なエントリーです。
VSTSのCI機能は早くからありましたが、CDに関しては、少し後からという感じでしたね。もともとRelease Managementという買収した製品があり、それをTFSに組み込み、さらにはVSTSに持っていくというところから始まったので、最初のリリース機能はおまけみたいなものでした。
だんだんと改良を続けてきて今に至るわけですが、まだまだもっとこうなればいいなーと思うところはあるものの、当初からしたら随分良くなったと思います。
最近の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の方が都合がいいでしょう。これはこれで正しいように思います。
今後はモバイル用のビューの不足ですね。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と一緒に使うとより便利です。パッと思いつく限りで。
まだ試せていないですが、VSTSをAzure ADで認証して、クライアントはAzure AD, Azure AD Domain Servicesを使っていると、WinRMのpublicプロファイル問題も解消できるんでしょうかね。
これどうなるんでしょうね。当面、別々に運用するようですが、当然連携するところもあります。ただ、ビルドするのは間違いなく、App Centerのビルド定義の方が楽ですね。
今回ほとんど紹介できませんでしたが、CI/CD 時にSeleniumなどで自動化テストを行うと言ったことも可能です。
あとは本番前のいわゆるシステムテスト(負荷テストなど)もできますね。機能的にはほとんど変わってないはずなので、昨年のカレンダーを見ていただいてもいいと思います。
ネタとしてはあったんですが、私の検証不足や執筆ペースの都合で諦めたものも結構あります。
TFS本と並行してできればと思っています。
今年もカレンダーなんとか完走できました！読んでくれて、ちょっとでもVSTSに興味を持ってもらえれば嬉しいです。
来年は他に書く人がいそうだったらやりましょう。
