Visual Studio Team Services(VSTS)のSprint 137アップデートでは、LinuxおよびmacOS MicrosoftホストのCI/CDエージェントから"Preview"モニカを削除し、一般提供を開始しました。Microsoftが提供するWindowsエージェントに加えて、プラットフォームに関係なく、プロダクションビルドおよびリリース用の信頼性とスケーラビリティのあるプラットフォームが用意されています。
コード、Wiki、パッケージ、および管理には他にもいくつかの機能があります。詳細は以下の機能一覧をご覧ください。
これらの新機能を読んだ後、次のリンクからぜひご自身でVSTSを体験してみてください。
Wiki:
Build and release:
- MicrosoftのLinuxとmacOSエージェントがBuildとreleaseで一般提供開始
- デプロイグループで新しいターゲットを自動的にデプロイ対象にする
- リリースゲートが一貫して成功するまで展開を保留する
- Azure DevOps プロジェクトの一般提供開始
Package:
Admin:
重要!
この機能を使うためには、あなたのプロファイルもしくはアカウントのpreview featureからNew Navigationを有効にする必要があります。
最初にpull request(PR)の提供をはじめたとき、PRを作成するときに選択したチームのコンテキストにすべてのPRを割り当てることが理にかなっていたと考えました。多くの人々がチームのコンテキストとPRの割り当てとの間のつながりに気付かなかったので、この仕様は不満点となっていました。実際、これはUserVoiceの一番の提案の1つです。新しいナビゲーションの変更の一環として、チームとのこのデフォルトの関連付けを変更する機会を得ました。以下の2つの変更点があります。
- PRを作成するとき、デフォルトではレビューアは追加されません。レビューアリストには、最近PRに追加された個人やグループを簡単に追加できるようにする機能があります。必要なレビュー担当者ポリシーは、特定のレビュー担当者がコードをレビューするために追加されていることを確認したいチームにも役立ちます。
- Pull Requestハブには、カスタマイズ可能な新しいセクションがあります。デフォルトでは、このセクションには、以前のセクションと同等の機能を提供する"Assigned my team"にPRが表示されます。ただし、複数のチームに所属している場合、このセクションでは、いずれかのチームに割り当てられたPRを表示します。セクションはカスタマイズも可能です。セクションヘッダーの近くにある”Customize this view”アクションをクリックするだけです。
ビルド破壊を引き起こした変更を元に戻したり、夜中に修正プログラムを適用したりするなど、ブランチポリシーをバイパスする必要がある場合があります。これまでは、「ポリシー実施の免除」("Exempt from policy enforcement")を使用して、プルリクエストを完了したときにブランチポリシーをバイパスする権限をどのユーザーに付与したかをチームが管理できるようにしていました。しかし、その許可は、PRプロセスをまったく迂回してブランチに直接プッシュする能力を与えました。このエクスペリエンスを向上させるために、バイパス権限を付与しているチームに、より多くのコントロールを提供するために古い権限を分割しました。古い権限を置き換える2つの新しい権限を用意しました。
- Bypass policies when completing pull requests(pull requestの完了時にポリシーをバイパス)。この権限を持つユーザーは、pull requestに対して"Override"(上書き)エクスペリエンスを使用できます。
- Bypass policies when pushing(プッシュするときのポリシーをバイパス)。この権限を持つユーザーは、必要なポリシーが設定されているブランチに直接プッシュできます。
第1の許可を与え、第2の許可を拒否することにより、ユーザは必要に応じてバイパスオプションを使用することができるため、依然としてポリシーでブランチへのプッシュを防止できます。
注
この変更により、動作の変更は導入されません。以前は"Exempt from policy enforcement"(ポリシーの適用除外)を許可されていたユーザーには両方の新しいアクセス許可が許可されるため、PRの完了を上書きし、ポリシー付きのブランチに直接プッシュできます。
詳細はブランチの権限の設定ドキュメントを読んでください。
今回の更新で、wikiページ内の任意のセクション見出しの横にあるリンクアイコンをクリックすると、そのセクションに直接URLを生成できます。そのURLをコピーしてチームメンバーと共有して、そのセクションに直接リンクすることができます。この機能は、提案に基づいて優先順位が付けられました。
リンクされていないwiki内のリンクはすべて、明確な赤色で表示され、壊れたことを示すリンクアイコンで表示されるため、wikiページ内のリンクがすべて壊れていることがわかります。
wikiページをオフラインで編集すると、添付ファイルや画像をwikiページと同じディレクトリに簡単に追加できます。今回の更新により、wikiの任意のフォルダに添付ファイルや画像を追加して、ページにリンクできます。この機能は、提案に基づいて優先順位が付けられました。
今回の更新で、Wikiページを新しいタブで開くには、右クリックして新しいタブで開くを選択するか、単にCtrl + Wキーを押します。
マイクロソフトが提供するするLinuxおよびmacOSエージェントが、プレビュー段階を終了し、一般提供を開始しました。数か月にわたるプレビューで、フィードバックをいただき、一貫性のあるサービスを提供するためにインフラストラクチャーのチューニングを行い、今日GA(一般提供)に至ったことをうれしく思います。詳細については、Microsoftが提供するエージェントのドキュメントを参照してください。
かつては新しいターゲットがデプロイメントグループに追加された場合、すべてのターゲットが同じリリースで実行されるように手動で展開する必要がありました。今回の強化で、最後の正常なリリースを新しいターゲットへ自動的にデプロイするように環境を構成できるようになりました。今後のスプリントで自動再デプロイメント構成にトリガーイベントとアクションを追加する予定です。詳細については、Deployment Groupのドキュメントを参照してください。
Release gateは、リリースが次の環境に昇格される前に、環境の稼働状態の自動評価を可能にします。デフォルトでは、すべてのゲートについて1つのサンプルが正常に受信された後にリリースが進行します。ゲートが不安定で、受信したサンプルがノイズの場合でも、リリースが進行します。この種の問題を回避するために、リリースの進行を開始する前に最小限の期間、稼働状態の一貫性を確認するようにリリースを設定できるようになりました。実行時、リリースの次の環境への昇格を許可する前にゲートの連続評価が成功することを保証します。評価の合計時間は、"time between reevaluation"(再評価の時間)に依存し、通常、構成された最小期間より長くなります。詳細については、Release deployment control using gatesを参照してください。
11月にDevOps Projectsを紹介しました。これは、コードから監視まで、わずか数分でAzure上の完全なDevOpsパイプラインを起動して実行するという用途に役立ちます。私たちは多くのフィードバックを取り入れ、途中でサービスを追加しました。私たちは現在、皆さんのDevOpsへの道のりをさらに進められるように、一般提供開始後も引き続き進んでいきます。詳細については、Microsoft DevOpsブログのAzure DevOps Projectsの一般提供開始の記事を参照してください。
パッケージ管理拡張機能は、すべてのアカウントにあらかじめインストールされています。プレビューの新しいナビゲーションを使用している場合、サービスのリストの一番下を見てください。現在のナビゲーションにいる場合は、Build and releaseハブグループでPackagesハブを探します。各アカウントには5人の無料パッケージ管理ユーザーが同梱され、追加ユーザーはマーケットプレイスから購入できます。ナビゲーションの右上にあるメニューを使用して拡張機能を管理します。
Project Collection Administrator(PCA)は、Azure Active Directoryから接続、または切断できます。これまではアカウント所有者がこれを行う必要がありました。
重要!
この機能を有効にするためにはaccount administratorがSettingからenable public projectsを有効にする必要があります。
4月に発表したとおり、私たちはVSTSにパブリックプロジェクトを展開しています。最初に使うとき、VSTSチームプロジェクトをパブリック状態にできます。これにより、匿名の(認証されていない)ユーザーは、作業項目、コード、およびビルド結果を含むそのプロジェクトの内容を表示できます。この機能はまだプレビュー中ですが、これまでのスプリントのように、プライベートプレビューに参加する必要はなくなりました。
重要!
パブリックプロジェクトを使ってGitHubでホストされているリポジトリをビルドする場合、リポジトリ内のブランチからのプルリクエスト(PR)はうまく構築されますが、今はフォークされたリポジトリからオープンされたPRはビルドされません。
これらの機能についてどう思っているかお聞きしたいと思います。フィードバックメニューを使用して、優先順位を付けたいと思っていることに関するアイデアがある場合は、問題を報告するか、提案をしてください。
アドバイスや回答が必要な質問がある場合、Stack Overflowコミュニティで聞いてください。
ありがとうございました。
Biju Venugopal