次の方法で共有


パッケージ アップストリーム ソースとシンボル サーバーの一般提供 – VSTS Sprint 130 Update

Sprint 130 Update of Visual Studio Team Services (VSTS) では、完全な DevOps パイプラインの確立に役立つツールやサービスとの統合を引き続き改善しています。 アップストリーム ソースからパッケージを管理 して依存関係を制御し、 VSTS をシンボル サーバーとして使用 してデバッグを簡略化します。 また、Microsoft Teams の VSTS メッセージング拡張機能を使用して、チームの会話に作業項目を取り込むこともできます。

その他の特徴は次のとおりです。

VSTS の新機能

コード

最近削除されたリポジトリを API を介して復元する

ソース管理の以前のリポジトリを整理しているとき、間違って削除することがあります。 Git リポジトリが削除されてから 30 日経過していない場合、REST API でそのリポジトリを復元できます。 詳細については、一覧表示操作と復元操作に関する文書を参照してください。

Work

VSTS メッセージング拡張機能を使用して Microsoft Teams の作業項目について説明する

Microsoft Teams は、多くのエンジニアリング チーム内のチームワークのハブとなっています。 Microsoft Teams と新しい VSTS メッセージング拡張機能の統合を拡張し、他のコンテンツやツールと共に特定の作業項目を見つけて話し合えるようにしました。 詳細については、Marketplace の Microsoft Teams 統合 拡張機能を参照してください。

Microsoft Teams の VSTS メッセージング拡張機能

作業項目と pull request ディスカッションでグループをメンションする

作業項目や pull request に関するディスカッションに複数のユーザー (または特定のチームの全員) が含まれている場合、通知するすべてのユーザーに @mention 時間がかかります。 これで、ディスカッションで単に @mention チームまたはセキュリティ グループを作成できるようになりました。 作業項目または pull request のいずれかでメンションされるグループのメンバーである場合は、電子メール通知を受け取ります。 作業項目にメンションされるグループのメンバーである場合は、作業項目ハブの [メンション済み] ピボットにも その作業項目 が表示されます。

グループ メンション

ビルドとリリース

VSTS をシンボル サーバーとして使用する

ORGANIZATIONでシンボルをホストおよび共有できる VSTS シンボル サーバーが一般公開されました。 シンボルは、実行可能ファイル 、特に C や C++ などのネイティブ言語で記述された実行可能ファイルのデバッグを容易にする追加情報を提供します。 詳細については、 デバッグ用のシンボルの発行に関するドキュメント を参照してください。

この機能は、上位の提案に基づいて優先順位が付けられました。

GitHub 成果物のブランチをフィルター処理する

GitHub リポジトリのブランチ フィルターも構成できるようになりました。 たとえば、master/* ブランチからのビルドのみをデプロイできます。

ブランチ フィルター

include と exclude を使用してブランチをフィルター処理する

ここまでは、リリースをトリガーするブランチとタグを指定できました。 これは制限されており、リリース定義に頻繁に更新が必要であるという明確なフィードバックを受け取っています。 ビルドと同様に、リリースをトリガーすべきではないブランチを指定できるようになりました。 たとえば、dev/featureX ブランチではなく、すべての dev/* ブランチに対してリリースをトリガーできます。

ブランチにフィルターを含める/除外する

Azure Container Registry と Docker Hub から自動的にリリース

コンテナー化されたアプリを展開するとき、コンテナー イメージはコンテナー レジストリに最初にプッシュされます。 プッシュの完了後、コンテナー イメージを Web App for Containers または Kubernetes クラスターに展開できます。 Docker Hub または Azure Container Registry を成果物ソースとして追加することで、この 2 つに格納されているイメージの更新でリリースの自動作成を有効にできるようになりました。

ソースとしてのAzure Container Registry

Jenkins 成果物を Azure Storage に伝達する

Jenkins ビルドによって生成された成果物は、アーカイブと共有のために一般的にストレージ リポジトリに反映されます。 Azure BLOB ストレージ は、Jenkins ビルドによって作成された成果物でサポートされているリポジトリの 1 つです。 これで、リリース定義で成果物ソースとして Azure Storage に発行する Jenkins プロジェクトを使用できるようになりました。

成果物を定義に追加するときは、成果物が発行される Azure BLOB ストレージの詳細が必要です。 その後、デプロイによって成果物が Azure からエージェントに自動的にダウンロードされます。 この構成では、エージェントを Jenkins サーバーから切断できます。 ホストされたエージェントは、サーバーをインターネットに公開せずに使用できます。

Jenkins 成果物を Azure Storage に発行するためのオプション

Jenkins 成果物の既定バージョンを指定する

成果物が複数のリリースを自動トリガーしているとき、リリース定義に保存されている既定バージョンがすべての成果物に対して選択されます。 以前は、Jenkins 成果物には既定のバージョン設定がないため、セカンダリ 成果物として Jenkins を使用してリリースに継続的デプロイ トリガーを設定できませんでした。

それが今回、Jenkins 成果物に既定バージョンをしていできるようになりました。選択肢は次のようなおなじみのものになっています。

  • Latest
  • リリース作成時に指定する
  • 特定のバージョン

Jenkins 成果物の既定のバージョン

変数グループの範囲を特定の環境に設定する

以前は、変数グループをリリース定義に追加すると、リリース定義に含まれる変数はリリースのあらゆる環境で利用できました。 今回、変数グループの範囲を特定の環境に設定できるようになりました。ある環境では利用できるが、同じリリースの他の環境では利用できないように設定できます。 このような機能は、SMTP メール サービスなど、環境間で異なる外部サービスを利用しているときに役立ちます。

リンク変数グループ

ビルドまたはリリース定義から直接 Marketplace からタスクをインストールする

ビルドまたはリリース定義エディターでタスクを検索すると、既にインストールまたは組み込まれているタスクに加えて 、Marketplace から関連するタスク拡張機能が一覧表示されるようになりました。 拡張機能を取得するには、[ 無料で入手 ] をクリックし、 Marketplace でワークフローを完了します。 新しいタスクを作成したら、定義エディターのタスク 一覧を更新して、新しくインストールされたタスクを表示し、定義に追加する準備が整います。

Marketplace タスク

Package

アップストリーム ソースを利用し、パブリック パッケージをシームレスに利用する

nuget.orgnpmjs.com のアップストリーム ソースが一般公開されました。 利点としては、たとえば、保存されているパッケージをアップストリーム ソースから管理 (一覧から削除、非推奨設定、非公開設定、削除など) できます。また、使用するアップストリーム パッケージがすべて確実に保存されます。

現時点では、これらの利点は、プレビュー 機能 パネルでアップストリーム ソースプレビュートグルを以前に有効にしていない限り、このお知らせの後に作成されたフィードにのみ適用されます。 プレビュー トグルを有効にした場合、トグルを有効にした後に作成されたフィードで、これらの利点を使用できます。 以降の更新プログラムでは、古いフィードをアップグレードして、これらの機能強化を利用できるようになります。

npmjs upstream

パッケージ一覧でパッケージ バージョンの品質を表示する

パッケージ一覧では、各パッケージ バージョンのビューからその品質を簡単に確認できるようになりました。 詳細については、リリース ビューに関する文書

パッケージ リスト内のビュー

以前、パッケージ ハブにあるパッケージの URL を共有できましたが、使い勝手が良くないことが多々ありました。URL にプロジェクトを含める必要がありましたが、リンクを利用するユーザーにそのプロジェクトが該当することもあれば、該当しないこともあるからです。 この更新プログラムを使用すると、受信者がアクセスできるプロジェクトを自動的に選択するアカウント レベルの URL を使用してパッケージを共有できるようになりました。 URL の形式は https://<account>.visualstudio.com/_packaging?feed=<feed>&package=<package>&version=<version>&protocolType=<NuGet|npm|Maven>&_a=package です。<account> を除くすべてのパラメーターが任意ですが、パッケージを指定する場合、プロトコルの種類を指定する必要があります。

バッジを利用してパッケージを共有する

オープン ソース コミュニティでは、リポジトリの README でパッケージの最新版にリンクされているバッジを使用するのが一般的です。 この更新プログラムを使用すると、VSTS フィード内のパッケージのバッジを作成できるようになりました。 フィード設定で [パッケージ バッジを有効にする] オプションをチェックし、パッケージを選択し、[バッジの作成] をクリックします。 バッジ URL を直接コピーしたり、パッケージの詳細ページにバッジをリンクさせる事前生成マークダウンをコピーしたりできます。

パッケージ バッジを作成する

パッケージをリサイクルし、復元する

使われていないパッケージを削除することでパッケージ一覧が整理されますが、間違って削除してしまうこともあります。 今回、削除したパッケージをごみ箱から復元できるようになりました。 削除したパッケージはごみ箱に 30 日間保持されます。この間、必要に応じてパッケージを復元できます。

パッケージのごみ箱

管理

グループを使用して多数のユーザーのアクセスと拡張機能を管理する

Azure AAD または VSTS グループにアクセス レベルと拡張機能を割り当てることで、管理者が大規模なユーザー グループを簡単に管理できるようになりました。 適切なルールを設定した後、ユーザーをグループに追加すると、VSTS アカウントにアクセスすると、適切なアクセス レベルと拡張機能が自動的に付与されます。 その結果、アクセス レベルと拡張機能を個別に管理する必要がなくなります。

グループ ライセンス

詳細については、昨年の Microsoft DevOps ブログの 大きなアカウント ユーザー管理ロードマップの投稿 と、 グループ メンバーシップによるユーザーへのアクセス レベルと拡張機能の割り当て に関するドキュメントを参照してください。

Azure AAD グループ メンバーシップの変更の待機時間の短縮

Azure Active Directory (Azure AD) グループ メンバーシップを使用してアクセス許可を管理している場合、過去の Azure AAD でのメンバーシップの変更が VSTS によって認識されるのに 24 から 48 時間かかった可能性があります。 この待ち時間は 1 時間に短縮され、新しいチーム メンバーをより迅速に稼働できます。

Graph REST API パブリック プレビューを使用してユーザーを管理する

Graph REST API リソースを使用すると、開発者はユーザー、グループ、グループ メンバーシップを管理するアプリケーションを作成できます。 API のセットには、MICROSOFT アカウント (MSA) または Azure Active Directory (Azure AD) ユーザーの VSTS への追加、VSTS グループの作成、VSTS グループからのメンバーの追加と削除など、主要なユーザー管理シナリオが含まれます。 詳細については、Graph REST API のドキュメントサンプル を参照してください。

アカウントを離れる

以前は、アカウント所有者または管理者のみがアカウントからユーザーを削除できました。 これで、自分で関与しなくなったアカウントを残すことができます。 アカウントを離れるには、プロファイル ページに移動し、アカウント一覧内に残すアカウントを見つけます。 [アカウントアクション] セクションの下に、アカウントを離れるオプションが表示されるようになりました。 この機能は提案に基づいて優先されました。

アカウントを離れる

次の手順とフィードバック

これらの機能に関するご意見をお聞かせください。 フィードバック メニューを使用して、問題を報告するか、Microsoft に優先順位を付ける必要がある事項に関するアイデアがある場合は、提案を提供します。

フィードバック メニュー

Stack Overflow のコミュニティが回答したアドバイスや質問を受けることもできます。

よろしくお願いします。

ヘンリー・ディクソンとアーロン・ビョーク