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

kkamegawa's weblog

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

Visual Studio Team Servicesで作業を管理する(4日目)

ALM VSO VSTS

4日目は作業項目をカスタマイズを紹介します。

初期状態

f:id:kkamegawa:20161203205211p:plain

Workタブをクリックすると、Backlog Itemsが初期状態で表示されます。Scrumテンプレートでは、Features(要求される機能)、Backlog(作業内での優先リスト)、Task(実際の作業)という階層で扱います。

Product Backlog単位でスプリント期間中に作りこむ作業の優先順位を決定します。最初から詰め込んだ作業ができるとは思わず、最初は見積もった作業がオーバーすることもよくあります。また、緊急度やビジネス上の価値などを考慮して、チームで優先順位を変えていきます。

特にリリースしたサービスが止まってしまった場合などは最優先で対処しなくてはならないでしょう。そういう作業の優先度をシステム上で見えるようにします。

カンバン仕事術

カンバン仕事術

  • 作者: Marcus Hammarberg,Joakim Sundén,原田騎郎,安井力,吉羽龍太郎,角征典,?木正弘
  • 出版社/メーカー: オライリージャパン
  • 発売日: 2016/03/26
  • メディア: 単行本(ソフトカバー)
  • この商品を含むブログ (5件) を見る

カンバンに特化した本やアジャイル関係の本はいくつも出ているので、詳細はそちらをどうぞ。

VSTSのカンバンはデジタルらしく、Feature,Backlogそれぞれでいろいろ設定ができますので、紹介します。

Features

バックログ

f:id:kkamegawa:20161203205212p:plain

一覧画面とカンバンそれぞれ設定ができます。ウィンドウ内の小さい歯車アイコンをクリックすると、Featuresの設定画面が表示されます。

f:id:kkamegawa:20161203205213p:plain

使用する機能レベルを表示します。Epicsは複数のスプリントをまたがるような大きな機能を作るときに使います。Featuresは要件と思ってもらえばいいと思います。小さいプロジェクトや、Scrumに慣れるまでは非表示でも構わないでしょう。

Backlogを非表示にすることはできません。

f:id:kkamegawa:20161203205214p:plain

作業可能な曜日を設定します。ここはブラックスプリントなので(嘘、実験用だから)、日曜から土曜まで全部入れていますが、通常は月曜から金曜までにします。もちろん特殊難環境で日曜から木曜まで働き、金曜土曜が休みというところはFridayとSaturdayのチェックを外します。

f:id:kkamegawa:20161203205215p:plain

バグをカンバン上に別扱いで表示するかどうかです。ここで出るバグというのはサービスが止まるような致命的な問題、と考えていただいて構いません。つまり最優先に対応しなければならないから、バックログと同じレベルということですね。

f:id:kkamegawa:20161203205216p:plain

一覧画面に表示する項目の追加/削除です。個人的なおすすめはIDで、これは作業項目IDです。IDはFeature, Backlog,Taskすべてで表示することをお勧めします。VSTSのいろんな場所で #番号 と書くと、作業項目番号をリンクすることができます(Gitのコミットメッセージでも有効です)。

「あの作業項目の番号何番だっけ?」といちいちタスクを開く必要がなくなります。

カンバン

f:id:kkamegawa:20161203205221p:plain

Board(カンバン)に切り替えて歯車アイコンをクリックすると、カンバン用の設定ができます。ここでもShow IDをチェックしておくと、ボード上に作業項目IDが表示されるのでわかりやすくなります。

f:id:kkamegawa:20161203205222p:plain

同様に、登録されたフィールドから明示的に表示したい項目を追加できます。例えば、Featureが変更された日付を表示したいならば、Changed Dateを追加します。

f:id:kkamegawa:20161203205223p:plain

カードのスタイルも変更できます。StyleタブでStyle Ruleをクリックすると、指定した条件に一致したカードの色変更ができます。例えば、昨日登録されたタスクが何も変わっていない場合、背景を赤色にするというスタイルを定義した例です。

チームメンバーで決めておけば危ない兆候を視覚的にわかりやすくすることができます。

f:id:kkamegawa:20161203205224p:plain

同様に、特定のタグが付いたFeatureに色付けすることもできます。タグの色付けは少し慣れてからでもいいかもしれません。タグの登録や削除には権限が絡んできますので、だれでも追加/削除できませんから。

f:id:kkamegawa:20161203205225p:plain

列を定義します。初期状態では3列ですが、チーム状況によってはもっと増やしても構いません。最初は3列から初めて、何か困ったら増やすほうがいいでしょう。VSTSを開発しているチームでは7列くらい作っているそうです(バックログだったかもしれませんが)。

f:id:kkamegawa:20161203205227p:plain

NewとDoneの間の列(今回はInProgress列)ではWIP limitを設定できます。これは「チームが仕掛として登録できる数」です。この考えはバックログも同じです。

むやみやたらにチームの稼働を超えたFeatureやBacklogを処理中にしても進むことはありません。メンバーの稼働状態でInProgressに登録できるタスクの数の上限を設定します。もちろん、メンバー数や能力に応じて上下します。

Split ColumnはInProgressをさらにDoingとDoneに分割する、という設定です。Doingは実際の作業中、Doneは「作業は終わったがDoneに移行する前の未レビュー状態」と考えていただければいいと思います。

レビューを受けて、関係者からのOKが出ればDoneに移行して、タスクが完全に終わりとなります。

f:id:kkamegawa:20161203205226p:plain

縦方向に分割できるんだから、横方向も分割できます。Swimlanesという設定がそれです。FeaturesやBacklogは表示順それ自体がタスクの優先度ですが、タスクの種類ごとに分割して認識したい場合があります。

今回の例で出しているキャプチャはよくないのですが、例えば、性能と画面デザイン、モバイルとWeb、それぞれ優先度はあるものの、別の行でまとめて見たいということは良くあります。

そういうときにSwimlanesで仕切るとそれぞれのカンバンが仕切られて見やすくなります。これも少し慣れてから使ってみてください。

Backlog Items

カンバン

Backlog Itemsも同じような設定ができますが、より細かくなります。

f:id:kkamegawa:20161203205228p:plain

Backlog Itemsとバグが同列で並びます。もちろんここでもShow IDにチェックを入れることをお勧めします(Bugも)。

f:id:kkamegawa:20161203205229p:plain

AnnotationsはBacklogに対応するテストとタスクを表示するかどうかです。Backlogがあるからには具体的なテストとタスクがある、ということなので、企保的には表示したままにすることをお勧めします。

f:id:kkamegawa:20161203205230p:plain

バックログに対する手動テストおよび、テスト計画です。関連して設計するか、テスト計画は完全に独立して設計し、関連付けるかという選択です。基本的にはその都度新しいテスト計画を作ることをお勧めします。

作業工数管理

実際、だれがどれくらいの作業を行ったか、またこのスプリントでどれくらいの作業ができるかという管理は重要です。最初からうまくいくこともありませんが、入力データが怪しければそこから先はどうにもなりません。スプリント単位でどんな作業が何時間できるか、登録しておきましょう。

f:id:kkamegawa:20161203205218p:plain

Capacityをクリックすると、各メンバーが該当スプリントで実施する作業内容と作業時間が設定できます。このブログを書くための時間という想定なので、毎日1時間程度です。

f:id:kkamegawa:20161203205219p:plain

開発に1時間、ドキュメントに1時間というように、複数の作業を設定することもできます。

Days offはあらかじめわかっている休日などを指定します。Team Days offはGWや祝日などのまとまった不定期の休みを設定すれば、チームメンバー全員に反映されます。これはチーム管理者の仕事になります。

f:id:kkamegawa:20161203205220p:plain

これで、スプリントの設定までできました。明日からいよいよ作業項目を作っていきます。

Visual Studio Team Servicesの高度な初期設定をする(3日目)

ALM VSTS VSO

はじめに

昨日で初期設定は終わったみたいなことを書きましたが、今日は応用編の初期設定を紹介します。やってもやらなくても構いませんが、慣れたらやってみましょう。

アカウントのトップページの歯車アイコンからテナント全体の設定ができます。この操作はadminアカウント(初期ではテナントを作ったアカウント)のユーザーのみ操作することができます。

チームプロジェクトを追加する

f:id:kkamegawa:20161202211355p:plain

Overviewハブからチームプロジェクトが作成できます。New team projectをクリックします。

f:id:kkamegawa:20161202211356p:plain

プロジェクト名、説明、プロセステンプレート、バージョン管理システムを選択します。初期値がAgileになっていますが、プロセステンプレートはCMMIやScrumを初期値にできます。

セキュリティ設定

f:id:kkamegawa:20161202211357p:plain

Securityハブではグループの構築ができます。Create groupでグループを追加します。ここではテナント全体に影響するセキュリティを設定するので、不要な権限を追加しないように注意してください。初期値のままで問題ないでしょう。

f:id:kkamegawa:20161202211358p:plain

Azure ADで作られたセキュリティグループをそのまま特定の権限として追加できます。Azure AD側のグループから削除したメンバーはそのままセキュリティもなくなります。

新しいプロセステンプレートを作る

Scrum,Agile,CMMIといったプロセステンプレートが用意されていますが、ほんのちょっとこの項目がほしいとか、用語を自分たちのプロセスに合わせたいという要望は非常によくあります。

VSTSではProcessハブから既存のテンプレートを流用してあたらしいプロセスを作り出せます。

f:id:kkamegawa:20161202211359p:plain

Scrumを継承して新しいテンプレートを作ります。…をクリックして、Create inherited processをクリックします。なお、ここでSet as default processをクリックすると、既定のプロセステンプレートがAgileからScrumになります。

必ずScrumでチームプロジェクトを作る場合、ここで変えておきましょう。

f:id:kkamegawa:20161202211400p:plain

継承するプロセステンプレート名を決めます。ここでは単純にInheritScrumにします。Create Processをクリックします。

f:id:kkamegawa:20161202211401p:plain

Createをクリックすると、テンプレートの編集が始まります。結構手間がかかるので、やりたいことを決めておきましょう。

f:id:kkamegawa:20161202211402p:plain

新しいプロセスの概要が表示されます。Users can…は既存のプロジェクトをこのテンプレートで置換できるようにするというオプションです。

f:id:kkamegawa:20161202211403p:plain

Scrumテンプレートそのままでは解決するかどうかわからない課題みたいなものを管理するために、新しい区分"Problem"を作ってみます。もちろん日本語に直しても問題ありません。

色は既存の色とかぶらない色を指定してください。カンバン上で色がついてわかりやすくなります。Createをクリックすると作成されます。

f:id:kkamegawa:20161202211404p:plain

layoutではProblemを登録するときに表示するWebフォームを構築します。フィールド、グループ、ページを使って、データを登録するためのフォームレイアウトを作ります。

ここでは既存のフィールドから選択します。Due date(対応日でしょうか)を選んでみます。

f:id:kkamegawa:20161202211405p:plain

Optionsではこの項目が必須かどうか、日付であれば規定日付を指定します。これで問題なければAdd fieldをクリックすれば入力フォーム上に表示されます。

f:id:kkamegawa:20161202211406p:plain

Fieldsにはこの項目で使えるフィールドの一覧が表示されます。もちろん新しいフィールドを作ることもできます。これらのフィールドはJavaScriptのAPIで使うこともできるようです。

f:id:kkamegawa:20161202211407p:plain

Statusを設定します。初期値、処理中、完了から該当するステータスを選択します。New Statusから新しい状態を追加することもできます。

f:id:kkamegawa:20161202211408p:plain

最初から登録されている不要なステータスは削除します。

f:id:kkamegawa:20161202211409p:plain

名前に対応するステータスを選択します。

f:id:kkamegawa:20161202211410p:plain

登録済みのステータスからプロセスにふさわしい用語を選択します。

f:id:kkamegawa:20161202211411p:plain

backlogのカンバンに表示するかどうかという選択です。

f:id:kkamegawa:20161202211413p:plain

もちろん、既存のフォームにもフィールドを追加できます。同じようにDue Dateを追加します。

f:id:kkamegawa:20161202211414p:plain

Due Dateは必須にします。

f:id:kkamegawa:20161202211415p:plain

Webフォームのどこに配置するかという設定です。ここでは既存のDetailsというグループ内に追加します。

f:id:kkamegawa:20161202211416p:plain

作ったけど不要になったフィールドはここで削除できます。もちろんテンプレート組み込みのフィールドを削除することはできません。

f:id:kkamegawa:20161202211417p:plain

作ったプロセステンプレートのセキュリティを設定します。

ビルド設定

f:id:kkamegawa:20161202211418p:plain

ビルドパイプラインの並列度を指定します。既定で並列なしのエージェントしか使えません。増やすにはCharge purchased qualityをクリックして、marketplaceから購入します。

f:id:kkamegawa:20161202211419p:plain

ここでBuyをクリックすると増やせます。Visual Studio Enterpriseサブスクリプションを持っているユーザーが増えれば増えるはずです。

f:id:kkamegawa:20161202211421p:plain

エージェントプールを構築します。プールはいくらでも作れます。エージェントの実行OSやインストールソフトで作成する、並列度に応じて変えるという方針でやりましょう。ローカルエージェントを構築するには、Download agentをクリックします。

f:id:kkamegawa:20161202211420p:plain

エージェントのダウンロードURLとインストール方法が表示されます。ローカルエージェントを実行するには.NET Coreをインストールしておく必要があります。

f:id:kkamegawa:20161202211422p:plain

エージェントプールはわかりやすい名前にしましょう。ここではmacOS用ということで、macAgentにします。あとはエージェントをインストールすれば、このエージェントプールに表示されます。

拡張機能

VSTSに拡張機能を追加することで、機能拡張ができます。最初は何も入っていません。

f:id:kkamegawa:20161202211423p:plain

Browse Marketplaceをクリックすると、Marketplaceが表示されます。いろいろありますが、最近追加された、Work Item Searchを追加しましょう。これを追加すると、Work Itemで日本語検索ができるようになるので便利です。

f:id:kkamegawa:20161202211424p:plain

Installをクリックします。ちなみにTFSとも共通で使える拡張機能もありますが、Work Item SearchはSQL ServerにWord breakerを追加すれば大体同じ機能が使えます。

f:id:kkamegawa:20161202211425p:plain

インストールするテナント(Account)を選択します。Confirmをクリックします。

f:id:kkamegawa:20161202211426p:plain

追加できればCloseをクリックします。

f:id:kkamegawa:20161202211427p:plain

Work Item Searchが追加されました!

f:id:kkamegawa:20161202211428p:plain

不要になった場合、Uninstallをクリックします。一時的に無効にしたい場合はDisableをクリックします。

f:id:kkamegawa:20161202211431p:plain

ブラウザをリロードすれば、上にWork Item Searchの検索ボックスが表示されます。

f:id:kkamegawa:20161202211432p:plain

a: 名前でアサインされた人のアイテムが検索できます。便利になりました。

性能

VSTSを多くのユーザーで共有している場合、負荷がかかると、一時的に性能低下することがあります。Usageハブでアクセス履歴と、性能低下状態の確認ができます。

f:id:kkamegawa:20161202223002p:plain

アクセス履歴ですね。

f:id:kkamegawa:20161202211430p:plain

もしも遅くなった操作がある場合、ここに表示されます。リクエストのキャンセルではなく、遅延になるそうです。しばらく待てば遅延のペナルティは復帰するとのことです。

まとめ

最初は使わなくても構わない設定ばかりですが、高度に使いこなそうとすると、必要になる設定を紹介しました。VSTSを活用していく場合、ぜひ使ってみてください。

Visual Studio Team Services初期設定をするその1(2日目)

ALM VSO VSTS office365

Azure ADのユーザー管理

f:id:kkamegawa:20161201204002p:plain

Azureポータルに組織アカウントでログインすると、ユーザーやグループを作成することができます。ここで作成したグループはそのままVSTSのグループとして使用できます。

  • VSTS用グループを作成
  • Azure ADにユーザー登録&グループ登録

という流れになります。小規模な環境であればポータルでやるのもいいですが、大きなところになればPowerShellなどで自動化を検討しましょう。

f:id:kkamegawa:20161201204003p:plain

Azure ADで作ったグループはVSTSのチームにアクセスするグループとしてそのまま使えます。

ユーザー管理

f:id:kkamegawa:20161201203949p:plain

VSTSを使用するユーザーはアカウントトップページにあるUsersから登録します。MSアカウントを使っている場合、ここでMSアカウントを選択しますが、組織アカウントを使っている場合、Azure ADのユーザーをそのまま追加できます。

azure.microsoft.com

登録したユーザーは何らかのライセンスを割り当てる必要があります。大雑把に分けて、無料で使えるアカウント、有料の一時払いと年払いという区分けです。

無料アカウント(Stakeholder)

お客様などの進捗のみ管理したい場合に割り当てます。無料でカンバンやタスクの優先順位変更のみできます。ビルドやテストの機能は一切ありません。

Basic(5人まで無料)

コードのチェックインなどの基本的な機能は使えます。6人目からは有料です。テスト機能は使えません。

Visual Studioサブスクリプション

ProfessionalかEnterpriseかによって多少違います。また、Azureの料金と一緒に月額払いすることもできるので、一時的に開発メンバーを増やしたいというときに非常に便利です(特に日本のSIer)。

Enterpriseのライセンス数に比例してビルドパイプラインの並列数が増えます(既定で1ライセンス付属)。

アカウントセキュリティ設定

f:id:kkamegawa:20161201203948p:plain

アカウントごとに設定します。タイムゾーン、URL、認証設定、外部アカウント(MSアカウントなど)のアクセスを許可するか、という点です。

Alternate authenticationは個別のIDとパスワードを指定してVSTSの認証を行うための機能ですが、セキュリティ上可能であれば無効にすることをお勧めします。今はPAT(Personal Access Token)やSSHでの認証ができるようになったので、必要性が低下しました。

チーム初期設定

f:id:kkamegawa:20161202060358p:plain

Overviewでチームの初期設定ができます。プロセスや詳細を確認できるほか、"New Item"をクリックすると、プロジェクトチームの中にさらにサブチームを作ることができます。

f:id:kkamegawa:20161202060359p:plain

チーム名とわかりやすい説明を指定します。そして、プロジェクト内での権限を設定します。Contributorsはコードの読み書き権があります。Readersであれば読み取りという権限が設定されています。

もちろん、ほかの権限を作ることもできます。Create an area path with the name of the teamをチェックしていれば、そのチーム用のarea pathが構築されます(後述)。

f:id:kkamegawa:20161201203950p:plain

WorkタブにあるIteration(イテレーション)とAreaを設定します。イテレーションはスクラムのスプリントと考えてください。メニューはAgileの用語が基本のようなので、こういうところがちょいちょいありますが、気にしないでください。

f:id:kkamegawa:20161201203951p:plain

Start DateとEnd Dateを設定します。3週間とか一か月とかの期間を設定します。最初にプロジェクトの終了までの期間を設定しています。今回はAdvent Calendarのデモ用途なので一か月というありえない工程組んでいますが、こんな短くしないようにしましょう(^^;。

f:id:kkamegawa:20161201203952p:plain

スプリントを一週間で同じように設定しています。この設定はカンバン(Board)の挙動に影響します。

個人的なおすすめはスプリントの下にさらにスプリントという階層を付けないことです。例えば2016年度というスプリントを作って、2016年1月とか2016年2月という孫階層まで作ると、後の操作が結構大変になります。

親子までにしておきましょう。

f:id:kkamegawa:20161201203954p:plain

次はAreaを設定します。これは実際にどんな仕組みを作るか、という種類分けにしておきます。とはいえ、アプリケーションのdllやexe単位にすると細かすぎます。例えば、バッチとか、Webサーバーとか、アプリケーションをデプロイする場所に対応させるとやりやすいかと思います。

最初はざっくりと、必要に応じて詳細な孫階層を作ればいいと思います。すでに割り当てたタスクを変更もできますよ。

f:id:kkamegawa:20161201203955p:plain

…をクリックすると、孫階層やアクセスするセキュリティの設定もできます。チーム内にさらにサブチームを作り、例えばWebフロントのみ担当するチームというセキュリティ設定もできます。

f:id:kkamegawa:20161201203956p:plain

セキュリティ設定ではどのグループにどんな権限を割り当てるか設定できます。最初は変更する必要ないでしょう。

Contributorsはコードの変更権限がある、Readersは読み取りのみです。

通知設定

f:id:kkamegawa:20161201203957p:plain

VSTSでは各種条件に一致した場合、メール通知させることができます。初期設定ではコードレビュー依頼のみですが、個人的なおすすめを紹介します。

f:id:kkamegawa:20161201203958p:plain

チーム全員に設定されるTeam Alertと自分のみのMy Alertの二種類選択できます。Newをクリックして、Team AlertのWork ItemからA work item is assigned me(私にタスクが割り当てられた)を選択して、OKをクリックします。

f:id:kkamegawa:20161201203959p:plain

これで問題なければOKをクリックします。これでチームメンバーの誰かにタスクが割り当てられたときに割り当てられた人に対してメール通知が行われます。

アイテム保持ポリシー

f:id:kkamegawa:20161201204000p:plain

Testをクリックして、Retantionでテスト実行後何日間保持しておくかという設定をします。既定で30日です。

まとめ

これで最低限のチーム準備ができました。Azure ADにユーザーとグループを登録しておけば、自動的にVSTS側に反映されます。

また、今後出てきますが、Azure ADに登録したAzureサブスクリプションに対してデプロイを行うことや、Power BI, Teamsなどとの連携も可能になっています。

Azure ADを中心とした連携は非常に便利なので、ぜひ使ってみてください。

Visual Studio Team Servicesを構築する(1日目)

VSTS VSO ALM

はじめに

今日からAdvent Calendarがはじまりますね。特に参加はしていないですが、Visual Studio Team Services(以下VSTS)の全機能について解説していこうと思います。日付が合えばほかのAdvent Calendarに相乗りの形で公開します。現在想定しているペースではたぶん25日で終わらないので、終わってもちまちま続けていきます。

幸い次の機能強化は一月中旬だそうです。それまでには終わると思います。

アカウント

VSTSを使うときはMSアカウント(個人管理)か、組織アカウント(Azure AD/Office 365)のいずれかを使う必要があります。ほとんどの解説ではMSアカウントを前提にしていますが、本連載ではすべて組織アカウントで解説します。

機能強化は基本的に組織アカウント前提で行われているような節があります。実際、この検証のためにテナントを作ったのですが、組織アカウントでの運用は非常に便利です。Office 365をすでに運用されている場合、組織アカウントでテナントを作成されることをお勧めします。

azure.microsoft.com

会社で使う場合の考慮事項に関しては以前書いたので、こちらも参考にしてください。

kkamegawa.hatenablog.jp

では、組織アカウントでセットアップします。

セットアップ

Visual Studio クラウド サブスクリプション - Visual Studio

もしもMSDNサブスクリプションを持っている場合、MSDNの枠で使用できますので、必ずMSDNの特典と組織アカウントを関連付けておきましょう。今はMSDNからVisual Studioサブスクリプションへ各種移行している最中なので、既存のユーザーの方とか少し混乱するかもしれません。

f:id:kkamegawa:20161130212045p:plain

まず、visualstudio.comからサインアップします。真ん中にあるVisual Studio Team Servicesの「無償利用の開始」をクリックします。

f:id:kkamegawa:20161130212046p:plain

サインイン画面で組織アカウントを使ってログインします。ちなみにWindows 10を使っており、Windows 10を組織アカウントに追加していればシングルサインオンされます。一台Azure ADに登録しているので、実際にシングルサインオンする様子も今後紹介します。

f:id:kkamegawa:20161130212047p:plain

テナントを作成します。アカウント名は早い者勝ちなので、注意してください。コード管理はGit(分散型)か、Team Foundation バージョン管理(TFVC/中央型)のいずれかを選択することができます。

TFVCもGitも本質的にできることは変わりありません。Subversionに慣れ切っている人はTFVCで始めると違和感があまりないと思います。ただ、Gitに関しては今どんどん投資され、UIおよび機能強化がすごいペースで行われています。便利な新機能を使いたいときはGitもいいかもしれません。

Gitに関する細かい話はしないので、Gitの専門書を読んでください。Tower,Git for Windows,Eclipse,IntelliJ,Xcodeといった、標準的なクライアントを使うことができます。Windows以外のプラットフォームを使う環境であればGitのほうが面倒がないと思います。

チームプロジェクトごとに一つのTFVCと複数のGitリポジトリを作成することができます。用途に応じてリポジトリを複数作っていただいて構いません。

接続する人は面倒ですが、チームプロジェクト名は後で変更することもできるので、最初は気軽に始めましょう。

f:id:kkamegawa:20161130212048p:plain

プロセステンプレート、ホストする地域(Azureのリージョンに対応します)、連絡先や名前を登録します。

プロセステンプレートはScrum,Agile,CMMIのいずれかが選択できます。簡単なカスタマイズができますが、今回はScrumを選択します。本格的にスクラムで開発したいという場合、プロのスクラムマスターの方と一緒に3-4回くらいスプリントを回してみてください。

何もかも変えるのはかなり大変なので、テンプレートを自分たちの解釈でやっても全く問題ないと思います。VSTSは結構うまく動いてくれます。Feature,Product Backlog,Taskといった階層がありますが、WBSの大中小と割り当てて使ってもいいでしょう。

プロジェクトをホストする地域は多少選べますが、オーストラリアはオーストラリアに納税している人作ることができない(招待してもらって利用することはできます)ので、注意してください。IPアドレスから自動的に判定されているので、「インドのオフショアの方が中心で使う」という理由でもない限り、変える必要はありません。

f:id:kkamegawa:20161130212050p:plain

続行をクリックしてしばらく待つと、作成完了です!チームとコードの紹介画面ですね。

f:id:kkamegawa:20161130212049p:plain

初期画面はこんな感じです。ここから始めよう!と思うかもしれませんが、結構初期設定やるところがあるんですよ。明日は細かい初期設定を紹介します。

NuGet.org公開前にVSTSのパッケージ管理機能でテストする

DevOps NuGet VSTS TFS

はじめに

VSTS/TFS 2017にはNuGetパッケージサーバー機能が提供されています。VSTSの場合、最初の5名までは無料です。パブリックに公開するようなパッケージではnuget.orgを使えばいいのですが、内部でパッケージの開発&テストするときにはVSTSのパッケージサーバー機能を使うと便利です。

いくつかパッケージ公開していますが、いずれも確認用はVSTSでテストして、問題なければnuget.orgに公開しています。

フィード作成

f:id:kkamegawa:20161127084348p:plain Package Managementからフィードを作成します。用途に応じて好きに設定します。チームメンバーか、だれでも使えるか。

誰でもパッケージを追加できるか、ビルド時のみパッケージ追加か。要はVSTSもしくは外部リポジトリ(GitHubなど)にあるソースをビルドして、VSTSに取り込むという方法です。

最近追加された新機能でnpmもサポートされました。

ソースファイル

f:id:kkamegawa:20161127084344p:plain

NuGetパッケージはこんな感じで作っています。NuGetパッケージごとにリポジトリ作っておけばよかったかなと思いつつも、ぼっちプロジェクトなのでいいかなと。GitHubにもミラーしています。

github.com

github.com

ビルド

ビルドはdevブランチとmasterブランチの二つに対して設定しています。devにpushすると、VSTSのCIで、VSTSのパッケージ管理に登録されます。masterにpushすると、nuget.orgに公開しています。

f:id:kkamegawa:20161127084345p:plain

こちらがdevブランチをビルドした時のNuGet公開タスク設定。フィードにInternal NuGetとfeed URLを指定するだけでOKです。

f:id:kkamegawa:20161127084350p:plain

devブランチをビルドするときはパッケージ番号にRelease番号を付けています。これは同じバージョン番号でNuGetパッケージを上書きできないという仕様によるものです。正式版はセマンテックバージョンに従って手動で上げていきます。

正確にはこんな風にバージョン番号をファイルに記録しているので、この番号を変更するだけですが。

Python27Dev_NuGet/VERSION at master · kkamegawa/Python27Dev_NuGet · GitHub

f:id:kkamegawa:20161127084346p:plain

masterブランチのNuGet PublisherタスクではExternal NuGet Feed(nuget.org)を指定しています。これは外部サービス機能で事前にAPI KEYを登録しておきます。

f:id:kkamegawa:20161127084347p:plain

devブランチをビルドすると、こんな感じで、NuGetフィードがVSTSに登録されます。不要になったものはDeleteで消せます。Unlistすると、表示もされなくなります。

フィードに接続する

f:id:kkamegawa:20161127084349p:plain

Package Managementの右上にあるConnect to feedをクリックすると、VSおよび、npmで接続するための方法が表示されます。

Visual StudioではPackage source URLをこんな風に登録します。

f:id:kkamegawa:20161127120605p:plain

オプションのNuGetパッケージマネージャーにある、パッケージソースに登録します。これでInstall-packageコマンドレットで自動的に登録が可能になります。

npmの場合、npmに対応した認証マネージャーがあるので、connect to feedの画面でダウンロードしておいてください。

VSTS/TFSのPackage Manager機能は非公開および、内部でテスト用のパッケージ作るとき便利ですよ。

Visual Studio Team Services 2016/11/23の更新

Git NuGet VSTSリリース

感謝祭期間中だというのに、いつも通りVSTSの更新が行われました。前回からGoogle翻訳を使って下訳→チェック修正しているので、かかる時間がずいぶん短くなりました(^^;。

Gitのブランチポリシーの挙動が少しユーザーの期待と違っていたので、期待されている挙動に変更したそうです。従来の挙動が望ましい場合は、設定で変更できます。

いよいよLinux Hosted poolが始まりました。これでDockerのためにLinuxエージェントをわざわざ立てる必要がなくなるので、助かりますね。また、これに合わせて、ライセンスモデルが二週間以内に変わり、従来のエージェント数とビルド時間ではなく、同時並列数に依存するモデルに変わるのだそうです。無料枠は従来通りですね。おそらく概ね安くなるのではないか、とのことです。

pull requestの詳細をMarkdownで書けるようになったのも嬉しいですね。ますますGitHub化が(ry。

他のチームプロジェクトの成果物をリンクできるようになったのも地味に嬉しい強化ですね。大きなアプリケーションなどで別チームプロジェクトで作っている、フレームワークのNightlyをリンクして試す、ということもできるようになりました。

ではまた三週間後。

(11/30追記)

blogs.msdn.microsoft.com

Brian Harryのブログによると、今年はこのSprint 109で終わり。予定通りなら年内にSprint 110が出る予定だったけど、スキップして、来年1月中旬のSprint 111に回すのだそうです。今展開しているSprint 109は12/2までに全部のテナントにリリースが完了するそうです。けっこうかかりますね。

来年まで更新ないようで、助かった…。

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

Visual Studio 2017 RCの再インストールが必ず失敗する場合の対処

VisualStudio

※:RC版の話なので、正式版では直っている可能性があります。

ちょっとした事情でVisual Studio 2017 RCを削除したのですが、問題が解決したので、再インストールしようとしたところ、こんなエラーが出て、どうしても実行できません。

[3874:0021][2016-11-23T06:57:22] Error 0x80131509: 場所 Microsoft.VisualStudio.Setup.Engine.VerifyInstallationPath(IServiceProvider services, String installationPath, IInstance instance, IQuery query) 場所 Microsoft.VisualStudio.Setup.Engine.Install(Product product, String destination, CancellationToken token)指定されたインスタンス 'aa78a46b' を、既存のインスタンス 'f90d13a0' と同じ場所または子ディレクトリにインストールすることはできません。

シングルクォートで囲まれた部分は環境によって変わります。なんだこれ、と思ったのですが、フィードバックで報告しようと思ったら、すでに答えがありました。

  1. インストーラーを終了(しばらく待つ)
  2. C:\Program Files (x86)\Microsoft Visual Studio\2017 をさっくり削除
  3. C:\ProgramData\Microsoft\VisualStudio\Packages_Instances にある、ログに出力されているフォルダ(今回の場合は'f90d13a0')を削除

f:id:kkamegawa:20161123093938p:plain

探すとこういうフォルダができているはずです。このフォルダで判定しているようですね。

f:id:kkamegawa:20161123093939p:plain

で、こういう問題に当たった時、インストーラーの右上の吹き出しから「提案の送信」か「問題の報告」をクリックします。

f:id:kkamegawa:20161123093936p:plain

フィードバッククライアントが表示されるので、適当にありそうな用語を「英語で」検索します。今回の場合はインスタンスというエラーが出ているので、Instanceで探してみます。

f:id:kkamegawa:20161123093937p:plain

すると、こんな風に関連しそうなQ&Aが出てきます。今回の場合はここで解決策も見つかったのでそれが上の手順になります。たいていすでに報告済みな現象だと思いますので、まずは探してみてください。英語じゃないと出てこないのが若干ハードル高いかもしれませんが…。