次の方法で共有

プロジェクトを継承プロセス モデルに移行することでカスタマイズを容易にする – VSTS Sprint 139 Update

  • [アーティクル]

Sprint 139 Update of Visual Studio Team Services (VSTS) で、Hosted XML プロジェクトを継承プロセス モデルに移行してカスタマイズを容易にできるようになりました。 さらに、マージの前に追加のテストを実行するために 、PR によってリリースをトリガーできるようになりました 。

詳細については、以下の 機能 の一覧を参照してください。

次の手順

以下の新機能を読み、VSTS に移動して自分で試してみてください。

VSTS に移動する

機能

Wiki:

作業:

コード:

ビルドとリリース:

Wiki

Wiki ページの目次を作成する

Wiki ページが長くなる場合があり、コンテンツは複数の見出しにまとめられます。 構文を使用して、少なくとも 1 つの見出しを持つ任意のページに目次を [[_TOC_]] 追加できるようになりました。 VSTS での Markdown の使用の詳細については、マークダウン ガイダンスのドキュメントを参照してください。 この機能は、UserVoice からの提案に基づいて優先順位が付けられていました。

Wiki 目次

Work

継承プロセス モデルにプロジェクトを移行することでカスタマイズを容易にする

ホスト型 XML プロセス モデルを継承プロセスに移行すると、ユーザー インターフェイスを使用して作業追跡システムをカスタマイズできます。 いずれかのプロジェクトで Hosted XML プロセス モデルを使用している場合は、それらを移行できます。 プロジェクトのプロセス モデルの変更は、2 つの手順で行うことができます。 まず、ホストされた XML プロセスを継承モデルに複製します。 これにより、作業項目の種類、フィールド、状態などのカスタマイズが、新しく作成された継承プロセスに追加されます。

複製プロセス

プロセスを検証したら、新しく作成されたプロセスを使用するようにプロジェクトを変更できます。

プロジェクトの変更プロセス

詳細については、 ホスト型 XML プロセスを継承に複製する に関するドキュメントを参照してください。

改善された Microsoft Teams 統合を使用して最新の状態についてチャットする

Microsoft Teams 統合の最新の機能強化では、明確なアイコンと色でアクティビティの状態をすばやく確認し、チャットを開始して物事を動かします。 pull request が作成者を待機している場合は、黄色で表示され、タイマー アイコンが表示されます。 ビルドが成功すると、緑色で表示され、チェックマーク アイコンが表示されます。

チーム チャットでのアクティビティ

コード

テンプレートを使用して pull request の説明を標準化する

適切な pull request の説明を記述することは、レビュー担当者がコードをレビューするときに期待する内容を把握するのに役立つ優れた方法です。 また、テスト、単体テストの追加、ドキュメントの更新など、すべての変更に対して行う必要のある作業を追跡するのに役立つ優れた方法でもあります (ドキュメントの更新を忘れる人はいません)。 多くのユーザーは、チームが優れた説明を簡単に記述できるように pull request テンプレートを追加するよう要求しており、その機能が追加されました。

既定の PR 説明テンプレートのサポートに加えて、チームは複数のテンプレートを追加できます。このテンプレートは、[PR の作成] ページのメニューに表示されます。 [テンプレートの 追加 ] ボタンをクリックして、リポジトリ内の任意のテンプレートから選択し、PR の説明に追加します。

PR 用テンプレートを追加する

特定のブランチまたはブランチ フォルダーに PR 用の別のテンプレートを適用する場合は、ブランチ固有のテンプレートもサポートされます。 たとえば、"修正プログラム/" で始まるすべてのブランチに固有のテンプレートを作成する場合は、すべての PR に使用されるテンプレートをそれらのブランチに追加できます。

テンプレートを作成して使用する方法の詳細については、 pull request テンプレートのドキュメントを参照してください。

ビルドとリリース

pull request リリース トリガーを使用して追加のテストを実行する

pull request (PR) に基づいてビルドをトリガーし、しばらくの間、マージの前にその迅速なフィードバックを得ることができました。 これで、リリースの PR トリガーも構成できます。 リリースの状態はコード リポジトリにポストバックされ、PR ページに直接表示されます。 これは、PR ワークフローの一部として追加の機能テストまたは手動テストを実行する場合に役立ちます。

リリースの PR トリガー

Azure DevOps プロジェクトを使用して Go アプリを Azure Kubernetes Service (AKS) にデプロイする

DevOps プロジェクト を使用すると、Azure で簡単に作業を開始できます。 これは、いくつかの手順で、任意の Azure サービスでアプリケーションを起動するのに役立ちます。 DevOps Projects には、アプリの開発、デプロイ、監視に必要なものがすべて用意されています。

DevOps プロジェクトで Go Language を対象とするAzure Kubernetes Service (AKS) のサポートが追加されました。 詳細については、 AKS のチュートリアル ドキュメントを参照してください。

GitHub に報告されるビルドの状態は、より簡潔です

VSTS がビルドの状態を GitHub に投稿すると、関連付けられているコミット、ブランチ、pull request チェックに状態テキストが表示されます。 これまで、テキスト内の各ビルド パイプラインの名前は で VSTS:始まるものでした。 ビルド パイプラインの名前がひとめでわかりやすくなり、ビルド パイプラインの公式名に混乱 VSTS: が生じないように、状態テキストからこの序文を削除しました。 残念ながら、この変更は GitHub ブランチ保護規則に影響します。GitHub では、パイプライン名が で VSTS:始まると想定されています。 これにより、リポジトリ設定が更新されるまで GitHub pull request がブロックされる可能性があります。 これを解決するには、ビルドを少なくとも 1 回実行した後、リポジトリの [設定 > ] [ブランチ] [ブランチ] 保護規則でリポジトリのブランチ保護規則を > 更新します。

フィードバックの提供方法

これらの機能についてご意見をお聞かせください。 フィードバック メニューを使用して、問題を報告したり、提案を提供したりします。

フィードバック メニュー

Stack Overflow のコミュニティからアドバイスや質問に回答してもらうこともできます。

よろしくお願いします。

ゴピナス・チガッカガリ