Microsoft でホストされている Linux および macOS エージェントの一般提供 – VSTS Sprint 137 Update

Sprint 137 Update of Visual Studio Team Services (VSTS) では、Linux および macOS Microsoft がホストする CI/CD エージェントから "プレビュー" モニカーを削除し、一般提供します。 Microsoft がホストする Windows エージェントと共に、お使いのプラットフォームに関係なく、運用ビルドとリリース用の信頼できるスケーラブルなプラットフォームが提供されるようになりました。

コード、Wiki、パッケージ、管理には他にも多くの機能があります。 詳細については、以下の 機能 の一覧を参照してください。

次の手順

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

VSTS の新機能

機能

コード:

Wiki:

ビルドとリリース:

パッケージ:

管理者:

コード

レビュー担当者として既定のチームを使用せずに pull request を作成する

重要

この機能を使用するには、プロファイルまたはorganizationで新しいナビゲーションプレビュー機能が有効になっている必要があります。

pull request (PR) エクスペリエンスを初めて開始したとき、PR の作成時に選択したチーム コンテキストにすべての PR を割り当てることが理にかなっていると考えました。 多くの人がチーム コンテキストと PR 割り当ての間の接続に気付かなかったため、この動作はフラストレーションポイントでした。 実際、これは UserVoice のトップ候補の 1 つです。

新しいナビゲーションの変更の一環として、この既定のチームとの関連付けを変更する機会を得ました。 次の 2 つの変更に気付くでしょう。

  1. PR を作成する場合、既定ではレビュー担当者は追加されません。 レビュー担当者リストには、最近 PR に追加された個人とグループを簡単に追加するための機能があります。 必要なレビュー担当者ポリシーは、特定の校閲者がコードをレビューするために確実に追加されるようにするチームにも役立ちます。
  2. Pull Requests ハブには、カスタマイズ可能な新しいセクションがあります。 既定では、このセクションには PR が "自分のチームに割り当てられている" と表示され、古いセクションと同等の機能が提供されます。 ただし、複数のチームに属している場合、このセクションには、いずれかのチームに割り当てられている PR が表示されます。 セクションもカスタマイズ可能です。セクション ヘッダーの近くにある [このビューのカスタマイズ] アクションをクリックするだけです。

プッシュ保護をあきらめずにブランチ ポリシーのバイパスを許可する

ブランチ ポリシーをバイパスする必要があるシナリオは多数あります。ビルド中断の原因となった変更の元に戻す、深夜に修正プログラムを適用するなどです。以前は、pull request の完了時にブランチ ポリシーをバイパスする機能を付与されたユーザーをチームが管理できるように、アクセス許可 ("ポリシーの適用から除外") を提供しました。 ただし、そのアクセス許可により、ブランチに直接プッシュする機能も付与され、PR プロセスは完全にバイパスされます。

このエクスペリエンスを向上させるために、古いアクセス許可を分割して、バイパスアクセス許可を付与しているチームにより多くの制御を提供しました。 古いアクセス許可を置き換えるには、次の 2 つの新しいアクセス許可があります。

  1. [Bypass policies when completing pull requests](pull request 完了時にポリシーをバイパス)。 このアクセス許可を持つユーザーは、pull request に対して "オーバーライド" 操作を使用できます。
  2. [Bypass policies when pushing](プッシュ時にポリシーをバイパス)。 このアクセス許可を持つユーザーは、必要なポリシーが構成されているブランチに直接プッシュできます。

最初のアクセス許可を付与し、2 番目のアクセス許可を拒否することで、ユーザーは必要に応じてバイパス オプションを使用できますが、ポリシーを使用してブランチに誤ってプッシュしても保護されます。

注意

この変更では、動作変更は発生しません。 以前に "ポリシー適用から除外する" の 許可 が付与されていたユーザーには、両方の新しいアクセス許可に 対して許可 が付与されるため、PR の完了をオーバーライドし、ポリシーを使用してブランチに直接プッシュすることができます。

詳細については、 ブランチのアクセス許可の設定 に関するドキュメントを参照してください。

Wiki

Wiki ページのセクション見出しの横にあるリンク アイコンをクリックすると、そのセクションに直接 URL を生成できます。 その後、その URL をコピーしてチーム メンバーと共有し、そのセクションに直接リンクできます。 この機能は提案に基づいて優先されました。

Wiki の見出し URL

正しくリンクされていない Wiki 内のすべてのリンクは、明確な赤い色と壊れたリンク アイコンで表示され、Wiki ページ内のすべての壊れたリンクの視覚的な手がかりを得ます。

Wiki の壊れたリンク

フォルダーにファイルとイメージを添付する

Wiki ページをオフラインで編集する場合は、Wiki ページと同じディレクトリに添付ファイルや画像を追加する方が簡単です。 これで、Wiki の任意のフォルダーに添付ファイルまたは画像を追加し、ページにリンクできます。 この機能は提案に基づいて優先されました。

Git リポジトリ フォルダー内の Wiki イメージ

新しいタブでページを開く

Wiki ページを右クリックして新しいタブで開くか、Ctrl キーを押しながら Wiki ページを左クリックして新しいタブで開くことができます。

Wiki の新しいタブ

ビルドとリリース

Microsoft でホストされている Linux および macOS エージェントを使用したビルドとリリース

Microsoft でホストされている Linux および macOS エージェントは、プレビューから外れ、一般提供されるようになりました。 プレビュー段階で数か月後、フィードバックを聞き、一貫したサービスを提供するためにインフラストラクチャをチューニングした後、GA でこれらを提供することに興奮しています。 詳細については、 Microsoft ホスト型エージェント のドキュメントを参照してください。

重要

ホストされたプールがプレビューで実装された方法により、既存の組織のエージェント プールには "プレビュー" モニカーが引き続き含まれます (名前のみ)。 "プレビュー" とマークされたプールは一般提供に達しており、近日中にロールアウトされる新しい名前のプールに相当します。

配置グループ内の新しいターゲットに自動的にデプロイする

以前は、新しいターゲットがデプロイ グループに追加されたとき、すべてのターゲットが同じリリースになるように手動デプロイが必要でした。 これで、最後に成功したリリースを新しいターゲットに自動的にデプロイするように環境を構成できるようになりました。 今後のスプリントで、自動再デプロイ構成にトリガー イベントとアクションを追加する予定です。 詳細については、 デプロイ グループ のドキュメントを参照してください。

デプロイ グループ

ゲートが一貫して成功するまでデプロイを保持する

リリース ゲートを使用すると、リリースが次の環境に昇格される前に正常性基準を自動的に評価できます。 既定では、すべてのゲートに対して 1 つのサンプルが成功した後にリリースが進行します。 ゲートが不規則で、正常に受信されたサンプルがノイズである場合でも、リリースは進行します。 これらの種類の問題を回避するために、進行状況の前に正常性の整合性を最小限の期間検証するようにリリースを構成できるようになりました。 実行時に、リリースでは、昇格を許可する前に、ゲートの連続した評価が成功することが保証されます。 評価の合計時間は"再評価までの時間" によって異なり、通常は構成された最小期間を超えます。 詳細については、 ゲートを使用したリリースデプロイ制御 に関するドキュメントを参照してください。

ゲートの保留設定

Azure DevOps プロジェクトの一般提供開始

11 月に導入された DevOps Projects は、コードから監視まで、Azure 上の完全な DevOps パイプラインを数分で開始して実行するのに役立ちます。 途中でサービスを追加し、多くのフィードバックを取り入れました。 今後も引き続き一般提供を開始し、DevOps を使用した体験をさらに進めるのに役立ちます。 詳細については、Microsoft DevOps ブログの Azure DevOps Projects の一般提供に 関する投稿を参照してください。

Package

プレインストールされているパッケージ管理の概要

パッケージ管理拡張機能は、すべての組織にプレインストールされています。 新しいナビゲーション プレビューを使用している場合は、サービスの一覧の下部でそれを探します。 現在のナビゲーションにまだ移動している場合は、[ビルドとリリース] ハブ グループで [パッケージ] ハブを探します。 各organizationには 5 人の無料パッケージ管理ユーザーが付属しており、Marketplace から追加のユーザー購入できます。 間もなく、他のユーザーと同様に、新しいナビゲーション内の [サービス管理者] ページを使用して、organizationでこのサービスの可視性を切り替えることもできます。

パッケージ サービス

管理

Azure Active Directory を Project Collection 管理として接続または切断する

プロジェクト コレクション管理者 (PCA) は、Azure Active Directory からorganizationを接続または切断できるようになりました。 以前は、organization所有者がこれを行う必要がありました。

すべての組織でプレビューで利用可能なパブリック プロジェクト

重要

この機能を使用するには、organization管理者が [設定] ページからパブリック プロジェクトを有効にする必要があります。

4 月に発表したように、VSTS にパブリック プロジェクトを導入します。 VSTS チーム プロジェクトを初めてパブリックとしてマークできます。 これにより、匿名 (認証されていない) ユーザーは、作業項目、コード、ビルド結果など、そのプロジェクトの内容を表示できるようになります。 この機能はまだプレビュー段階ですが、このスプリントの時点で、プライベート プレビューに参加するように招待する必要はなくなります。

重要

パブリック プロジェクトを使用して GitHub でホストされているリポジトリをビルドする場合は、リポジトリ内のブランチからの pull request (PR) は正常にビルドされますが、リポジトリのフォークから開かれた PR は現在ビルドされないことに注意してください。

VSTS でプロジェクトのコレクションを参照する場合は、"organization" という単語を採用します

VSTS のプロジェクトのコレクションを参照する際に、用語を変更しました。 以前は "account" という用語を使用しましたが、これにより、より広範な開発者やオープンソース コミュニティに多くの混乱が生じていました。 "account" という用語を "organization" に置き換えることを選択しました。 この変更のロールアウトは、この更新プログラムのドキュメントと製品内で表示されます。 詳細については、Microsoft DevOps ブログの「organization」という単語の採用に関する記事を参照してください。

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

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

フィードバック メニュー

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

よろしくお願いします。

Biju Venugopal