Azure DevOpsのSprint 154 Updateでは、AtlassianマーケットプレイスにAzure Pipelines for Jiraアプリをリリースします。この統合により、リリースと共にデプロイされた作業項目としてJiraのissueへのリンクが追加でき、デプロイメントの詳細でJiraのissueを直接表示できます。
また、作業項目の検索と追跡が簡単になるように改善しました。検索ボックスは、作業項目のインスタント検索と最近の作業項目のリストをサポートするようになりました。また、Wikiでは、Wikiコンテンツで作業項目を作成および追跡することで、ライブドキュメントを作成できます。
詳細については、以下の機能リストをご覧ください。
General:
Azure Boards:
- 作業項目の自動更新
- コマンドラインからイテレーションとエリアパスを管理する
- 作業項目の親項目を列オプションで確認する
- 作業項目のインスタントサーチ
- 作業項目のインクリメンタルサーチ
- プロジェクトのプロセスを変更する
Azure Pipelines:
- Jira用Azure Pipelinesアプリケーション
- Slack用Azure Pipelinesアプリの強化
- 単一のhosted pool
- organizationの設定におけるUpdated Agent Poolユーザーインターフェイスの更新
- キュー投入時の値の上書を制御する
- 巨大なテスト結果の添付をサポート
- YAMLパイプラインでのDeployments
- Optimizelyの統合
- GitHub releaseをアーティファクトの入力として追加する
- Azure DevOpsポータルから追加のパイプラインが購入可能に
- Releasesハブから直接リリースの承認ができるようになりました
- Azure Kubernetes サービスクラスターへのリンクがKubernetes environmentsリソースビューに追加
- サブスクリプションの通知でReleaseフォルダー単位のフィルターが可能になりました
- Azure Kubernetes Services(AKS)へのデプロイに外部のGitレポジトリをサポートしました
- BitBucketレポジトリをDevOpsプロジェクトでサポートしました
- デプロイメントセンターでのAKSとWebAppコンテナー用にDockerfileの切り替えをサポート
Azure Test Plans:
Azure Repos:
Azure Artifacts:
Wiki:
2月に、Azure CLI用のAzure DevOps拡張機能を導入しました。拡張機能を使用すると、コマンドラインからAzure DevOpsとインタラクティブな処理ができます。私たちはみなさんのフィードバックをいただいたことにより、私たちが拡張機能を改善し、そしてもっと多くのコマンドの追加に役立ちました。今回の更新で拡張機能が一般公開状態になったことをお知らせいたします。
Azure DevOps CLIの詳細については、こちらのドキュメントを参照してください。
以前は、2人で同じ作業項目を更新していた場合、2人目のユーザーは変更を行うタイミングでエラーが発生し、更新を失いました(訳注:同じフィールドを更新しようとすると、後で更新する人はTF26071というエラーが出ます)。今回の更新で、2人が両方とも異なるフィールドを編集している限り、作業項目に加えられた変更が自動更新されていることがわかるでしょう。
az boards iterationコマンドとaz boards areaコマンドを使用して、コマンドラインからイテレーションパスとエリアパスを管理できるようになりました。たとえば、CLIから対話形式でイテレーションパスとエリアパスを設定および管理したり、スクリプトを使用して設定全体を自動化したりできます。コマンドと構文の詳細については、こちらのドキュメントを参照してください。
今回の更新で、プロダクトバックログまたはスプリントバックログ内のすべての作業項目の親を確認できるようになりました。この機能を有効にするには、目的のバックログのColumn Optionsに移動し、Parent列を追加します。
最近訪れた作業項目、カンバンボード、バックログ、およびスプリントが簡単に見つけられるようになりました。Azure Boardsの検索ボックスをクリックすれば、最近アクセスした作業項目にアクセスできます。
ヒント
キーボードショートカット「/」を入力すれば、検索ボックスが表示されます。
今回の更新で、検索ボックスに入力するはじから作業項目の検索結果が表示されるようになるため、選択した作業項目にすばやく移動できます。
付け加えると、コードとWikiまたはパッケージの検索も下に表示されるため、タブを切り替えることなく、その場でコードやWikiの検索結果へ移動できます。
ツールはあなたのチームのように変わるべきで、希望したタイミングでプロジェクトを任意のプロセステンプレートから他のプロセスへ切り替えられるようになりました。たとえば、プロジェクトをAgileからScrum、BasicからAgileに変更できます。こちらに完全なステップバイステップのドキュメンテーションがあります。
Jira用Azure Pipelineアプリが利用可能になったことをお知らせします。この統合により、Azure PipelinesのリリースとJiraソフトウェアクラウドのissueで双方向リンクが可能になります。GitHubのコミットでリリースされたJiraのissueを追跡することで、リリースノートの生成が簡単になります。
付け加えると、Azure Pipelinesからのビルドおよびリリース情報を表示し、それをissueの開発パネルに表示します。これにより、issueがいつどのように配信されたかを追跡することができ、issueの作成からJiraで追跡された展開までの緊密な開発サイクルが提供されます。
Azure PipelinesとJiraソフトウェアクラウドの統合の詳細については、こちらのドキュメントを参照してください。
2月に、パイプラインの監視に役立つようにSlack用Azure Pipelinesアプリをリリースしました。今回のアップデートで、さらにアプリを強化しました。失敗したビルドについての通知があったとき、Slackチャンネルで @mentionを使います。さらに、リリース展開承認のを待機している場合、承認者には通知が行われます。
さらに、Azure Pipelinesアプリでビルドまたはリリースへのリンクを貼り付けて、豊富なパイプラインのプレビューを表示できるようになりました。これによりリンクにコンテキストが追加され、Azure DevOpsへの移動が容易になります。
たとえば、ビルドへのリンクを貼り付けると、そのビルドの詳細と現在のステータスが表示されます。
このアップデートの詳細については、こちらの完全な発表があるブログ投稿を参照してください。
注意事項
この説明はこれから私たちの変更予定を事前にお知らせするためのものです。
複数のHosted poolがあると、ときどき混乱してしまいます。同時実行の枠がどのプールで消費されているか、正確な状況はわかりません。たとえば、同時実行性10の並列ジョブがある場合、各ホストプールに10の仮想エージェントが表示されますが、正確ではありません。すべてのアイドル状態のエージェントにおいて、特定のHosted pool(Hosted VS2017など)でジョブが待機している場合、他のHosted pool(Hosted Ubuntu 1604など)で並行性が使われている可能性があることに気付かず、Azure Pipelinesサービスが破損していると思われることがあります。
Azure Pipelinesと呼ばれる新しい統合ホスト型エージェントプールを含めるように、エージェントプール管理エクスペリエンスを更新します。これにより、Hosted、Hosted VS2017、Hosted Ubuntu 1604、Hosted Windows 2019(VS2019)、Hosted macOS、Hosted macOS High Sierraなど、他のホスト型プールもすぐに置き換えられます。
この機能が展開されると、そのプールで実行されているジョブの数を正確に把握できる単一のホストプールが表示されます。次の数スプリントでこの変更を発表する予定です。古いホストプールから新しい統合プールの適切なイメージにジョブが自動的にリダイレクトされるため、パイプラインに変更を加える必要はありません。
過去の更新で、プロジェクト設定のエージェントプール管理ページを変更して新しいユーザーインターフェイスを追加しました。今回の更新で、組織設定の下でエージェントプールインターフェイスを更新しています。この新しいインターフェイスは、hosted poolの統合や同時実行ジョブの消費量を追跡する機能など、今後予定されている機能の第一弾となるものです。
今後更新される機能の詳細については、シングルホストプールのリリースノートを参照してください。
現在、新しい実行を開始する前に、UIまたはREST APIを使用して任意の変数の値を更新できます。パイプラインの作成者が特定の変数を_settable at queue time_としてマークすることはできますが、システムはこれを強制せず、他の変数で上書きされることを防ぐことができませんでした。言い換えれば、この設定は、新しい実行を開始するときに追加の入力を促すためにのみ使用されていました。
_settable at queue time_パラメーターを強制するための新しい組織レベルでの設定を追加しました。この強化により、新しい実行を開始するときにどの変数を変更できるかを制御できます。今後は、作成者が_settable at queue time_としてマークしていない変数を変更することはできません。
注意事項
この設定は既存の組織では既定でオフになっていますが、新しいAzure DevOps組織を作成すると既定でオンになります。
Azure Pipelinesのpublish test resultsタスクでは、テストの実行時にテスト結果を公開して、包括的なテストレポート作成と分析のエクスペリエンスを実現できます。これまでは、テスト実行とテスト結果の両方のテスト添付ファイルは100MBまでという制限がありました。この制限はクラッシュダンプやビデオのような大きなファイルのアップロードに支障がありました。今回の更新で、大規模なテスト添付ファイルのサポートが追加され、失敗したテストをトラブルシューティングするために使用可能なすべてのデータを入手できるようになりました。
デプロイジョブは、アプリを環境へデプロイするために使用される特別な種類のジョブです。今回の更新で、デプロイメントジョブでのステップ参照のサポートが追加されました。たとえば、1つのファイルで一連の手順を定義することで、デプロイメントジョブで参照可能になっています。
展開ジョブに追加のプロパティのサポートも追加しました。ここで設定できるデプロイメントジョブのプロパティをいくつか紹介します。
- timeoutInMinutes - 自動的にキャンセルするまでにジョブを実行する期間
- cancelTimeoutInMinutes - タスクを終了する前に「キャンセルされたタスクでも常に実行」する時間
- condition - ジョブを条件付きで実行
- variables - ハードコードされた値を直接追加することも、Azure Key Vaultで保護されているvariable groups、variable groupsを参照することも、ファイルで定義されている一連の変数を参照することもできます。
- continueOnError - この展開ジョブが失敗しても将来のジョブを実行する必要がある場合。デフォルトは 'false'です。
展開ジョブと展開ジョブを指定するための完全な構文の詳細については、Deployment jobを参照してください。
Optimizelyは、製品チーム向けの強力なA/Bテストおよびフィーチャーフラグをサポートするプラットフォームです。Azure PipelinesとOptimizelyの実験的なプラットフォームを統合で、製品チームはAzure PipelinesからDevOpsのすべての利点を得ながら、加速したペースでテスト、学習、および展開ができます。
Azure DevOpsのOptimizely拡張機能では、ビルドパイプラインとリリースパイプラインに実験と機能フラグのロールアウト手順が追加されているため、Azureパイプラインを使用して継続的に繰り返し機能をロールアウトできます。
Azure DevOps Optimizelyエクステンションの詳細については、こちらをご覧ください。
今回の更新で、GitHub ReleaseをAzure DevOpsリリースパイプラインのアーティファクトソースとしてリンクできます。これはあなたの展開の一部としてGitHub Releaseを利用することを可能にします。
リリースパイプライン定義でAdd an artifactをクリックすると、新しいGitHub Releaseソースタイプが表示されます。GitHub Releaseを利用するために、service connectionとGitHubリポジトリを提供できます。GitHub Releaseのデフォルトバージョンを選択して最新の特定のタグバージョンとして使用することも、リリース作成時に選択することもできます。GitHub Releaseがリンクされると、自動的にダウンロードされてリリースジョブで利用可能になります。
今までは、追加パイプライン購入の支払いはマーケットプレイスに行かなければなりませんでした。今回の更新でAzure DevOpsポータルから追加のパイプラインが購入できます。Organization Settings > Billingから、Microsoft-hostedかself-hosted CI/CDの数を増減できます。
詳しくは、こちらのCI/CDの購入に関するドキュメントをご覧ください。
保留中の承認への対処が簡単になりました。これまでは、リリースの詳細ページからリリースを承認することのみ可能でした。今回の更新でReleaseハブから直接リリースを承認できるようになりました。
対応するクラスターのAzureブレードに移動できるように、Kubernetes environmentのリソースビューへのリンクを追加しました。これは、Azure Kubernetesサービスクラスター内の名前空間にマップされている環境に適用されます。
フォルダーを使うことで、パイプラインが整理できるので、見つけやすさとセキュリティ管理を容易にできます。多くの場合、フォルダー配下のすべてのパイプラインによって表される、すべてのリリースパイプライン毎に異なるメールアドレスを使った通知を設定しなければなりません。以前は、優先的なメールを受け取るには、複数のサブスクリプションを構成するか、またはサブスクリプション内で複雑なクエリー設定を行う必要がありました。今回の更新では、deployment completedおよび*approval pending(訳注:承認を保留している状態)イベントにrelease folder句を追加して、メールの購読を簡素化できるようになりました。
以前は、AKSデプロイメントセンターのコードの配置場所としてAzure ReposとGitHubをサポートしていました。今回の更新では、External Gitリポジトリのサポートを追加したので、パブリックまたはプライベートのGitリポジトリからAKSにコードをデプロイできます。
私たちはDevOpsプロジェクトにBitBucketリポジトリのサポートを追加しました。これで、Azureリソースへのデプロイに選択できる豊富なリポジトリとブランチの一覧をOAuthのエクスペリエンスで取得できます。
今回の更新で、AKSとWebAppコンテナー用のデプロイメントセンターで任意のDockerfileの選択ができるようになりました。これは、異なるバージョンのDockerfileを管理したい場合や、同じリポジトリに複数のアプリケーションを持っている場合に役立ちます。これにより、プッシュしたい特定のDockerFile/アプリケーションの選択ができます。
新しいTest Plan Page(Test Plans*)が、すべてのAzure DevOps組織にパブリックプレビューで公開されています。新しいページには、テスト計画、オーサリング、実行など、目の前のタスクに集中する際に役立つ、合理化されたビューが用意されています。それはまた雑然としておらず、Azure DevOpsの他の製品と一致しています。
新しいページは以下で表示されているPreview Featuresから有効にできます。
Test Plans*ページには、copyとclone test plansなどの新機能に加えて、既存のページのほとんどに新機能があります。3週間ごとにテスト計画とオーサリング機能を追加します。
新しいページについてより学びたい場合、こちらのドキュメントを見てください。
組織設定のAzure DevOps auditingタブで使用できるReposのイベントを追加しました。ポリシーの作成、削除、変更、またはバイパス時にポリシーのイベントを表示できるようになりました。さらに、リポジトリの作成時(フォークや削除の取り消しを含む)、名前の変更、ソフト削除、破棄、またはデフォルトブランチの変更時に、リポジトリのイベントを表示できます。
フィードページの読み込み時間が短縮されたことをお知らせいたします。平均して、フィードページの読み込み時間は10％短縮されました。最大のフィードでは、99パーセンタイルのフィードページの読み込み時間(全フィードの最高99％の読み込み時間)が75％短縮されました。
以前は、コードWikiページを編集するときに、編集のためにAzure Reposハブへリダイレクトされていました。現在、Repoハブはmarkdown編集用に最適化されていません。
今回の更新で、Wiki内のサイドバイサイドエディターでコードWikiページを編集できるようになりました。これにより、豊富なmarkdownツールバーを使用してコンテンツを作成し、編集操作をプロジェクトWikiの編集操作と同等にできます。コンテキストメニューのEdit in Reposオプションを選択して、リポジトリで編集することもできます。
みなさんからのフィードバックに耳を傾けているうちに、ブレインストーミング文書、計画文書、機能に関するアイデア、仕様文書、議事録などをキャプチャするためにwikiを使用していると聞きました。今回の更新から、Wikiページを離れることなく、計画文書から直接機能やユーザーストーリーを簡単に作成できるようになりました。
作業項目を作成するには、作業項目を埋め込むウィキページ内のテキストを選択して、New work itemを選択します。最初に作業項目を作成し、編集してからそれを埋め込む作業項目を見つける必要がないので、これによって時間を節約できます。また、あなたがWikiの編集から出て行くことがなくなるため、コンテキストの切り替えも少なくなります。
Wikiから作業項目の作成と貼り付けはこちらのドキュメントを読んでください。
注意事項
ここで議論されている機能は今後二～三週にわたって順次展開されます。
これらの新機能を読んだ後、次のリンクからぜひご自身でAzure DevOpsサービスを体験してみてください。
これらの機能についてどう思っているかお聞きしたいと思います。 フィードバックメニューを使用して問題を報告するか、提案を提出してください。
アドバイスや回答を必要とする質問がある場合、Stack Overflowコミュニティで聞いてください。
ありがとうございました。
Steven Borg
Biju Venugopal