Visual Studio Team Services の最新情報: 2017 年 8 月のまとめ


執筆者: Buck Hodges (Director of Engineering, VS Team Services)

このポストは、8 月 30 日に投稿された What’s brewing in Visual Studio Team Services: August 2017 Digest の翻訳です。

 

このブログ シリーズでは、Visual Studio Team Services (VSTS) に関する最新情報をお届けします。皆様はここで 3 週間分のリリース情報をご確認いただけます。Visual Studio Team Services は効率的な継続的インテグレーションと Azure へのリリース パイプラインを作成するのに最適な DevOps ツールです。

今月は、新しいリリース定義エディター、新たに導入された Wiki に関する更新、プル リクエストの機能強化、独自の VSTS 用拡張機能の開発をすぐに始める方法などをご紹介します。それでは、最新リリースで強化された機能について見ていきましょう。

新しいリリース定義エディター

新しいリリース定義エディターのプレビューが開始されます。この機能はしばらく前にリリースされた新しい CI エディターがベースになっており、マイクロソフトが目指している全体的な方向性がよく表れています。単にエクスペリエンスがわかりやすくなっただけでなく、構造的な変更によってリリース プロセスが視覚化されるようになりました。これにより、システムについて考えているとおりにリリース作業を行うことができます。今後は、リリースの進捗状況を視覚化できるように、ランタイム ビューにも同様のアプローチを導入する予定です。マイクロソフトでは、充実した使いやすい視覚化機能であらゆるデータを最大限に活用できるようにするための取り組みを製品全体で進めています。

パイプラインの視覚化

エディターのパイプラインでは、デプロイメントがリリース内でどのように進行するかが視覚的に表示されます。成果物はリリースで使用され、環境にデプロイされます。環境のレイアウトとリンクには、各環境で定義されているトリガー設定が反映されます。

release pipeline visualization

コンテキストに応じた構成 UI

成果物、リリース トリガー、デプロイメント前後の承認、環境プロパティ、デプロイメント設定を、コンテキストに応じて容易に構成できるようになりました。

Relesae in-context configuration

デプロイメント テンプレートの適用

環境を新規作成するときに、主なテンプレートのリストが表示されます。

Release templates

タスクとフェーズ エディターの機能強化

新しいビルド定義エディターの強化機能が、リリース定義エディターでも使用できるようになりました。タスクを検索して、それを [Add] ボタンまたはドラッグ アンド ドロップで追加できます。また、ドラッグ アンド ドロップでタスクの順序を変更したり、クローンを作成したりもできます。

Release task and phase editor

Jenkins CI でのリリースのコード情報

マイクロソフトでは、Jenkins などの主要な CI システムとリリースをさらに統合したいと考えています。今回の更新では、CI ビルドが VSTS で作成されている場合のみ、コードのコミットが [release summary] タブで表示されるようになりました。この機能により、リリースを実行しているエージェントから Jenkins サーバーにアクセスできる場合、Jenkins CI の成果物のコード情報も確認できるようになります。

Code info in Release with Jenkins

[Code] ハブのリリース状態バッジ

コミットがお客様の運用環境にデプロイされているかどうかを把握したい場合に、どのビルドでコミットが実行されているかをまず特定し、次にそのビルドがデプロイされているリリース環境をすべて確認できるようになりました。このエクスペリエンスは、[Code] ハブの状態バッジにデプロイ状況が統合されて、コードのデプロイ先の環境が一覧で表示されることで実現されています。すべてのデプロイメントについて、デプロイメントに含まれていた最新のコミットに状態が掲示されます。コミットを (複数環境の) 複数のリリース定義にデプロイする場合、それぞれにバッジのエントリが存在し、各環境の状態が表示されます。これにより、コード コミットのデプロイ状況が簡単に追跡できるようになります。

release status badge

Ansible 拡張機能

Ansible (英語) と統合された、ビルドやリリース タスクを含む新しい拡張機能 (英語) がリリースされました。この拡張機能では、インベントリ ノードの特定のリストに記載されたプレイブックをコマンド ライン インターフェイスから実行することができます。Ansible では、構成、デプロイメント、オーケストレーションの手順を YAML 形式で記述したプレイブック (英語) を使用します。それぞれのプレイブックは、ホストのグループを一連のロールにマッピングします。それぞれのロールは、Ansible タスクの呼び出しで表されます。インベントリ (英語) ファイルには、Ansible からアクセスされるホスト ノードの説明が記述されています。

タスクを実行するには、プレイブックインベントリ ファイルがプライベートの Linux エージェント、または Ansible 自動化エンジンがインストールされているリモート マシンのいずれかに配置されている必要があります。Ansible がリモート マシンにインストールされている場合は、SSH エンドポイントをセットアップする必要があります。インベントリは、動的インベントリまたはホスト リストとしてインラインで指定することもできます。

configure Ansible extension

Wiki 編集エクスペリエンスの機能強化

7 月にお伝えしたように、VSTS の各プロジェクトで専用の Wiki がサポートされるようになりました。この Wiki に引き続き機能強化が行われています。ここでは、最新の改良点について説明します。

新しい Wiki 編集エクスペリエンスでは、マークダウン形式の HTML タグがサポートされるようになりました。

Wiki HTML tags

また、マークダウン フォルダーの画像のサイズを簡単に変更できます。

Wiki resize image

Wiki の改訂バージョンの取り消し

Wiki を使いこなすようになると、誤って意図しない変更を保存してしまうこともあります。改訂バージョンの詳細に移動して [Revert] ボタンをクリックすると、Wiki ページへの変更内容を元に戻せます。

revert wiki edit confirmation

詳細については、Wiki のスタート ガイド (英語) を参照してください。

Git のプル リクエスト ステータス拡張機能のパブリック プレビュー

ブランチ ポリシー (英語) はコード レビュー以外に自動ビルドや自動テストでも利用でき、コードの品質向上に役立ちます。これまでは、ブランチ ポリシーが使用できるのは VSTS からネイティブに提供された統合機能のみに限られていましたが、新しい PR Status API とそれに対応するブランチ ポリシーを使用すれば、サードパーティのサービスでもネイティブな VSTS 機能とまったく同様に PR ワークフローに参加できます。

サービスからプル リクエストを Status API に発行すると、新しい [Status] セクションの [PR details] ビューにすぐに表示されます。[Status] セクションには説明が表示され、サービスから提供される URL へのリンクが作成されます。また、ステータスのエントリでは、Web 拡張機能で新たに追加された操作に対応した操作メニューもサポートされています。

pull request

ステータスだけで PR の完了がブロックされることはありません。これはポリシーによって行います。PR のステータスを発行すると、ポリシーを構成できます。ブランチ ポリシーのエクスペリエンスからは、[Require approval from external services] という新しいポリシーを使用できます。[+ Add service] をクリックしてプロセスを開始します。

add service status for pull request

このダイアログでは、ステータスを発行するサービスをリストから選択し、適切なポリシー オプションを選択します。

branch policy status dialog

ポリシーを有効化すると、ステータスが [Policies] セクションの [Required] または [Optional] の該当する方に表示され、適宜 PR が強制的に完了されます。

Status API の詳細を確認し、自分で試してみる場合は、ドキュメント (英語)サンプル (英語) を参照してください。

プル リクエスト完了時の作業項目の自動完了

作業項目を PR にリンクしている場合 (皆様はリンクしていますよね)、最新状態が簡単に維持されるようになりました。PR を完了する際に、PR が正常にマージされた後でリンクされた作業項目を自動的に完了するオプションを使用できます。ポリシーを使用している場合に PR の自動完了を設定すると、これと同じオプションが表示されます。今後は、PR の完了後に忘れずに作業項目に再度アクセスして状態を更新する必要はありません。VSTS がユーザーの代わりに行います。

Complete work items via pull request

プル リクエストの説明やコメント内のタスク リスト

PR の準備中やコメントの入力中に、追跡したい項目がいくつかあり、結局そのためにさらにテキストを編集したり複数のコメントを追加したりしなければならない場合があります。PR 作成者やレビュー担当者が説明内や 1 つにまとめられたコメント内で To-Do リストの進捗状況を追跡するには、軽量なタスク リストを使用すると便利です。それには、マークダウン ツール バーをクリックするか、選択したテキストに書式を適用します。

pull request task list

タスク リストを追加したら、チェック ボックスをオンにするだけで項目に完了のマークをつけることができます。マークダウンでは [ ][x] で表され、コメントに格納されます。詳細については、マークダウンのガイド (英語) を参照してください。

Pull request task list complete

プル リクエストのコメントへの "いいね"

支持したい PR コメントがある場合は、[like] ボタンをクリックするだけでそれを表明できます。ボタンにマウス ポインターを合わせると、コメントに "いいね" を付けたユーザーがすべて表示されます。

Like pull request comments

古いブランチの整理

不要になったブランチを削除してリポジトリを整理すると、チーム メンバーが作業対象のブランチを探しやすくなったり、適度な細かさでお気に入りを設定しやすくなったりします。しかし、リポジトリ内のブランチ数が多い場合、どのブランチが活動しておらず削除できるかを見極めるのは一苦労です。これを解決するために、「古い」ブランチ (3 か月以上経過したコミットを指しているブランチ) が特定しやすくなりました。古いブランチは、[Branches] ページの [Stale] ピボットに表示されます。

Stale branches

削除されたブランチの検索と再作成

ブランチが誤ってサーバーから削除された場合、何が起こったかを明らかにすることは困難です。そこで、削除されたブランチを検索して、だれがいつ削除したかを確認し、必要な場合は再作成できるようになりました。

削除されたブランチを検索するには、ブランチの検索ボックスにブランチの完全な名前を入力します。そのテキストに一致するものがあれば、既存のブランチが返されます。削除されたブランチのリスト内では、完全一致を検索するオプションも使用できます。リンクをクリックして、削除されたブランチを検索します。

Search deleted branches

一致するブランチがヒットしたら、だれがいつ削除したかが表示されます。また、このブランチを復元することもできます。

Restore deleted branch

ブランチを復元すると、最後に指していたコミットで再作成されます。ただし、ポリシーやアクセス許可は復元されません。

作業項目のプロセスのコピー

プロセスを新規作成する場合や、プロセス変更の準備やテストを行う場合に、プロセスを継承したコピーを作成して雛形として使用できます。

copy work item process

1 つまたは複数のチーム プロジェクトで使用されているプロセスを変更すると、その変更は即座にそれぞれのチーム プロジェクトに反映されます。しかし、これでは不都合な場合もあります。以下の手順に従うと、プロセスのコピーに変更を加えて、すべてのチーム プロジェクトにロールアウトする前に変更内容をテストすることができます。

  1. 変更するプロセスのコピーを作成します。
  2. コピーして作成したプロセスに変更を加えます。このプロセスを使用しているチーム プロジェクトは存在しないため、変更を加えても影響が出ることはありません。
  3. テスト プロジェクトをまだ作成していない場合は、コピーして作成したプロセスからテスト プロジェクトを作成し、変更内容をテストします。テスト プロジェクトを作成済みの場合は、コンテキスト メニューから [Change team project to use <プロセス名>] オプションを選択すると、テスト プロジェクトのプロセスを変更できます。
  4. 変更内容を適用するチーム プロジェクトのプロセスを変更し、変更をデプロイします。コンテキスト メニューから [Change team project to use <プロセス名>] オプションを選択します。
  5. 必要に応じて、元のプロセスを無効化または削除します。

かんばんボードの最終列の順序を改善

作業項目の状態にカスタムの項目を追加した場合、かんばんボードの最終列は最も早く終了したカードの順に表示されます。マイクロソフトは、直近に終了したカードが上位に表示された方がさらに便利になるのではないかと考えました。

この動作は、かんばんボードの最終列が [Closed Date] フィールドの降順に並ぶ仕様に関連しています。各プロセス (Scrum、Agile、CMMI) では、作業項目の種類ごとに、状態が [Closed] または [Done] になったとき (プロセスや作業項目の種類による) に [Closed Date] フィールドに値が設定されるというルールが決められています。しかし、ユーザーがカスタムの状態を追加した場合、その新規の状態に対応して [Closed Date] フィールドに値を設定するルールが自動的に追加されることはありません。作業項目の状態が新規の状態から [Closed] や [Done] に変更されると、[Closed Date] の値は空になります。クエリ エンジンでは、降順で並べる場合、空の値は上位に配置されます。このため、かんばんボードでは、最も早く終了したカードが上位に表示されます。

まず、カスタムの状態を追加した場合に、作業項目に適切なルール セットが追加されるようになりました。今後は、作業項目を終了したときに [Closed Date] に空の値が設定されることはなくなります。既に終了した既存の作業項目に値が再設定されることはありません。また、直近に終了したカードが確実にかんばんボードの上位に表示されるように、かんばんボードの最終列の順序付けロジックが更新され、[Closed Date] フィールドの値が空のカードは下位に表示されるようになりました。

Analytics 用 Velocity ウィジェット

Analytics 拡張機能 (英語)Velocity ウィジェットが追加されました。

この強力なウィジェットを使用すると、ストーリー ポイント、作業項目数、任意のカスタム フィールドでチームのベロシティをグラフ化できます。さらに、高度なオプションを使用すると、チームの成果と計画を比較したり、完了が遅延した作業を強調表示したりできます。

Velocity Widget

バックログ ビューでベロシティ グラフを表示する機能のほかに、Velocity ウィジェットには以下のような機能があります。

  • 現在のチームだけでなく任意のチームのベロシティを表示する。
  • ストーリーのバックログだけでなく、任意のバックログ レベルまたは作業項目の種類についてベロシティを表示する。
  • ストーリー ポイントだけでなく、任意のフィールドの合計値または作業項目の種類の数からベロシティを計算する。
  • 計画と実際の状況の比較を表示し、計画どおりに成果が挙がっているか確認する。
  • 完了が遅延した作業をスプリント後に強調表示する。
  • 1 のサイズのタイルにベロシティの平均を表示する。

Analytics 拡張機能 (英語) をまだインストールしていない場合は、インストールしてから Velocity ウィジェットにアクセスしてください。Lead Time、Cycle Time、Cumulative Flow Diagram の各ウィジェットもご利用いただけます。

なお今後数か月以内に、Burndown、Burnup、Trend などの Analytics 拡張機能用ウィジェットがリリースされる予定です。

今月の拡張機能: SpecFlow+ LivingDoc

SpecFlow+ LivingDoc (英語)Marketplace (英語) で公開されました。「Living Documentation」は、常に最新の状態が維持されたわかりやすいシステム ドキュメントを表す際に使用される言葉です。Gherkin (英語) で記述されたフィーチャ (feature) ファイルがその良い例で、特定のシナリオで想定されているアプリケーションの動作が自然言語で説明されています。自然言語で仕様を説明することで、あらゆる担当者 (業務、開発、テスト、要件など) が対等な立場で仕様について理解し議論することができます。こうした仕様も、システム ドキュメントの重要な部分を占めており、BDD や Specification by Example などのアジャイル開発手法で広く使用されています。

多くの .NET 開発者が、Gherkin で記述されたテスト シナリオを Visual Studio で自動化する際に、オープン ソース プロジェクトの SpecFlow (英語) を使用しています。しかし、これらの Gherkin ファイルはプレーン テキスト形式でありながら、通常はコード リポジトリに保存され多くのチーム メンバーはアクセスできません。Visual Studio の SpecFlow 拡張機能では Visual Studio で Gherkin 構文の強調表示がサポートされていますが、業務部門の担当者をはじめ Visual Studio にアクセスできない担当者もいます。

SpecFlow+ LivingDoc はこの問題を解消し、VSTS のすべてのチーム メンバーが Gherkin で記述された仕様にアクセスできるようにします。SpecFlow+ LivingDoc はオプションの有料拡張機能の SpecFlow+ (英語) シリーズの一部で、フィーチャ ファイルを取り込んで解析し、VSTS で表示する際に構文を強調表示したり、書式を設定したりします。これにより、書式が設定されていないプレーン テキストのフィーチャ ファイルよりも大幅に理解しやすくなります。

書式設定には次のようなものがあります。

  • Gherkin キーワードの構文の強調表示
  • Given/Then/When セクションの背景色の変更
  • マークダウンとして埋め込まれている画像のサポート

spec flow

独自の拡張機能の開発をすぐに始めるには

マイクロソフトではこの数年の間に、.NET (英語) 用クライアント ライブラリ (.NET Framework と .NET Core アプリの両方に対応) や Node.js (英語) 用クライアント ライブラリなど、VSTS での拡張と統合を目的とする機能を多数導入してきました。また、Web エクスペリエンスの拡張を可能にする拡張モデルも作成しました。

これだけ選択肢がいくつもあると、開発を始めるにあたって必要となる要素を把握し、それらをいかに適切に組み合わせるかが課題となります。そこで、マイクロソフトでは統合ドキュメント (英語) を大幅に改訂しました。また、ドキュメントのさらなる改訂も近いうちに予定しています。それでも、ドキュメントだけでは不十分な場合もあります。

新たに公開されたブログ記事「新たな VSTS 拡張機能開発への最短の近道 (英語)」では、独自の拡張機能の開発を速やかに開始するための方法が紹介されています。

yeoman command line

今回の記事だけでは、各リリースについてお伝えしきれないことがまだまだあります。詳細については、7 月 14 日 (英語) および 8 月 4 日 (英語) のリリース ノートを参照してください。VSTS に関する計画や開発の最新情報は、DevOps ブログ (英語) をチェックしてください。

ではまた!

@tfsbuck

Comments (0)

Skip to main content