kkamegawa's weblog

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

Visual Studio Team Services 2017/1/5の更新

お久しぶりのVSTSのリリースがありました。もう少し先だと思っていましたが、早かったですね。今回はSprint 110を飛ばして、111と一緒にリリースされているので、内容も盛りだくさんです。オリジナルはこちらから。

www.visualstudio.com

新しいプロジェクトページは情報が集約されて、とてもつかいやすくなったと思います。いつでも戻せるので(将来的にはこちらに移行するのでしょうが)、試してみてください。ほとんどの機能にお気に入りがついて、Favoritesでまとめて見えるようになったのは助かりますね。積極的につけていくといいでしょう。

一つだけ使いにくくなったかなと思うのは、Hosted Build/Load Testの使用時間がわからなくなることです。今まではアカウントホームページで見えていたのですが、プロジェクトページを有効にしてしまうと見えなくなるので、ちょっと困る。フィードバックはしています。

TFS 2010を最後に廃止されていたテスト影響分析(変更のあったテストのみ自動的に実施する)も戻ってきました。通常は全テストすればいいのですが、どうしても間に合わない時というものもあります。そういう時に便利かなと思います。

ではまた三週間後!

translate to Japanese to VSTS release notes from h ...

VSTS/TFSで長期間にわたる保守業務をタスク管理する

はじめに

VSTSやTFSで作業管理する場合、ちょっと悩ましいのが定期的に発生するような「長期間にわたる定常業務」をどうやって管理するか、という話があります。私も部門で入れようとして、この辺どうしようかなぁと試行錯誤しました。Epicを作るとかでもいいのですが、それも何か違う。

ある人から聞いた話では「1時間絵の練習をする」とか「チュートリアルをやる」などをタスクにしているそうです。具体的に「xxまで完成させる」ではなく、あくまでもタイムボックスでタスクにする。

こうすると、進捗のいかんではなく、やったかやってないかだけですが、比較的心理的に軽くなります。またバーンダウンもやればいい感じで出るので、モチベーションにもつながりますね。

具体例

  1. 計画されたタスクはFeatureやSprint backlogとして作る
  2. 計画されてないタスクをまとめるSprint backlogを作り、Sprint毎の日付で一つのタスクにする。完全に異なるタスクであれば、別のタスクにする

f:id:kkamegawa:20170112062257p:plain

doingとdoneに分割して、WIPを制限しています。

f:id:kkamegawa:20170112054814p:plain

定期的に発生するとわかっている作業はそれだけでバックログにします。このバックログはスプリント期間が終了すればcloseします。複数の担当者がそれぞれ定期的な作業を持っている場合は個人単位でバックログにすればいいでしょう。

このような保守業務のバックログはSwimlanesで分割してしまえば計画された作業と区別できるので便利です。

f:id:kkamegawa:20170112054815p:plain

バックログ内の作業は日単位でタスクにしてしまいます。あらかじめわかっているので、最初に全部作っておけばいいでしょう。ちゃんと時間を登録しておけば作業時間としても可視化できますね。

プロセステンプレートで対応する

f:id:kkamegawa:20170112062259p:plain

余裕があればプロセステンプレートを修正して、Taskに「保守作業」というフィールドを追加して、Booleanを設定します。

f:id:kkamegawa:20170112062300p:plain

こうすると、タスク画面に保守作業かどうかのフラグが表示されます。こういうフラグを用意しておけばクエリエディタで、残っている保守作業や、保守作業の作業量を集計することもできるので、便利です。

ここまでやりたくない、という場合、Taskのタグで「保守作業」とか設定しておけばいいでしょう。タグもクエリで検索できますので。ただし、みんなにいちいち作ってもらう運用だと絶対忘れるので、REST APIでスプリントの最初に作っておくとか、毎日バッチなどで自動的に作るといいですね。

関連拡張機能

marketplace.visualstudio.com

定期的な保守ではないですが、拡張機能のTeam Calendarでチーム内のイベントをカレンダー形式で管理できます。特定のイベントがあるとかの管理に便利そうですね。

Visual Studio Team Servicesで外部サービスを呼び出す(30日目 - 最終回)

はじめに

アドベントカレンダーの枠からはみ出して続けていたVSTSの機能全紹介もここでいったん区切りです(1/5の新機能が出ちゃったし)。VSTSは基本オールインワンですが、Web hookやREST APIを使って外部サービスを使用することもできます。

外部サービス呼び出しはチームプロジェクトごとの設定になります。

Azure Resource Manager Endpoint

やはり同じ会社のサービスということもあり、Azureはいろいろ優遇されています。

f:id:kkamegawa:20170104070633p:plain

今強化やデプロイは基本Azure Resource Managerのほうが多いので、こちらを選ぶと…

f:id:kkamegawa:20170104070634p:plain

こんな風に接続名とサブスクリプションを選ぶだけです。以前はMSアカウントでSPNを作る必要があり、はっきり言って、「これユーザーにやらせるのか」と思っていたのですが、便利になりました。

f:id:kkamegawa:20170104070635p:plain

Azure Classicで接続sるう場合…面倒ですね。通常はCertificate Basedを選んでAzureポータルから管理証明書をダウンロードするのですが面倒です。

GitHubへの接続

f:id:kkamegawa:20170104070636p:plain

GitHubでホストされているソースをVSTSでビルド、Release Managementで使用する場合に必要です。ここで設定しなくても、ビルドタスクの中でもできます。PATを使うか、ここでOAuthの認証をするか好きな方法が選択できます。どちらを使ってもGitHub側で無効にできます。

Jenkinsへの接続

f:id:kkamegawa:20170104070638p:plain

Jenkins連携も強化されてます。Jenkinsを選択すると、サーバURLとユーザー、パスワードを指定します。

SSHでの接続

f:id:kkamegawa:20170104070639p:plain

SSHを使用して特定のホストに接続します。LinuxのWebサーバなどへVSTSからデプロイする場合にこの接続を使います。

Subversion

f:id:kkamegawa:20170104070640p:plain

Git(Hub)同様に、外部ソースコードリポジトリにSubversionをサポートしています…一部のエンタープライズ向けにはいいんじゃないでしょうかね。

その他一般的な外部サービス

f:id:kkamegawa:20170104070637p:plain

サーバのURLとユーザー、PAT/パスワードで接続する外部サービスです。VSTSの拡張機能で提供されていないような外部サービス(Chatworkとかかな…)を使う場合使用します。

SonarQubeへの接続

Continuous Code Quality | SonarQube

最後は静的解析では有名なSonarQubeの紹介です。品質管理はSonarQubeに任せることにしたようで、最近強化が続けられています。有償版と無償版、さらにはLTSも提供されていますが、SonarQubeの強化と同期をとっているようなので、できればLTSではない、Currentを使ってください。ほぼ毎月のように更新されています。

つい先日公開された6.2でUIが結構変わってびっくりしています(6.0で変えなかったのに)。

f:id:kkamegawa:20170110063009p:plain

サービス一覧からSonarQubeを選択します。アクセスするユーザーでTokenを生成してください。Azureの仮想マシンで作る場合、AzureにSQL Serverを作ってもいいのですが、SQL Databaseもサポートされているので、SQL DatabaseにS0で作っています。遅くなったなと思ったら、SQL DatabaseをS1とかにすればいいでしょう。

f:id:kkamegawa:20170111055821p:plain

SonarQubeで解析する場合、ビルドタスクにPrepare the SonarQube analysisを追加します。注意点として、先日MSが提供するビルドタスクからSonarSourceが作ったビルドタスクに移行することになりました。

[DEPRECATED]がついているタスクは使わないでください。

f:id:kkamegawa:20170111055823p:plain

ビルドすると、こんな風に最後にDetailed SonarQube reportと表示されています。クリックすると、SonarQubeを呼び出して…

f:id:kkamegawa:20170111055822p:plain

こんな風にSonarQube側でプロジェクトが開かれます。

まとめ

VSTSの外部サービス連携は以前のService Hookと合わせて使えばいろいろ使えると思います。いいとこどりしてみてください。

ちょっと駆け足でしたが、VSTSの全機能を大体紹介したつもりです。Application Insightsとかも紹介したいなと思ったのですが…ほかにも漏れているところがあれば、また紹介します。では今年のアドベントカレンダーは…疲れたから別のやつにします(^^;。

実はもう一つだけネタがあったのですが、ちょっと間に合わなかったのでまた後で。

Visual Studio Team ServicesとAzure App Servicesの継続的デプロイメント(29日目)

はじめに

Azure App Servivesには二つデプロイ方法が用意されています。現在プレビューの継続的配信昨日はVSTS側に設定を行います。

更新のお知らせ

この記事のタスクはproject.jsonを使う古い.NET Core 1.0ベース(VS2015といってもいい)のやり方になっています。VS2017を使うやり方は別途書きましたので、そちらをみてください。

kkamegawa.hatenablog.jp

デプロイオプション

f:id:kkamegawa:20170108160044p:plain

今まであった、デプロイオプションはこんな感じで作れます。これはGitリポジトリのみサポートのようでGitリポジトリにコミットがあれば自動的にAzure App Services側にデプロイされます。

一切処理がない、静的コンテンツを配置するときに便利だと思います。VSTSのHosted Agentのビルド時間を消費しないのでお得です。

Azureの継続的配信(プレビュー)

f:id:kkamegawa:20170108160045p:plain

しかし、ASP.NET(Core)のデプロイするときは困るためかどうか知りませんが、継続的配信という機能が追加されました。Configureをクリックすると、設定が始まります。

f:id:kkamegawa:20170108160046p:plain

ソースリポジトリ、プロジェクト、ブランチを選択します。

f:id:kkamegawa:20170108160047p:plain

ASP.NETかASP.NET Coreかを選択します。注意点として、現時点においてVSTSのHosted AgentはASP.NET Core 1.1に対応していないので、1.0のプロジェクトである必要があります。

f:id:kkamegawa:20170108160048p:plain

負荷テストとApp Servicesのデプロイメントスロットを使っている場合はここで指定できます。

f:id:kkamegawa:20170108160049p:plain

これで完了です。左からリンクをクリックするとVSTS側のビルド定義の確認、リリース定義の確認、ビルド実行となります。

VSTS側の設定

f:id:kkamegawa:20170108181358p:plain

Azure側で作成した継続的配信はVSTS側でこんな風に既定のビルド定義が作成されます。TriggersタブにContinuous integrationオプションが設定されているので、リポジトリにコミットされるとAzure側へのデプロイが行われます。

f:id:kkamegawa:20170108160051p:plain

デプロイも設定されています。つまり、ビルド→リリースが自動的に行われます。Hosted Agentの時間もそれだけ使われます。

不要になった場合

不要になった場合、以下の手順で削除します。

  1. Azureポータルの継続的配信のdisconnectをクリックして削除する。
  2. VSTS側のリリース定義を削除する
  3. VSTS側のビルド定義を削除する

まとめ

Azureにデプロイする場合、VSTSからビルド定義を作るとちょっと手順が多いですが、Azure側から作成すると簡単にできますね。