Visual Studio Team Services の最新情報: 2017 年 7 月のまとめ
執筆者: Buck Hodges (Director of Engineering, VS Team Services)
このポストは、7 月 12 日に投稿された What’s brewing in Visual Studio Team Services: July 2017 Digest の翻訳です。
このブログ シリーズでは、Visual Studio Team Services (VSTS) に関する最新情報をお届けします。皆様はここで 3 週間分のリリース情報をご確認いただけます。Visual Studio Team Services は効率的な継続的インテグレーションと Azure へのリリース パイプラインを作成するのに最適な DevOps ツールです。
今月はまず、業界で初めて行った Git の大幅なスケーリングについてご紹介します。他にも Git の機能強化をいくつか説明し、その次に、新しい組み込みの Wiki のパブリック プレビューについてお伝えします。さらに、ビルド、リリース、パッケージ管理、作業項目の追跡に関する機能強化などたくさんのニュースがありますので、さっそく始めましょう。
世界最大の Git リポジトリを VSTS でホスト: ファイル数 3.5M、ファイル サイズ 300 GB!
マイクロソフトは、"One Engineering System (1ES)" と呼ばれるエンジニアリング システムの刷新 (英語) に向けて大規模な取り組みを進めています。その一環として、数年前に Windows コード ベースを Git に移行するという大きな目標を設定しました。サブモジュールを含む数種類のアプローチを試した結果、最も良いのは、リポジトリを仮想化して Git をスケーリングすることだという判断に至りました。今年の春、Windows チームは Windows コード ベース全体を Visual Studio Team Services でホストされる単一の Git リポジトリに移行し、この目標を達成しました。現在、"OS" と呼ばれる単一の Git リポジトリで約 4,000 人のエンジニアが作業しています (英語)。Windows は、何十年もの歴史の中で初めて単一のバージョン管理リポジトリに移行されました。マイクロソフトはこれを実現するために Git Virtual File System (GVFS、英語) を作成し、だれもが VSTS で使用できるようにオープンソース プロジェクト (英語) としてもリリースしました。
Windows 開発の運営規模は非常に大きなものです。以下に、いくつかデータをご紹介しましょう。
- 過去 4 か月間、このリポジトリの履歴に 250,000 件以上の到達可能な Git コミットがある
- 1 日あたり平均 8,421 回のプッシュ
- 1 就業日あたり 6,600 人のレビュー担当者が平均 2,500 件のプル リクエストに対応
- 4,352 件のアクティブなトピック ブランチ
- 1 日あたり 1,760 回の正式ビルド
GVFS は、最初のリリースからパフォーマンスが大幅に強化されています (英語)。その過程で Git のパフォーマンスとスケールの強化 (英語) も行われ、その成果が Git プロジェクトに反映されています。GVFS は VSTS のすべてのアカウントで使用できますので、ぜひお試しください (英語)。
次に、Git に関連したエクスペリエンスの強化点についてご説明します。
プル リクエストのコメントが折りたたみ可能に
コードのレビューは、プル リクエストにおける重要な作業です。そこで、レビュー担当者がこの作業に集中しやすくするために、新機能を追加しました。新しいコードを初めてレビューする際に、コメントを簡単に非表示にできるようにしました。
[Hide comments] を選択すると、ツリー ビューではコメントが非表示になり、ファイル ビューではコメント スレッドが折りたたまれます。
コメントが折りたたまれているときは、余白のアイコンをクリックすると簡単に展開できます。もう一度クリックすると再び折りたたまれます。ヒントを利用すると、スレッド全体を表示させることなく、一部のコメントを簡単に確認できます。
提案付きのプル リクエストの承認ワークフローの強化
プル リクエストに オートコンプリート オプション (英語) を使用すると生産性が向上しますが、コードのレビュー担当者との密な議論がなくならないように気をつけなければなりません。このため、プル リクエストが自動的に完了するように設定した場合に [Approve with suggestions] ダイアログが表示されるようにしました。これにより、ユーザーはオートコンプリート オプションをキャンセルしてレビュー担当者がフィードバックを読めるようにするか、オートコンプリートの設定を維持してすべてのポリシーの条件が満たされた場合にプル リクエストが自動で完了するようにするかを選択できます。
Code のツリー ビューのフィルタリング
目的のファイルを探すのに、コミットで変更が加えられたファイルの長いリストを端から端までスクロールする必要がなくなりました。コミットの詳細、プル リクエスト、シェルブセットの詳細、変更セットの詳細ページのツリー ビューで、ファイルやフォルダーのフィルタリングがサポートされ、フォルダー名でフィルタリングすると、フォルダーの子ファイルが表示されます。また、ファイル名でフィルタリングした場合は、ファイル階層を示すファイルのツリー ビューが折りたたまれた状態で表示されます。
コミット ツリーの [Find a file or folder] フィルター
Git タグ
VSTS の Web UI における Git タグの操作性は絶えず進化しています。表示機能が強化されたほか、タグの削除、フィルタリング、セキュリティ設定の機能も追加されました。
タグの表示
リポジトリのタグはすべて [Tags] ページで確認できます。すべてのタグをリリースとして管理している場合、ユーザーは [Tags] ページですべての製品リリースをまとめて確認できます。
このページでは、注釈付きタグと軽量タグを簡単に区別できます。注釈付きタグでは、タグ作成者、作成日、関連するコミットが表示され、一方、軽量タグではコミット情報のみが表示されます。
タグの削除
タグ名にタイプミスがあったり、誤ったコミットにタグ付けしてしまった場合には、リモート リポジトリからタグを削除する必要があります。Web UI からタグを削除するには、[Tags] ページに表示されたタグのコンテキスト メニューをクリックして、[Delete tag] を選択します。
タグのフィルタリング
時間が経てば経つほど、タグの数はどんどん増えていきます。また、リポジトリによってはタグが階層化され、必要なタグを見つけることが難しい場合があります。
目的のタグがなかなか見つからない場合は、[Tags] ページ上部のフィルターを使ってタグ名で検索することができます。
タグのセキュリティ
タグを管理するリポジトリのユーザーに、細かく権限を付与できるようになりました。タグを削除する権限、タグを管理する権限をユーザーに付与できます。
新しい Wiki エクスペリエンスのパブリック プレビュー
以前から、組み込みの Wiki がほしいというリクエストがありましたが、今回これにお応えして、各プロジェクトで独自の Wiki がサポートされました。Wiki はチーム メンバーや他のユーザーがプロジェクトについて理解したり、使用したり、参加するうえで役立つものです。詳細については、こちらのブログ記事 (英語) とドキュメント (英語) をご確認ください。また、絵文字 (英語) も完全サポートしているのでぜひご利用ください。
最新の Visual Studio を使用したビルド
Visual Studio の各バージョンの取り扱いに関するモデルを変更することになりました。アーキテクチャ、ストレージ、パフォーマンス上の制限を理由に、今後、単一のホスト型ビルド マシンに Visual Studio の複数のバージョンを提供することはなくなります。今回の変更に至った経緯と理由について、詳しくは「Visual Studio Team Services の Visual Studio Hosted Pool (英語)」をご確認ください。
今回のリリースでの変更点は次のとおりです。
- ビルド定義を作成する際に、キューを明示的に選択することが必要になりました (既定値なし)。
- この操作を簡単にするために、既定のキューを [Process] セクションの [Tasks] タブに移動しました。
- Visual Studio のビルド (英語) と MSBuild (英語) のタスクでは、バージョン引数の既定値が「Latest」に設定されました。
今後さらに多くの変更が予定されています。その 1 つとして、以下のホストされたプール (および対応するキュー) が追加されます。
- Hosted VS2017
- Hosted VS2015
- Hosted Deprecated (旧称 "Hosted Pool")
- Hosted Linux Preview
Chef: Infrastructure as Code
Visual Studio Team Services Marketplace で Chef の拡張機能が公開されました。 Chef とはインフラストラクチャ自動化プラットフォームと優れたカスタム開発キットを提供するもので、これによって容易に「インフラストラクチャをコードに変換する」ことができます。Chef の提供元は、「コードとして記述したインフラストラクチャは、柔軟性が高く、バージョン管理がしやすく、人間が解読できて、テストが可能」と説明しています。今回のリリースについては、Chef によるブログ記事 (英語) も併せてご確認ください。
この Chef の拡張機能は、Chef Automate の構成に使用できる 6 つの新しいビルドとリリース タスクを追加するものです。
このタスクを使用することで、Chef Automate (英語) プラットフォームで作業する際に頻繁に行うアクティビティを自動化できます。セットアップと構成の詳細については、GitHub で公開されている入門ガイド (英語) を確認してください。この拡張機能に含まれるタスクのうち、主にビルド プロセス中に使用されるものは以下のとおりです。
- Update cookbook version number (Cookbook のバージョン番号を更新 ) : Chef Cookbook をアップロードする前に、Cookbook のバージョンを現在のビルド番号に設定します。
- Upload cookbook to Chef Server (Chef サーバーに Cookbook をアップロード ) : リポジトリ内の Cookbook を含むパスを指定し、Chef サーバーにアップロードします。指定した場合、すべての前提条件も共にアップロードされます。
主にリリース プロセス中に使用されるタスクは以下のとおりです。
- Add variables to Chef Environment (Chef 環境に変数を追加 ) : 現在使用している環境の VSTS Release Management の変数セットをコピーして、指定した Chef 環境で使用します。
- Release cookbook version to environment (Cookbook のバージョンを特定の環境にリリース ) : 特定の環境の Chef Cookbook のバージョンの "ピン" を指定します。このタスクをリリース パイプラインで使用することで、その環境に Cookbook を "リリース" できます。
- Execute InSpec (InSpec を実行 ) : デプロイメント グループ内の各マシンで InSpec を実行します。
- Execute Chef Client (Chef Client を実行 ) : デプロイメント グループ内の各マシンで Chef Client を実行します。
マイクロソフトは、Team Services の拡張機能エコシステムに Chef が加わったことをたいへん嬉しく思っています。ぜひ皆様のインフラストラクチャで Chef の拡張機能をお試しください。
ソース ブランチに基づいて環境へのリリースを制御
リリース定義では、新規のリリースを作成した場合 (通常はソースのビルドが成功した後) に、デプロイメントを自動的にトリガーするように構成できます。しかし、成功したすべてのビルドではなく、ソースの特定のブランチのビルドのみをデプロイしたい場合もあります。
たとえば、開発およびテスト環境にはすべてのビルドをデプロイし、運用環境には特定のビルドだけをデプロイする場合などです。これを行うには、これまで開発/テスト環境用と運用環境用の 2 つのリリース パイプラインを維持する必要がありました。
しかし今回、Release Management で各環境に成果物フィルターを使用できるようになりました。これにより、ビルドの成功や新規リリースの作成といったデプロイメント トリガー条件が満たされた場合に各環境にデプロイされるリリースを指定できます。これには、各環境の [Deployment conditions] ダイアログの [Trigger] セクションで、その環境への新規デプロイメントをトリガーするビルドのソース ブランチやタグといった成果物条件を選択します。
また、[Release Summary] ページには、すべての未開始のデプロイメントについて、その状態になっている理由と、デプロイメントの開始方法や条件を示すヒントがポップアップ表示されます。
成果物ソースとしての Git リポジトリのリリース トリガー
Release Management では、同じアカウント内の任意のチーム プロジェクトのリリース定義にリンクした Git リポジトリの継続的デプロイメント トリガーを構成できるようになりました。これにより、リポジトリが新たにコミットされた場合にリリースを自動的にトリガーすることができます。また、Git リポジトリのどのブランチのコミットによってリリースをトリガーするかを指定できるようにもなったため、成果物ソースとして GitHub リポジトリと Team Foundation の Git リポジトリをリリース定義にリンクしてから、ビルドから生成されていないアプリケーション (Node.js や PHP など) のリリースを自動的にトリガーできます。
自動テストのオンデマンド トリガー
[Test] ハブで、テスト計画やテスト スイートから自動テスト ケースをトリガーできるようになりました。[Test] ハブから自動テストを実行する場合のセットアップ方法は、[Release Environments] でテストを指定したスケジュールで実行する場合と同様です。[Run automated tests from test plans] テンプレートを使用して、リリース定義の環境をセットアップし、自動テストを実行するテスト計画に関連付けます。[Test] ハブから環境をセットアップし、自動テストを実行する方法の詳しい手順については、こちらのドキュメント (英語) を参照してください。
Apple 証明書などのファイルを安全に保存
Build & Release 機能に汎用の Secure Files ライブラリ (英語) が追加されました。このライブラリを使用すると、ソース リポジトリにコミットすることなく、署名証明書、Apple プロビジョニング プロファイル、Android Keystore ファイル、SSH キーなどのファイルをサーバーに保存できます。
Secure Files のコンテンツは暗号化され、ビルドまたはリリース プロセスでタスクから参照した場合にのみ使用できます。Secure Files ライブラリのファイルは、セキュリティ設定に基づいて、チーム プロジェクトの複数のビルドおよびリリース定義で使用できます。Secure files はライブラリのセキュリティ モデルに従います。
この新機能を活用した以下の Apple タスクも追加されました。
- Utility: Install Apple Certificate (ユーティリティ: Apple 証明書のインストール)
- Utility: Install Apple Provisioning Profile (ユーティリティ: Apple プロビジョニング プロファイルのインストール)
Azure Key Vault のシークレットを変数として使用
Azure Key Vault との統合に関する高度なサポートが追加され、変数グループを Key Vault のシークレットにリンクできるようになりました。これにより、VSTS の設定を変更せずに、シークレットの値を Azure Key Vault 内で完全に管理できます。たとえば、リリースに影響を与えることなく、Azure Key Vault のパスワードや証明書のローテーションを行うことが可能です。
[Variable Groups] ページでこの機能を有効にするには、[Link secrets from an Azure key vault as variables] のトグル ボタンを使用します。Vault の詳細を構成したら、[+Add] を選択して、この変数グループにマッピングする特定の Vault のシークレットを選択します。
「変数グループ (英語)」で説明されているように、Azure Key Vault にマッピングした変数グループを作成したら、リリース定義にリンクすることができます。
なお、変数グループの変数にマッピングされるのはシークレット名のみで、値ではないことに注意してください。各シークレットの実際の値 (最新バージョン) は、リリース プロセス中に使用されます。
パッケージのビルド タスクの更新
NuGet、npm、Maven、dotnet のビルド タスクが全体的に更新され、GitHub の vsts-tasks リポジトリ (英語) に記録されている大半の問題も修正されました。
新しい統合 NuGet タスク
他のビルド タスク ライブラリのタスクとの整合性を高めるために、NuGet Restore、NuGet Packager、NuGet Publisher の各タスクが NuGet ビルド タスクに統合されました。新しいタスクは既定で NuGet 4.0.0 を使用します。これに伴い、古いタスクは廃止されたため、ユーザーには新しい NuGet タスクに移行することをお勧めします。今回の変更と同時に、いくつか機能強化が実施されます。これらの機能強化は、統合タスクを使用した場合にのみアクセスできるようになります。
この一環として、新しい NuGet Tool Installer タスクもリリースされました。このタスクは、指定したパスにある NuGet のバージョンを管理するもので、新しい NuGet タスクによって使用されます。そのため、ビルドの最初に NuGet Tool Installer タスクを追加するだけで、最新バージョンの NuGet を使用できます。
npm ビルド タスクの更新
新しい NPM ビルド タスクでは、npm プロジェクトのビルドを Windows、Linux、Mac のいずれで実行しても対応することができます。また、タスクを再編成し、npm install と npm publish の両方を簡単に実行できるようにしました。install と publish については、資格情報を容易に取得できるようにし、プロジェクトの .npmrc ファイルに記載されているレジストリの資格情報をサービス エンドポイント (英語) に安全に保存できるようにしました。また、VSTS フィードを使用している場合は、選択ツールを使用してフィードを選択すると、ビルド エージェントによって使用される必須の資格情報を含む .npmrc が生成されます。
アカウント/コレクション以外での作業
別の VSTS アカウントや TFS サーバーの Package Management フィードでも、NuGet.org/npmjs.com、Artifactory、MyGet といった Package Management 以外のフィードでも、VSTS アカウント以外でフィードを簡単に利用できるようになりました。NuGet および npm の専用の Service Endpoint タイプにより、正確な資格情報を簡単に入力し、パッケージのダウンロードやパッケージのプッシュ操作でビルド タスクをシームレスに実行できます。
Maven と dotnet での認証済みフィードのサポート
NuGet や npm とは異なり、Maven と dotnet のビルド タスクではこれまで、認証済みフィードを利用できませんでした。今回、フィードの選択ツールやアカウント以外での作業の機能強化といった前述のすべてのメリットが dotnet のタスクにも追加されました。また、Maven のタスクでも同様に、現在のビルドと同じ VSTS アカウントまたは TFS コレクション内の認証済みフィードがサポートされました。pom.xml にフィードを追加するだけで Maven によって自動で資格情報が追加され、完了時にはクリーンアップされるため、Package Management でサポートされているすべてのパッケージ タイプの VSTS/TFS や外部のフィード/リポジトリを簡単に利用することができます。
モバイル用の作業項目フォームの一般提供開始
Visual Studio Team Services の作業項目のモバイル エクスペリエンスの一般提供が開始されました。作業項目のデザインと操作性の最適化など、完全なエンドツーエンドのエクスペリエンスが提供され、自分に割り当てられた項目、フォローしている項目、スマートフォンから最近アクセスした項目、または編集した項目を簡単に操作できます。
今月の拡張機能: ProductPlan
全体像を共有することで、メンバー全員がチームの目標に沿って作業を行い、作業に遅れが生じた場合には多くのメンバーが気付くことができます。そこで今回、マイクロソフト パートナーの ProductPlan (英語) のロードマップ ソリューションを VSTS Marketplace (英語) で公開したことを発表しました。
ProductPlan を利用することで、チーム メンバーが簡単に製品戦略を計画、共有できるようになります。まずは、30 日間の無料トライアル版 (英語) をお試しください。
- バー、マイルストーン、コンテナー、レーンを簡単にドラッグ アンド ドロップするだけで、見栄えの良いロードマップを数分で作成できます。
- 計画を瞬時に更新できます。
- 個人、チーム全体、企業全体と無料で安全に情報を共有できます。PDF、画像、スプレッドシートに簡単に印刷、エクスポートできます。
- Planning Board を使用して、プロジェクトを客観的にスコア付けできます。
- Parking Lot で今後のビジネス チャンスをまとめて把握できます。
- レーンやコンテナーを展開して、共有する詳細情報の量を調整できます。
- Master Plan で複数のロードマップを表示して、製品ポートフォリオ全体をひと目で把握できます。
他にもさらに多くのリリース情報があります。すべての機能については、6 月 1 日 (英語) および 6 月 22 日 (英語) 付の発表記事をご覧ください。VSTS に関する最新情報は、DevOps ブログ (英語) をご覧ください。
ではまた!