読者です 読者をやめる 読者になる 読者になる

kkamegawa's weblog

Visual Studio,TFS,ALM関係のことについていろいろと書いていきます。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側に設定を行います。

デプロイオプション

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側から作成すると簡単にできますね。

Python 2.7.xをWindowsでビルドする

たまにしかやらないので、忘れてしまうから自分用にメモ。

必要なもの

  • Visual Studio 2008
  • Active Perl
  • TortoiseSVN(コマンドラインツールも必ずインストールします)

OSはVisual Studio 2008がサポートされているものならいいはずです。XP世代のOSを使おうとすると、Active PerlとかTortoiseSVNは一世代以上古いものを入手する必要があります。64bit版のPythonをビルドする場合、ビルド後イベントで生成したPythonを実行するため、64bit OSを使うほうがいいでしょう。

MSがPython 2.7の拡張機能をビルドするために配布しているVisual C++ 2008コンパイラをPython自身のビルドに使えるかどうかはわかりません。

Download Microsoft Visual C++ Compiler for Python 2.7 from Official Microsoft Download Center

ソース入手

公式からダウンロードします。

www.python.org

注意点として、Pythonが依存している外部ライブラリ(OpenSSL,SQLiteなど)は含まれていません。別途取得します。

ソースを展開してできた、Python-2.7.xxフォルダの下にPCBuildフォルダがあります。そのなかにget_externals.batというバッチファイルがあるので、実行します。依存しているライブラリのソースコードをSVN経由でとってきます。なので、TotoiseSVNインストール時にコマンドラインツールも必ず入れてください。

ビルド

Pythoon-2.7.xx\PCの下にVC6とかVC7.1とかあります。VS2008の場合、VS9.0フォルダに移動して、コマンドプロンプトからbuild.batを実行するだけです。標準ではWin32のReleaseビルドがVS9.0フォルダ内に生成されます。オプションをいくつか指定できます。

-c Debug:デバッグ版Pythonが生成されます
-p x64:64bit版Pythonが生成されます(32bit OSでもビルドできますが、最後にPython自身が実行できなくてエラーになります)
-t Rebuild:クリーンビルドします
-d -c Debugと同じ意味です
-e ビルド時にget_externals.batを自動的に実行して、依存しているライブラリをダウンロードします
-k 何らかのサービスなどでPythonをバックグラウンドで実行している場合、自動的に終了させます。

注意点として、DebugとReleaseで異なるフォルダに出力する、ということはやっていないようです。大体ファイル名が違う(デバッグ版は_dがつく)ので区別はできますが、後の作業がめんどくさいので、ビルド前にVS9.0フォルダもしくはamd64フォルダを複製しておくといいと思います。

Visual Studio Team ServiceのLibrary機能で複数の値を一括管理する(28日目)

はじめに

ユーザーIDやパスワードをリリース定義のスクリプトに埋め込まず、外部に定義したいことはよくあります。そういう時、Release ManagementではVariableに設定することで、複数のリリース環境に同じ値を使えます。

そういう時、関連した値をひとまとめに管理したいという要求もよくあります。まだリリースノートが出ていない機能ですが、Libraryはそういう時に役立ちます。

作成

f:id:kkamegawa:20170104070641p:plain

LibraryからAdd variable groupをクリックして、新規のグループを作成します。ユーザーとパスワード、DBへの接続文字列のように関連する値をグループとして管理しましょう。

f:id:kkamegawa:20170104070642p:plain

グループ名と、説明、追加したい名前と値を指定します。パスワードのように表示したくない場合は右端の鍵アイコンをクリックすれば秘密文字列として表示されません。

参照する

f:id:kkamegawa:20170104070643p:plain

リリース定義のVariablesにLink variable groupがあるので、クリックします。

f:id:kkamegawa:20170104070644p:plain

作成したVariable groupが表示されているので、Linkをクリックします。

f:id:kkamegawa:20170104070645p:plain

作成したVariable groupをリリース定義から参照可能になっています。もちろん、Variable groupは履歴管理されていて、誰が編集したか確認できます。

まとめ

関連する複数の値を外だしで一括管理できる新機能Libraryを紹介しました。便利だとは思うのですが、どうせならBuildとReleaseで共通に受け渡しできるといいなと思います。環境変数とかでBuildとReleaseで値を受け渡しできればいいのですが、今の所どうもできないようです。

この辺は将来に期待ですかね。

2016年振り返り

関西方面の生活もだいぶ慣れてきましたが、予想以上に東京行かないですね…。もうちょっと機会があるかなと思ったのですが。来年のde:codeはたぶん行けると思うので、その時はよろしゅうに。

今年は一人アドベントカレンダーなぞやってしまってかなり死ぬかと思いました…。ブログのPV的には昨年比30%くらい伸びたのでびっくりしてます(ネタとしてはニッチなんですが)。Bash on Windowsの話という、一つどかんとでっかい山がありましたが、それを除いても全般的に伸びたようです。

ぼちぼちはじめたVSTSのリリースノート翻訳もわりといいブログの更新ネタになっています。世間様というか自分に役立つネタとしてNuGetパッケージを公開したのもいい勉強になりました。これらのNuGetパッケージは別のOSSを公開するための下準備として作ったものなんですが、アドベントカレンダーやってたおかげで、そちらに時間が取れなくて困ったものです。

アドベントカレンダーネタはもう少し残っているので、次のVSTSのスプリントが公開される前に(もうすでになんか新機能が細々と公開されているようだけど)やり切りたいなと思っています。

延び延びになっていた本をなんとかTFSUGのみんなで出せてよかったです。

アジャイルでやってみた。ウォーターフォールしか知らなかった僕らSIerのスクラム日記

アジャイルでやってみた。ウォーターフォールしか知らなかった僕らSIerのスクラム日記

この都合もあって、しばらく登壇とかありませんでしたが、1月末にぶりしゃぶ食べに…もとい、Hokuriku.netでお話しさせていただきます。今回はちょっと趣向を変えてみようかなと思っています(準備が大変だけど)。

toyama-eng.connpass.com

執筆やイベントは時間の都合がつく限りお受けいたします。

来年はXamarinでアプリ作ることと、伸ばしていたOSSの公開をやろうかなと…できれば3月までに。ではよいお年を!&来年もよろしくお願いします。

追記。今年読まれた記事TOP10。BoW強いですね。

  1. Windows 10のbash on Windowsを試す - kkamegawa's weblog
  2. Windows 10に.NET Framework 3.5を追加する - kkamegawa's weblog
  3. Surface Book と MacBook Proを使い比べてみて - kkamegawa's weblog
  4. Visual Studioに統合されるデータベース開発ツール- SSDT - kkamegawa's weblog
  5. Windows 8にオフラインで.NET Framework 3.5を追加する方法 - kkamegawa's weblog
  6. Windows 10でMS Moneyが動くようになった - kkamegawa's weblog
  7. bitnami Redmine(Windows版)のメール送信設定ではまるところ - kkamegawa's weblog
  8. Windows 7/8.1/Server 2012/Server 2012 R2用PowerShell v5リリース! - kkamegawa's weblog
  9. プログラマ的にWindows 10 Anniversary Updateのうれしいところ - kkamegawa's weblog
  10. ビックカメラタブレットを買った - kkamegawa's weblog