2018/03/05
Visual Studio Team Services(VSTS)のSprint 131アップデートには、UserVoiceで大量のフィードバックとアクティビティを受け取ったいくつかの機能があります。1つはWork Items hubです。現在は、重要な作業を日常のワークフローの最前線にもたらすために一般的に利用可能になります。Azure DevOps Projectsを設定するためのオプションとして仮想マシンを追加しました.Webアプリケーションの下位レベルの制御を保持することが重要であることがわかっているためです。
そのほかのハイライト。
- Query work across the iteration schedule with +/- @CurrentIteration
- Improve release times by partially downloading artifacts
注意事項
ここで議論されている機能は今後二～三週間にわたって順次展開されます。
今回のアップデートでは、Gitをスムーズに動作させるために、2つの新しいリポジトリ設定があります。
Case enforcementを使うと、サーバーは "File.txt"と "file.txt"が区別されるデフォルトの大文字と小文字の区別モードから、WindowsおよびMacOSフレンドリモード("File.txt"と "file.txt"は同じファイルとして扱う)となります。この設定は、ファイル、フォルダ、ブランチ、およびタグに影響します。また、コントリビューターが誤って大文字と小文字を混在させたファイルを使ってしまうケースを防ぎます。ほとんどのコントリビューターがWindowsまたはmacOSを使っている場合、大文字小文字の同一視機能を有効にすることをお勧めします。
Limit file sizesでは、新規または更新されたファイルが設定したサイズ制限を超えないようにすることができます。Gitリポジトリの履歴に存在する大きなファイルの数が多いほど、cloneとfetchが遅くなり、操作のパフォーマンスが低下します。この設定は、これらのファイルの誤った導入を防ぎます。
queries, backlogs, boardは、あなたの作業を確認するさまざまな方法を提供しますが、私たちはあなたにとって最も重要な仕事があなたの手元にあることを望んでいます。6ヶ月間のWork Items Hubプレビューを経て、皆さんが使用可能になりました。プレビュー開始以来、私たちはハブで多くの変更を繰り返してきました。これにはいくつかの変更が含まれています。
Work Items Hubには、4つの人物中心のピボットがあり、重要なことに焦点を当てるだけでなく、3つのプロジェクト中心のビューによってプロジェクトの作業をよりよく理解できます。
- Assigned to me - プロジェクトにおいて、最後に更新されたものからすべてのWork itemを並べて表示する
- Following - あなたがフォローしているすべてのwork itemを表示する
- Mentioned - 直近30日において、すべての作業項目からあなたがメンションされたwork item。
- My activity - あなたが最近見たか、更新したすべてのwork item
- Recently updated - プロジェクトでもっとも最近更新されたすべてのwork item
- Recently completed - あなたのプロジェクトにおいて、最近完了したすべてのwork item
- Recently created - プロジェクトで最近作成されたすべてのwork item
Title、Area path、作成日など、さまざまなオプションに基づいてプロジェクトのピボットをソートすることができるようになりました。これらの作業項目を昇順または降順で表示することもできます。
イテレーションスケジュールに基づいてチームの作業を追跡するために役立つ@CurrentIterationマクロで、整数オフセットをサポートするようになりました。@CurrentIteration - 1で閉じられなかった作業を簡単に確認したり、@CurrentIteration + 1で次のイテレーションでの予定作業の確認ができます。詳細については、Microsoft DevOpsブログの@CurrentIterationポストを参照してください。この機能は、現在投票数456の投票で最大12位になった提案に基づいて優先順位が決定されました。
以前、クエリで@CurrentIterationマクロを使用していた場合、チームのコンテキストが異なるイテレーションスケジュールがチーム間で変更された場合、結果が異なることに気づいたかもしれません。今回の更新で、@CurrentIterationマクロを使用してクエリを作成または変更するときに、クエリに関連するイテレーションスケジュールでTeamを選択する必要があります。Teamパラメータを使用すると、同じクエリで、チーム間で@CurrentIterationマクロを使用できます。一つの例として、異なるイテレーションおよびスケジュールを使用している2つの異なるチームプロジェクトに対して、work itemのクエリであってもかまいません。これは、スプリントの変更に伴いクエリを更新する必要がなくなったことを意味します。詳細については、Microsoft DevOps Blogの@CurrentIterationのポストを参照してください。この機能は、提案に基づいて優先順位が付けられました。
Azure DevOps Projectを使用すると、わずか数ステップで完全に構成されたCI/CDパイプラインをセットアップできます。Azure Web Appsで提供を始めましたが、Windowsを実行しているAzure仮想マシンに展開できます。ASP.NETまたはASP.NET Coreアプリケーションを使い始めるときは、Virtual machineオプションを選択するだけです。
以前、展開フェーズの一環として、すべての成果物をダウンロードするか、すべてをスキップするかを選択ができました。今回の更新により、ダウンロードする必要のある成果物の選択ができます。エージェントは必要なものだけをダウンロードするだけでよくなるので、時間を節約できます。詳細は、リリースアーティファクトのドキュメントを参照してください。 この機能は、提案に基づいて優先順位が付けられました。
SonarSourceは、最近更新されたSonarQube拡張機能と新しいSonarCloud拡張機能をリリースしました。これは、多数の言語の静的コード解析を可能にします。VSTSのGradleタスクとMavenタスクは、特にJavaビルドのこれらの拡張機能を利用します。GradleまたはMavenタスクのバージョン2.*でRun SonarQubeまたはSonarCloud Analysisを有効にして、次に示すようにSonarQube/SonarCloudのPrepareとPublishタスクを追加します。詳細については、SonarQubeを使用した分析のドキュメントを参照してください。
GitHubまたはGitHub Enterpriseからのビルドは、すでに関連するコミットにリンクしています。それを構築したビルドへのコミットをトレースすることも同様に重要です。 これは、VSTSでソースタギングを有効にすることで可能になりました。 ビルド定義でGitHubリポジトリを選択しているときに、タグ形式と一緒にタグ付けするビルドの種類を選択します。
次に、ビルドタグをGitHubまたはGitHub Enterpriseリポジトリに表示します。
デフォルトでは、VSTSで自動的に設定されるAzure Resource Managerサービスエンドポイントは、サブスクリプションでContributorロールを構成します。今回の更新で、エンドポイントを作成し、サブスクリプション内の特定のリソースグループにスコープを制限するオプションが用意されています。これにより、エンドポイントが必要なものとだけ対話できるようになります。Azureサブスクリプションの承認を求めるプロンプトが表示されたら、Advancedオプションを選択します。
従来、ロールベースのセキュリティでは、セキュリティアクセスロールが設定されたとき、それらは、Deployment group、Variable group、Agent queue、およびService endpointのhubレベルのユーザーまたはグループに設定されていました。今回の更新において、特定のエンティティの継承をオンまたはオフにでき、必要な方法でセキュリティを設定できます。
Buildと同様に、Releaseで最後に完了した環境に対するデプロイメントの状態を示すバッジを設定できるようになりました。これらのバッジはURLで公開されており、使用者やコントリビューターに透明性を与えるために任意のリポジトリに埋め込むことができます。
プロジェクトにおいて、権限のあるメンバーが有効にすると、バッジURLへのアクセス権を持つユーザーは、選択した環境への展開状況を確認できます。
複数の成果物のソースをリリース定義に追加し、リリースをトリガーするように構成することができます。いずれかのソースに対して新しいビルドが利用可能になると、新しいリリースが作成されます。リリースがトリガーされたソースに関係なく、同じデプロイメントプロセスが実行されます。トリガーソースに基づいてデプロイメントプロセスをカスタマイズできるようになりました。自動でトリガーされたリリースの場合、リリース変数Release.TriggeringArtifact.Aliasにデータが入力され、リリースをトリガした成果物ソースが識別できます。これをタスク条件、フェーズ条件、およびタスクパラメータで使用して、プロセスを動的に調整することができます。たとえば、環境によって変更された成果物のみを配備する必要がある場合などです。
Visual StudioのサブスクリプションがAzure Active Directory(AAD)の電子メールアドレスに割り当てられていた場合、VSTSでも同じ電子メールアドレスがVisual Studioサブスクライバとして認識されなければなりませんでした。ただし、Microsoftアカウント(MSA)に割り当てられたサブスクリプションの場合、My Visual Studioポータルに別のAzure AD電子メールアカウントを追加し、そのAzure AD電子メールを使用してVSTSにアクセスできます。
この機能は、AADベースのVisual StudioユーザがMy Visual Studioポータルに別のAAD電子メールアカウントを追加できるように拡張されました。これにより、サブスクリプションが割り当てられているものとは異なる、VSTSで異なるAAD電子メールを使用できるようになります。
サブスクリプションに代替アカウントを追加する手順は、My Visual StudioのFAQにあります。詳細については、Microsoft DevOpsブログのVS Subscriptions and linking your VSTS account to AzureAD postを参照してください。
これらの機能についてどう思っているかお聞きしたいと思います。フィードバックメニューを使用して、優先順位を付けたいと思っていることに関するアイデアがある場合は、問題を報告するか、提案をしてください。
アドバイスや回答が必要な質問がある場合、Stack Overflowコミュニティで聞いてください。
ありがとうございました。
Jamie Cool