Visual Studio Team Services(VSTS)のSprint 132アップデートには、ビルドとリリースパイプラインの拡張に役立ついくつかの重要な機能があります。Buildでは、新しいビルド完了トリガーを使用して、異なるチームが所有する関連ビルドを連鎖させます。Releaseでは、実稼働環境を含む複数の仮想マシン間で高可用性を高めるためのDeployment Groupsの一般提供開始をお知らせします。
そのほかのハイライト:
注意事項
ここで議論されている機能は今後二～三週間にわたって順次展開されます。
- ビルド完了トリガーを使って、関係するビルドのトリガーを連続実行する
- Deployment Groupsを使って、大規模なVMの展開を実施する
- Goアプリケーションのビルド
- タスク拡張機能でRelease Gateを強化する
- GitレポジトリからmarkdownファイルをWikiへ発行する
- Wikiページタイトルに特殊文字が使用可能に
- 入力補完を使用して、ほかのwikiページへのリンクをすばやく作成
- REST APIを使用したWikiの拡張
説明的なコミットメッセージを書いておくと、Gitレポジトリの履歴に価値が生まれます。質の高いコミットメッセージを奨励するために、複数のコミットを持つ新しいPull Request(PR)には、コントリビュータが手動でタイトルを入力する必要があります。
Pull Requestの詳細説明はデフォルトでは空のままですが、新しい機能により、PRコミットからのコミットメッセージをPR詳細へ転記が容易になります。コミット・メッセージを追加するには、単にAdd commit messagesをクリックして、コミット・メッセージをPR記述テキストの最後に追加します。
Windowsファイルエクスプローラに統合された、軽いバージョン管理のエクスペリエンスを提供するTFVC Windows Shell Extensionが、VSTSとTFS 2018をサポートします。このツールは、Windowsエクスプローラのコンテキストメニューで多くのTFVCコマンドに簡単にアクセスできます。
以前TFS Power Toolの一部であったこのツールは、Visual Studio Marketplaceでスタンドアロンツールとして改めてリリースされました。
大規模な製品には、お互いに依存するいくつかのコンポーネントがあります。これらのコンポーネントは独立して構築されることが多くなります。依存関係の上位にいるコンポーネント(例えばライブラリ)が変更された場合、依存関係の下位にいるコンポーネントは再構築および、再検証する必要があります。チームは通常、これらの依存関係を手動で管理します。
今回の更新により、別のビルドが正常に完了したときに依存関係のあるコンポーネントのビルドが開始できます。上位のビルドによって生成されたアーティファクトは、後でビルドする際にダウンロードして使用できます。また、これらの変数からデータを取得することもできます：Build.TriggeredBy.BuildId、Build.TriggeredBy.BuildDefinitionId、Build.TriggeredBy.BuildDefinitionName 詳細については、build triggersのドキュメントを参照してください。
この機能は、現在1,129票の投票で2位に挙げられている提案に基づいて優先順位が決定されました。
場合によっては、単一のマルチフェーズビルドで要件を満たすことができることに注意してください。ただし、ビルド完了トリガーは、異なる構成設定、オプション、または別のチームが依存しているプロセスを保有している場合、便利です。
堅牢で、すぐに使えるマルチマシン展開を実現するDeployment Groupsの一般提供が開始されました。Deployment Groupsを使用すると、複数のサーバー間で更新プログラムを順番に展開することで、アプリケーションの高可用性を確保できます。Azureまたは、任意のクラウド上のオンプレミスまたは仮想マシンのサーバーにデプロイすることも、展開された成果物のどのバージョンがどのサーバーに展開されているか、エンドツーエンドのトレーサビリティをサーバーレベルまで下げることもできます。
エージェントベースの展開機能は、使用可能なビルドエージェントとデプロイメントエージェントが同じであることに依存しています。Deployment Groupフェーズでは、ターゲットマシン上で完全なタスクカタログを使用できます。拡張性の観点から、REST APIをdeployment groupsおよび、プログラム・アクセス用のターゲットに使用することもできます。
同じサーバーに複数のアプリケーションを実行している場合、deployment poolを使用してチームプロジェクト間でサーバー(展開ターゲットとも呼ばれます)の共有ができます。
新しいリリース定義テンプレートを使用することにより、複数のターゲットへのデプロイが簡単に行えるようになりました。IIS Webサイト用の複数のテンプレート、データベース付きのIIS Webサイト、SQL DB用の複数の展開テンプレートが用意されています。
拡張Azure Resource Groupタスクを使用すれば、Azure上で新たにプロビジョニングされた仮想マシン、または既存の仮想マシン上のエージェントを動的に構築します。
昨年5月にdeployment groupsをローンチしたとき、私たちはいくつかの重要なシナリオを対象としたシンプルなユーザーインターフェイスで提供しました。今回の更新で、製品の他の機能と同様、一貫したインターフェースになっているでしょう。
開始の詳細については、Deployment Groupsのドキュメントを参照してください。
GoアプリケーションがVSTSで構築できるようになりました！
Go Tool Installerタスクで、1つまたは複数のバージョンのGoツールをタスク実行時にインストールします。このタスクでは、プロジェクトで必要となるGoツールの指定されたバージョンを取得し、ビルドエージェントのPATHに追加します。ターゲットとなるGoツールのバージョンがすでにエージェントにインストールされている場合、再度ダウンロードしてインストールするプロセスをスキップします。
Goタスクは、アプリケーションの依存関係のダウンロード、アプリケーションのビルド、テストに役立ちます。このタスクを使用して、独自のGoコマンドの実行もできます。
Release Gateはサービスの生存情報をあなたのリリースパイプラインにもたらします。ゲートは、展開の前または後に、リリースが次の段階に進むべきかどうかを決定するために、一連のサービスの生存情報を繰り返し収集します。組み込みゲートセットが提供されていましたが、これまでは他のサービスを統合するためには、Invoke Azure Functionオプションが推奨されていました。
今回の更新で、ゲートが拡張機能の形で提供されるため、新しいサービスやカスタムサービスをあなたもしくは、ほかの人が拡張機能として作ることにより、容易に統合してゲートの設定ができるようになります。
詳細については、authoring gate taskのドキュメントを参照してください。
アップストリームソースには引き続き投資します。今回の更新で、すべてのパッケージの依存関係を1つのフィードに集中し、使用するすべてのパッケージの保存されたコピーの保持ができます。npmパッケージで複数のVSTSフィードを参照している場合、一つのVSTSアカウントで他のVSTSフィードをアップストリームソースとして追加できます。npmはほとんどの場合、プロジェクトの構成で単一のフィード/レジストリに制限されるため、アップストリームソースはチームや製品ごとに1つなど、複数のnpmフィードを使用するために必要な柔軟性を提供します。
また、VSTS NuGetフィードのアップストリームソースをすぐに使えるように取り組んでいます。 詳細については、upstream sourcesドキュメントを参照してください。
時間が経過すると、パッケージバージョン数が大きくなるため、古いバージョンは使用されなくなります。パッケージ提供者がが頻繁に更新している場合、古いバージョンを手動で削除するまで、NuGet Package Managerや他のクライアントのフィードクエリが遅くなる可能性があります。
今回の更新で、フィードの保持ポリシーを設定できるようになりました。保持ポリシーは、保持しきい値が満たされると、パッケージの最も古いバージョンを自動的に削除します。ビュー内でプロモート(訳注:Promote)で指定されたもの)されているパッケージは無期限に保持され、本番環境で使用されているか組織全体で広く使用されているバージョンが保護できます。
保持ポリシーを有効にするには、フィードの編集で、Retention policiesセクションのMaximum number of versions per packageに値を入力します。
開発者は、コードレポジトリの「API」、「SDK」、「コードを説明するヘルプドキュメント」といったドキュメントを作成します。読者は正しい文書を見つけるためにコードを調べる必要があります。今回の更新で、コードレポジトリからマークダウンファイルを公開し、Wikiにホストすることができるようになりました。
Wiki内から、Publish code as wikiをクリックします。次に、Gitレポジトリ内でWikiに提供するフォルダを指定します。
Publishをクリックすると、選択したフォルダのすべてのmarkdownファイルがwikiとして公開されます。これは、Gitレポジトリへの変更がすぐに反映されるように、ブランチのHEADをwikiにマップします。
製品に複数のバージョンがあり、これらのバージョン毎のドキュメントを簡単に切り替えて見たい場合、別のブランチを使用して、新しいバージョンのドキュメントをwikiに公開することもできます。
markdownファイルが公開されると、そのページはWikiの検索ハブで検索可能になります。
間違ったレポジトリを公開した場合、単にwikiの公開を解除してください。元のレポジトリは変更されません。
レポジトリからページの順序を変更したり、フォルダをwikiページのように移動もできます。
詳細については、製品ドキュメントのブログ記事を参照してください。この機能は、提案に基づいて優先順位が付けられました。
: < > * ? | -のような特殊文字を含むwikiページを作成できるようになりました。Wikiで、「FAQ？」や「Set-up guide」のようなタイトルのページの作成ができます。次の文字は、UTF-8でエンコードされた文字列に変換されます。
| Character | Encoded String |
|---|---|
| : | %3A |
| < | %3C |
| > | %3E |
| * | %2A |
| ? | %3F |
| | | %7C |
| - | %2D |
この機能は提案に基づいて優先順位がつけられました。
別のwikiページへのリンクを作成したいとき、リンク追加の標準的なmarkdown構文である[link name](/を入力するだけです。すべてのページから表示されたリンクをクリックすると、現在のWikiに選択したページへのリンクが登録されます。wikiページをmarkdownエディタにドラッグしてリンクを作成しても、ページへのリンクが簡単に作成できます。
この機能は提案に基づいて優先順位がつけられました。
WikiのREST APIを公開します。詳細はWiki functionsとWiki searchを見てください。
Analyticsビューは、VSTS Power BIデータコネクタと連携します。VSTSのデータをPower BIに簡単に取り込むことができ、カスタムレポートも作れます。
VSTS Analytics拡張機能をインストールすると、Power BIで使用できる既定のAnalytics View一式が作成されます。今回の更新で、既定のビューを編集したり、新しいビューを作成してPower BIに返されたレコード、フィールド、履歴を微調整したりできます。
これらの機能についてどう思っているかお聞きしたいと思います。フィードバックメニューを使用して、優先順位を付けたいと思っていることに関するアイデアがある場合は、問題を報告するか、提案をしてください。
アドバイスや回答が必要な質問がある場合、Stack Overflowコミュニティで聞いてください。
ありがとうございました。
Gopinath Chigakkagari