次の方法で共有


GitHub のコミットと pull request をAzure Boards作業項目にリンクする - Sprint 144 Update

Azure DevOps の Sprint 144 Update では、引き続き GitHub との統合を拡張しています。 これで、GitHub のコミットと pull request をAzure Boards作業項目にリンクできるようになります。 GitHub とAzure Boardsを接続することで、バックログ、ボード、スプリント計画ツール、複数の作業項目の種類などの機能にアクセスできる豊富なプロジェクト管理機能を利用できます。

詳細については、以下の 機能 の一覧を参照してください。

機能

Azure Boards:

Azure Repos:

Azure Pipelines:

Azure Artifacts:

全般:

Wiki:

[Administration:

Azure Boards

GitHub をコードに使用し、豊富なプロジェクト管理機能を必要とする Teams は、リポジトリをAzure Boardsと統合できるようになりました。 GitHub とAzure Boardsを接続することで、バックログ、ボード、スプリント計画ツール、複数の作業項目の種類などのすべての機能を取得でき、GitHub の開発者ワークフローと統合するワークフローをまだ持つことができます。

コミットと pull request を作業項目にリンクするのは簡単です。 次の構文を使用して作業項目をメンションします。

AB#{work item ID}

コミット メッセージ、pull request タイトル、または pull request の説明に作業項目をメンションすると、その成果物へのリンクが作成Azure Boards。 たとえば、次のようなコミット メッセージを考えてみましょう。

Adds support for deleting connections. Fixes AB#20.

これにより、作業項目 #20 から GitHub のコミットへのリンクが作成されます。これは、作業項目の [開発] セクションに表示されます。 ​

作業項目からコミットへのリンク。

"fix"、"fixs"、または "fixed" という単語が作業項目メンションの前にある場合 (上に示すように)、コミットが既定のブランチにマージされると、作業項目は完了状態に移動されます。

Azure Pipelines を使用して GitHub でコードをビルドしている Teams には、ビルドの概要に GitHub コミットにリンクされている作業項目も表示されます。

サービスとしてのAzure Boardsを取得する

Azure Boardsを簡単に取得し、独自のサービスとして使用できるようになりました。 コードがAzure Reposか GitHub かに関係なく、[Azure Boardsの使用を開始する] に移動https://www.azure.com/boardsしてクリックすると、すぐに開始できます。 新しいユーザーには、Azure Boardsしかないプロジェクトと、実行している現場にアクセスするための概要が表示されます。

Azure Boardsの使用を開始します。

Azure Repos

自動完了 pull request に対して期限切れのビルドを再実行する

Azure Repos、pull request ポリシーによってトリガーされた期限切れのビルドが自動的にキューに入れられます。 これは、他のすべてのポリシーに合格し、自動完了に設定されている pull request に適用されます。 以前は、pull request に必要なレビュー担当者などのポリシーがある場合、承認プロセスに時間がかかりすぎるため、関連付けられているビルドが期限切れになり、レビュー担当者が pull request を承認する可能性がありました。 pull request が自動完了に設定されている場合、ユーザーが期限切れのビルドを手動でキューに入れるまでブロックされたままになります。 この変更により、ビルドは自動的にキューに入れられます。これにより、ビルドが成功した後に pull request が自動的に完了します。

注意

この自動化では、pull request ごとに最大 5 つの期限切れのビルドのみがキューに入れられ、各ビルドのキューの再作成が 1 回だけ試行されます。

Azure Pipelines

パイプラインを使用して GitHub リリースを管理する

GitHub リリースは、ユーザーにソフトウェアをパッケージ化して提供するための優れた方法です。 Azure Pipelines の GitHub リリース タスクを使用して自動化できるようになったことをお知らせします。 タスクを使用すると、新しいリリースの作成、既存のドラフト/発行済みリリースの変更、または古いリリースの破棄を行うことができます。 複数のアセットをアップロードしたり、リリースをプレリリースとしてマークしたり、リリースをドラフトとして保存したりなどの機能をサポートしています。 このタスクは、リリース ノートの作成にも役立ちます。 また、このリリースで行われた変更 (コミットと関連する問題) を自動的に計算し、ユーザー フレンドリな形式でリリース ノートに追加することもできます。

タスクの単純な YAML を次に示します。

task: GithubRelease@0 
displayName: 'Create GitHub Release'      
inputs:
  githubConnection: zenithworks
  repositoryName: zenithworks/pipelines-java
  assets: $(build.artifactstagingdirectory)/*.jar

GitHub リリース タスク。

このタスクを使用して作成された GitHub リリースのサンプル:

GitHub リリースのサンプル。

YAML ベースのパイプラインの VS Code 拡張機能

コーディング プロセスを高速化するために、YAML パイプライン用の VS Code 拡張機能 を追加しました。 この拡張機能は、構文の強調表示と IntelliSense (コード補完) をサポートし、ファイルが正しく構造化されていること、および有効なキーワードを使用していることを検証します。 さらに、組み込みのタスクもサポートし、必要な入力を検証することもできます。

この拡張機能は GitHub のオープンソース プロジェクトであり、コミュニティからのフィードバック、バグ レポート、コントリビューションをお待ちしております。

YAML パイプライン用の IntelliSense を使用した Web エディター

YAML を使用してパイプラインを定義する場合は、このリリースで導入された新しいエディター機能を利用できるようになりました。 新しい YAML パイプラインを作成する場合も、既存の YAML パイプラインを編集する場合でも、パイプライン Web エディター内で YAML ファイルを編集できます。 YAML ファイルを編集するときは、Ctrl + Space キーを押して IntelliSense をサポートします。 構文エラーが強調表示され、それらのエラーの修正に関するヘルプも表示されます。

YAML パイプライン用の Web エディター。

ServiceNow Change Management の統合

ServiceNow とのシームレスな統合により、運用デプロイの遅延を排除します。 ServiceNow と連携して Azure Pipelines が ServiceNow Change Management 拡張機能の一般公開を発表し、ServiceNow の変更管理プロセスをリリース パイプラインに認識させます。

ServiceNow 変更管理をリリース ゲートとして使用すると、ServiceNow で変更管理プロセスを開始し、変更を実装する準備ができるまで 2 つのステージ間でパイプラインを保持できます。

ServiceNow Change Management

デプロイ プロセスで ServiceNow 変更要求タスクを更新することもできます。ServiceNow 変更要求は、デプロイの状態と結果で更新されます。 これにより、ServiceNow と Azure Pipelines の間の完全な双方向統合が可能になります。

ServiceNow と Azure Pipelines の統合。

ビルド ログ内の特定の行へのリンクを共有できるようになりました。 これは、ビルド エラーの診断で他のチーム メンバーと共同作業を行うときに役立ちます。 結果ビューからログの行を選択するだけで、リンク アイコンが表示されます。

ビルド ログ内の特定の行にリンクします。

1 つのファイルでマルチプラットフォーム パイプラインを指定する

Azure Pipelines では、Linux、macOS、および Windows エージェント用のホストされたプールが提供されます。 以前は、3 つのホストされているプールすべてで同じパイプライン ステップを再利用するには、別のテンプレート ファイルで手順を指定する必要がありました。 マルチプラットフォーム パイプラインとマトリックス戦略を 1 つのファイルで指定できるようにするために、この要件を削除しました。

strategy:
  matrix:
    win:
      vm: windows-latest
    mac:
      vm: macOS-latest
    linux:
      vm: ubuntu-latest

pool:
  vmImage: $(vm)

steps:
- script: npm install
- script: npm run test

失敗時に自動的に再デプロイする

ステージへのデプロイが失敗すると、 Azure Pipelines は最後に成功したデプロイを自動的に再デプロイできるようになりました。 デプロイ後の条件自動再デプロイ トリガーを構成することで、最後に成功したリリースを自動的にデプロイするようにステージを構成できます。 今後のスプリントで、トリガーされたイベントとアクションを自動再デプロイ構成に追加する予定です。 詳細については、 デプロイ グループ のドキュメントを参照してください。

障害発生時に自動的に再デプロイします。

Azure Artifacts

PyPI パブリック プレビュー

Azure Artifacts で Python パッケージをホストできるようになりました。 これには、生成するパッケージと、パブリック PyPI から保存されたアップストリーム パッケージが含まれます。 詳細については、 お知らせのブログ投稿ドキュメントを参照してください

これで、すべての NuGet、npm、Maven、Python、ユニバーサル パッケージを同じフィードでホストできます。

Python パッケージをホストします。

全般

Service Health ポータル

サービスの正常性をフォローするためのエクスペリエンスを向上する新しい Azure DevOps サービス状態ポータルを追加しました。 いずれかのサービスで問題が発生した場合は、ここでサービスの正常性をチェックできます。

ポータルサービス正常性。

詳細については、 お知らせのブログ投稿ドキュメントを参照してください

Wiki

数式とビデオ用のマークダウン テンプレート

Wiki を編集するときに 、数式ビデオYAML タグ を追加するための Markdown 構文を覚える必要がなくなりました。 ツールバーのコンテキスト メニューをクリックし、任意のオプションを選択できるようになりました。

数式とビデオ用の Markdown テンプレート。

管理

削除されたプロジェクトを復元する

このリリースでは、削除されたプロジェクトを復元する機能が追加されました。 現在、削除プロジェクトのアクセス許可を持つユーザーは、REST API を使用して削除されたプロジェクトを復元できます。 これを行うには、 { "state" : "wellFormed" } を使用してプロジェクトの更新要求を作成します。 今後のリリースでは、organizationの概要ページからアクセスできる UI を追加する予定です。 REST API の詳細については、 こちらのドキュメントを参照してください。

削除されたプロジェクトの一覧を取得するには、次の要求を使用します。

GET https://dev.azure.com/{organization}/_apis/projects?stateFilter=deleted&api-version=5.0-preview.3

削除されたプロジェクトを復元するには、次の要求を使用します

PATCH https://dev.azure.com/{organization}/_apis/projects/{projectId}?api-version=5.0-preview.3

要求本文

{
    "state" : "wellFormed"
}

Note

削除されたプロジェクトを復元するには、最大 28 日しかかからなくなります。 28 日後、プロジェクトは 完全に 削除されます。

次の手順

Note

これらの機能は、今後 2 ~ 3 週間にわたってロールアウトされる予定です。

以下の新機能について確認し、Azure DevOps に進んで自分で試してみてください。

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

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

ご提案の送信

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

よろしくお願いします。

Aaron Bjork