デプロイ グループとビルド完了トリガー – VSTS Sprint 132 Update
Sprint 132 Update of Visual Studio Team Services (VSTS) には、ビルドおよびリリース パイプラインのスケーリングに役立ついくつかの重要な機能が用意されています。 [ビルド] で、新しいビルド完了トリガーを使用して、異なるチームが所有する可能性がある関連するビルドを連結します。 リリースでは、運用環境を含む高可用性を備えた複数の仮想マシン間でデプロイをスケーリングするために使用できるデプロイ グループの一般提供についてお知らせします。
その他の特徴は次のとおりです。
VSTS の新機能
機能
コード
ビルドとリリース
- ビルド完了トリガーを使用して関連するビルドを連結する
- デプロイ グループを使用して VM にデプロイをスケーリングする
- Go で記述されたアプリケーションをビルドする
- タスク拡張機能を使用してリリース ゲートを拡張する
Package
Wiki
レポート
コード
コミット メッセージを使用して pull request をすばやく記述する
記述的なコミット メッセージを記述すると、Git リポジトリの履歴に価値が追加されます。 品質コミット メッセージを促すために、複数のコミットを持つ新しい pull request (PR) では、共同作成者が手動でタイトルを入力する必要があります。
Pull request の説明は既定では引き続き空になりますが、新しい機能を使用すると、PR コミットからのコミット メッセージを PR の説明に簡単に組み込むことができます。 コミット メッセージを追加するには、[ コミット メッセージの追加 ] をクリックして、PR 説明テキストの末尾にコミット メッセージを追加します。
Windows エクスプローラーから直接 TFVC コマンドを実行する
WINDOWS エクスプローラーに統合された軽量バージョン管理エクスペリエンスを提供する TFVC Windows シェル拡張機能では、VSTS と TFS 2018 がサポートされるようになりました。 このツールでは、Windows エクスプローラーのコンテキスト メニューで直接、さまざまな TFVC コマンドにアクセスできて便利です。
以前は TFS Power ツールに含まれていたこのツールが Visual Studio Marketplace でスタンドアロン ツールとしてリリースされました。
ビルドとリリース
ビルド完了トリガーを使用して関連するビルドを連結する
大規模な製品には、相互に依存する複数のコンポーネントがあります。 多くの場合、これらのコンポーネントは個別に構築されます。 アップストリーム コンポーネント (ライブラリなど) が変更された場合、ダウンストリームの依存関係を再構築して再検証する必要があります。 Teams は通常、これらの依存関係を手動で管理します。
これで、別のビルドが正常に完了したときにビルドをトリガーできます。 アップストリーム ビルドによって生成された成果物は、後のビルドでダウンロードして使用できます。また、Build.TriggeredBy.BuildId、Build.TriggeredBy.DefinitionId、Build.TriggeredBy.BuildDefinitionName の各変数からデータを取得することもできます。 詳細については、 ビルド トリガーに関する ドキュメントを参照してください。
この機能は、現在、1,129 票で 2 位の投票候補に基づいて優先順位が付けられました。
場合によっては、単一 のマルチフェーズ ビルド がニーズを満たす可能性があることに注意してください。 ただし、ビルド完了トリガーは、要件に異なる構成設定、オプション、または依存プロセスを所有する別のチームが含まれている場合に便利です。
デプロイ グループを使用して VM にデプロイをスケーリングする
堅牢で、すぐに使えるマルチマシン デプロイメントを提供する配置グループが、汎用的に使用可能になりました。 配置グループを使用すれば、アプリケーション全体の高可用性を確保しながら、複数のサーバーの間で配置を調整し、ローリング更新を実行できます。 また、Azure または任意のクラウド上のオンプレミスまたは仮想マシンにサーバーをデプロイでき、さらには、デプロイされた成果物をエンド ツー エンドで、サーバー レベルまで追跡できます。
エージェント ベースの配置機能は、既に使用可能になっている同じビルドと配置エージェントに依存します。 配置グループ フェーズで、ターゲット コンピューター上の完全なタスク カタログを使用できます。 拡張性の観点から、プログラムによるアクセスに対して配置グループとターゲットの REST API を使用することもできます。
共有デプロイ ターゲット
同じサーバーを使用して複数のアプリケーションをホストしている場合は、デプロイ プールを使用してチーム プロジェクト間でサーバー (デプロイ ターゲットとも呼ばれます) を共有できます。
新しいテンプレート
新しいリリース定義テンプレートを使用して、複数のターゲットへのデプロイが簡単になりました。 IIS Web サイト用の複数のテンプレート、データベースを含む IIS Web サイト、SQL DB 用の複数のデプロイ テンプレートをすぐに使用できます。
VM のプロビジョニング
拡張 Azure リソース グループ タスクを使用して、Azure で新しくプロビジョニングまたは既存のVirtual Machinesにエージェントを動的にブートストラップします。
昨年 5 月にデプロイ グループを起動したとき、いくつかの主要なシナリオを対象とした単純なユーザー インターフェイスが出荷されました。 これで、製品の残りの部分のように感じる、より一貫性のあるインターフェイスが見つかります。
開始の詳細については、 展開グループ のドキュメントを参照してください。
Go で記述されたアプリケーションをビルドする
これで、VSTS で Go アプリケーションをビルドできるようになりました。
Go Tool インストーラー タスクを使用して、1 つ以上のバージョンの Go Tool をすぐにインストールします。 このタスクは、プロジェクトに必要な特定のバージョンの Go Tool を取得し、ビルド エージェントの PATH に追加します。 対象の Go Tool のバージョンがエージェントに既にインストールされている場合、このタスクはダウンロードして再インストールするプロセスをスキップします。
Go タスクは、依存関係のダウンロード、ビルド、またはアプリケーションのテストに役立ちます。 このタスクを使用して、任意のカスタム Go コマンドを実行することもできます。
タスク拡張機能を使用してリリース ゲートを拡張する
リリース ゲート は、正常性シグナル情報をリリース パイプラインに直接取り込みます。 ゲートは、デプロイの前または後に、一連の正常性シグナルを繰り返し収集して、リリースを次のステージに進めるかどうかを判断します。 一連の組み込みゲートが用意されており、これまでに他のサービスを統合する場合は、[ Azure 関数の呼び出し ] オプションが推奨されています。
これで、ゲートは拡張機能の形式になり、新しいサービスまたはカスタム サービスを統合してゲートを構成することが簡単になりました。
詳細については、 オーサリング ゲート タスク のドキュメントを参照してください。
Package
VSTS の他の場所からアップストリーム npm パッケージを使用する
引き続きアップストリーム ソースに投資します。これにより、すべてのパッケージの依存関係を 1 つのフィードで一元化し、使用するすべてのパッケージの保存されたコピーを保持できます。 npm パッケージを含む複数の VSTS フィードがある場合は、同じ VSTS アカウント内のもう一方のアップストリーム ソースとして 1 つを追加できます。 npm では主にプロジェクトの構成で 1 つのフィード/レジストリに制限されるため、アップストリーム ソースでは、チームや製品ごとに 1 つなど、複数の npm フィードを使用する必要がある柔軟性が得られます。
また、VSTS NuGet フィードのアップストリーム ソースをすぐに有効にする作業も行っています。 詳細については、 アップストリーム ソース のドキュメントを参照してください。
保持ポリシーを使用してフィード クエリの速度を維持する
時間の経過と共に、パッケージ バージョンの数が増え、古いバージョンが使用されなくなる可能性があります。 結果的に、パッケージを頻繁に公開するユーザーの場合、NuGet パッケージ マネージャーやその他のクライアントで、いくつかのバージョンを手動で削除するまで、フィード クエリが遅くなることがありました。
フィードでアイテム保持ポリシーを有効にできるようになりました。 保持ポリシーによって、リテンション期間しきい値に達したとき、最も古いバージョンのパッケージが自動的に削除されます。 ビューに昇格したパッケージは無期限に保持され、実稼働または組織全体で使用されているバージョンを保護できます。
保持ポリシーを有効にするには、フィードを編集し、 [保持ポリシー] セクションの [パッケージごとの最大バージョン数] に値を入力します。
Wiki
Git リポジトリから Wiki として Markdown ファイルを発行する
開発者は、コード リポジトリに "API"、"SDK"、および "コードを説明するヘルプ ドキュメント" のドキュメントを作成します。 読者は、適切なドキュメントを見つけるためにコードを調べる必要があります。 これで、コード リポジトリから Markdown ファイルを発行し、Wiki でホストできます。
Wiki 内から、まず [コードを Wiki として発行] をクリックします。 次に、昇格する必要がある Git リポジトリ内のフォルダーを指定できます。
![[ページの発行] ダイアログ](media/132_05.png)
[発行] をクリックすると、選択したフォルダーの下にあるすべての Markdown ファイルが Wiki として発行されます。 これにより、ブランチの先頭が Wiki にマップされ、Git リポジトリに対して行った変更が直ちに反映されます。
製品の複数のバージョンがあり、これらのバージョンのドキュメントを簡単に確認したい場合は、異なるブランチを使用して新しいバージョンのドキュメントを Wiki に公開することもできます。
Markdown ファイルが発行されると、ページは Wiki 検索ハブでも検索できるようになります。
間違ったリポジトリを発行した場合は、単に Wiki を発行解除するだけで、基になるリポジトリは変更されません。
リポジトリからページの順序を変更したり、Wiki ページのようにフォルダーを変換したりすることもできます。
詳細については、 製品ドキュメントのブログ投稿 を参照してください。 この機能は提案に基づいて優先されました。
Wiki ページタイトルに特殊文字を保持する
などの : < > * ? | -特殊文字を含む Wiki ページを作成できるようになりました。 Wiki で、"FAQ" や "セットアップ ガイド" などのタイトルを含むページを作成できるようになりました。 次の文字は、UTF-8 でエンコードされた文字列に変換されます。
| 文字 | エンコードされた文字列 |
|---|---|
| : | %3A |
| < | %3C |
| > | %3E |
| * | %2A |
| ? | %3F |
| | | %7C |
| - | %2D |
この機能は提案に基づいて優先されました。
REST API を使用して Wiki を拡張する
Wiki REST API がパブリックになりました。 詳細については、 Wiki 関数 と Wiki 検索 のドキュメントを参照してください。
レポート
ビューを使用して Power BI と VSTS Analytics を統合する
分析ビューは、VSTS Power BI Data Connector と連携します。 これらのツールを組み合わせることで、VSTS データを Power BI に簡単に取り込み、カスタム レポートの作成を開始できます。
VSTS Analytics 拡張機能をインストールすると、Power BI で使用を開始できる既定の Analytics ビューのセットが作成されます。 既定のビューを編集し、 新しいビューを作成 して、Power BI に返されるレコード、フィールド、履歴を微調整できるようになりました。
次の手順とフィードバック
これらの機能に関するご意見をお聞かせください。 フィードバック メニューを使用して、問題を報告するか、Microsoft に優先順位を付ける必要がある事項に関するアイデアがある場合は、提案を提供します。
Stack Overflow のコミュニティが回答したアドバイスや質問を受けることもできます。
よろしくお願いします。
ゴピナス・チガッカガリ
フィードバック
以下は間もなく提供いたします。2024 年を通じて、コンテンツのフィードバック メカニズムとして GitHub の issue を段階的に廃止し、新しいフィードバック システムに置き換えます。 詳細については、「https://aka.ms/ContentUserFeedback」を参照してください。
フィードバックの送信と表示