次の方法で共有

作業項目ハブと VM ベースの Azure DevOps プロジェクト – VSTS Sprint 131 Update

  • [アーティクル]

Sprint 131 Update of Visual Studio Team Services (VSTS) には、UserVoice で大量のフィードバックとアクティビティを受け取った機能がいくつかあります。 1 つは Work Items ハブです。これにより、毎日のワークフローの最前線に重要な作業を取り込むための一般提供が開始されました。 また、Azure DevOps プロジェクトを構成するためのオプションとして仮想マシンを追加しました。これは、Web アプリケーションに対する下位レベルの制御を維持することが重要であることがわかっているためです。

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

VSTS の新機能

コード

リポジトリ設定を利用して上書きを回避し、パフォーマンスの低下を防ぐ

今回の更新プログラムには、Git の円滑な運営を維持するための新しいリポジトリ設定が 2 つあります。

ケースの適用 により、サーバーは既定の大文字と小文字を区別するモード ("File.txt" と "file.txt" が異なる) から、"File.txt" と "file.txt" が同じファイルである Windows と macOS に対応するモードに切り替わります。 この設定は、ファイル、フォルダー、ブランチ、タグに適用されます。 また、投稿者が誤って大文字と小文字が違うだけであるものを投稿しないようにすることができます。 投稿者の多くが Windows または macOS を実行しているときは、大文字と小文字の区別の強制を有効にすることをお勧めします。

ファイル サイズの制限では、設定したサイズ制限を新しいファイルや更新されたファイルが超えないようにします。 Git リポジトリの履歴に存在する大型ファイルの数が多くなればなるほど、複製やフェッチの操作のパフォーマンスが悪くなります。 この設定によって、制限を超えるファイルが間違って移入されることがありません。

Work

作業項目ハブを使用して重要な作業に集中する

クエリ、バックログ、ボードではさまざまな方法で作業内容を確認できますが、最も重要な作業をすぐに使用できるようにしたいと考えています。 作業項目ハブの 6 か月のプレビューの後、すべてのユーザーが利用できるようになりました。 プレビューの開始以来、ハブで多くの反復処理が行われ、以下に加えたいくつかの変更が含まれています。

作業項目ハブには、自分にとって重要なことに集中できる 4 つのユーザー中心のピボットと、プロジェクトの作業をよりよく理解するための 3 つのプロジェクト中心のビューが用意されました。

  • [自分に割り当て済み ] - プロジェクト内で最後に更新された順序で割り当てられたすべての作業項目
  • フォロー中 - フォローしているすべての作業項目
  • メンション済み - 過去 30 日間にメンションされたすべての作業項目
  • マイ アクティビティ - 最近表示または更新したすべての作業項目
  • 最近更新 された - 最近更新されたプロジェクト内のすべての作業項目
  • 最近完了 - 最近完了 したプロジェクト内のすべての作業項目
  • 最近作成 - プロジェクトで最近作成されたすべての作業項目

作業項目のピボット

タイトル、エリア パス、作成日など、さまざまなオプションに基づいてプロジェクト ピボットを並べ替えることができるようになりました。 これらの作業項目を昇順または降順で表示することもできます。

作業項目の並べ替えオプション

+/- を使用してイテレーション スケジュール全体でクエリを実行する @CurrentIteration

@CurrentIterationイテレーション スケジュールに基づいてチームが作業を追跡するのに役立つマクロで、整数オフセットがサポートされるようになりました。 - 1 で @CurrentIteration 閉じられなかった作業を簡単にタブに保持するか、+ 1 で今後のイテレーション @CurrentIteration で計画されている作業を先読みします。 詳細については、Microsoft DevOps ブログの @CurrentIteration投稿 を参照してください。 この機能は、現在、456 票を獲得した 12 位の投票候補に基づいて優先順位が付けられました。

Team パラメーターを使用してクエリイテレーションのスケジュールを @CurrentIteration 明確にする

過去にクエリでマクロを @CurrentIteration 使用していた場合、イテレーション スケジュールが異なる Teams 間でチーム コンテキストが変更された場合、結果が異なる場合があることに気付いたかもしれません。 ここで、マクロを使用 @CurrentIteration してクエリを作成または変更する場合は、クエリに関連するイテレーション スケジュールを持つチームも選択する必要があります。 Team パラメーターを使用すると、チーム間で同じクエリでマクロを使用 @CurrentIteration できます。 1 つの例として、異なるイテレーション名とスケジュールを使用する 2 つの異なるチーム プロジェクトの作業項目のクエリがあります。 つまり、スプリントの変化に合わせ、クエリを更新する必要がなくなります。 詳細については、Microsoft DevOps ブログの @CurrentIteration投稿 を参照してください。 この機能は提案に基づいて優先されました。

Team パラメーター

ビルドとリリース

Azure DevOps プロジェクトを仮想マシンにデプロイすることで、アプリをより詳細に制御する

Azure DevOps プロジェクトを使用すると、いくつかの手順で完全に構成された CI/CD パイプラインを設定できます。 Azure Web Appsの使用を開始した後、必要に応じて Windows を実行している Azure 仮想マシンにデプロイできるようになりました。 ASP.NET または ASP.NET Coreアプリケーションの使用を開始する場合は、単に [仮想マシン] オプションを選択します。

DevOps Project VM オプション

成果物を部分的にダウンロードし、リリース回数を減らす

以前は、展開フェーズの一環として、すべての成果物をダウンロードするか、スキップするように選択できました。 それが今回、ダウンロードが必要な成果物を選択できるようになりました。 必要とするもののみエージェントがダウンロードすることで時間を短縮できます。 詳細については、リリース成果物に関する文書を参照してください。 この機能は提案に基づいて優先されました。

成果物を部分的にダウンロードする

SonarSource の最新の拡張機能を使用してコードの品質を向上させる

SonarSource は最近、更新された SonarQube 拡張機能 と新しい SonarCloud 拡張機能をリリースしました。これにより、多数の言語の静的コード分析が可能になります。 VSTS Gradle タスクと Maven タスクでは、特に Java ビルド用にこれらの拡張機能を利用します。 Gradle または Maven タスクのバージョン 2.* で [SonarQube または SonarCloud 分析の実行 ] を有効にし、次に示すように[SonarQube/SonarCloud の 準備 と 発行 ] タスクを追加します。

Gradle と Maven のタスク

ビルド タグを利用し、ビルドまで GitHub ソースを追跡する

GitHub または GitHub Enterprise からのビルドは関連コミットに既にリンクされています。 コミットを構築したビルドまでコミットを追跡できることは同じくらい重要です。 VSTS でソースタグ付けを有効にすることで、それが可能になりました。 ビルド定義で GitHub リポジトリを選択するとき、タグを付けるビルドの種類とタグの形式を選択します。

タグ ソースのオプション

次に、GitHub または GitHub Enterprise リポジトリにビルド タグが表示されるのを確認します。

GitHub のタグ付けされたソースの例

Azure Resource Manager サービス エンドポイントをリソース グループに分離する

既定では、VSTS で自動的に構成される Azure Resource Manager サービス エンドポイントは、サブスクリプションに対する共同作成者ロールを取得します。 これで、エンドポイントを作成し、スコープをサブスクリプション内の特定のリソース グループに制限するオプションが用意されました。これにより、エンドポイントが必要な操作のみを確実にやり取りできるように、いくつかの分離が提供されます。 [Azure サブスクリプションの承認] を求められたら、[詳細オプション] を選択します。

Azure サブスクリプション 詳細オプションを承認する

エンティティ固有セキュリティの管理

以前、ロール ベースのセキュリティでは、セキュリティ アクセス ロールが設定されるとき、展開グループ、変数グループ、エージェント キュー、サービス エンドポイントのハブ レベルでユーザーまたはグループにロールが設定されました。 特定のエンティティの継承のオン/オフが切り替えられるようになりました。セキュリティを好みに合わせて構成できます。

[セキュリティ] ダイアログ

バッジを使用してデプロイの状態を共有する

ビルドと同様に、リリースで、環境に対する最後に完了したデプロイの状態を示すバッジを構成できるようになりました。 これらのバッジは、URL を介してパブリックにアクセスできます。これは、コンシューマーと共同作成者により透明性を高めるために、任意のリポジトリに埋め込むことができます。

バッジ オプション

プロジェクトの承認されたメンバーによって有効になると、バッジ URL へのアクセス権を持つすべてのユーザーが、選択した環境へのデプロイの状態を確認できます。

readme のバッジ

成果物を選択的に展開し、リリースをトリガーする

複数の成果物ソースをリリース定義に追加し、リリースをトリガーするように構成できます。 いずれかのソースに新しいビルドが利用できるようになると、新しいリリースが作成されます。 リリースをトリガーしたソースに関係なく、同じ展開プロセスが実行されます。 トリガーするソースに基づいて展開プロセスをカスタマイズできるようになりました。 自動的にトリガーされたリリースについては、リリースをトリガーした成果物ソースを識別する目的で、リリース変数 Release.TriggeringArtifact.Alias にデータが入力されるようになりました。 これはタスク条件、フェーズ条件、タスク パラメーターで使用し、プロセスを動的に調整できます。 たとえば、環境を介して変更された成果物ソースのみを展開できます。

サブスクリプション

AAD ベースの代替メール アカウントを使用して既存のサブスクリプションを活用する

以前は、Visual Studio サブスクリプションが Azure Active Directory (Azure AD) のメール アドレスに割り当てられている場合は、VSTS で同じメール アドレスを使用して追加し、Visual Studio サブスクライバーとして認識する必要がありました。 ただし、Microsoft アカウント (MSA) に割り当てられたサブスクリプションの場合は、 My Visual Studio ポータルで代替の Azure AD メール アカウントを追加し、その Azure AD メールを使用して VSTS にアクセスできます。

この機能は、AAD ベースの Visual Studio サブスクライバーが My Visual Studio ポータルで別の AAD メール アカウントを追加できるように拡張されました。 これにより、サブスクリプションの割り当て先とは異なる AAD メールを VSTS で使用できるようになります。

サブスクリプションに代替アカウントを追加する

サブスクリプションに代替アカウントを追加する手順については、「 My Visual Studio FAQ」を参照してください。 詳細については、Microsoft DevOps ブログの 「VS サブスクリプションと VSTS アカウントを AzureAD にリンク する」を参照してください。

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

VSTS に移動する

更新をサブスクライブする

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

フィードバック メニュー

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

よろしくお願いします。

ジェイミー クール