Azure DevOps の概要
Visual Studio Team Services (VSTS) だった 1 つのサービスが、Azure DevOps Services の新しいセットになりました。 ドキュメント、Web サイト、製品全体を通じて、Azure DevOps のすべての新しいアイコンと名前、および Azure DevOps 内の各サービスに注目します。
- Azure Pipelines を 使用して、任意のプラットフォームとクラウドを継続的に構築、テスト、デプロイできます。
- 強力な作業管理のための Azure Boards 。
- Maven、npm、NuGet パッケージ フィード用の Azure Artifacts 。
- クラウドでホストされる無制限のプライベート Git リポジトリ用の Azure Repos 。
- 計画済みおよび探索的テスト用の Azure テスト プラン 。
Azure Pipelines の立ち上げに伴い、GitHub Marketplace に新しいアプリを導入し、開始に役立つさまざまなエクスペリエンスを更新し、オープンソース プロジェクトに対して無制限の CI/CD 分と 10 個の並列ジョブを提供しています。
詳細については、以下の 機能 の一覧を参照してください。
機能
Azure Pipelines:
- GitHub Marketplace から Azure Pipelines を追加する
- Azure Pipelines を使用してオープンソース プロジェクトを無料でビルドする
- YAML を使用してビルドを構成する
- 新しいウィザードを使用して YAML ビルド パイプラインを作成する
- 新しい [ビルド] ページを使用してビルド パイプラインを管理する
- GitHub pull request ビルドをリビルドする
- 新しいビルドステータスバッジの URL
- Microsoft がホストする Linux エージェントでさらに多くのツールを活用する
- リリースで GitHub のコミットと関連する問題を追跡する
- 改善された書式設定を使用してビルドとデプロイの完了メールをより適切に管理する
- 新しい統合 Azure Pipelines の用語に従う
Marketplace:
管理:
次のステップ
Note
これらの機能は、今後数日間にわたってロールアウトされます。
以下の新機能について読み、Azure DevOps Services に進んで、自分で試してみてください。
Azure Pipelines
GitHub Marketplace から Azure Pipelines を追加する
GitHub Marketplace の新しい Azure Pipelines アプリは、GitHub リポジトリとの統合を拡張し、並列ジョブの購入を合理化します。
以前は、OAuth 認証を使用して GitHub リポジトリとの継続的インテグレーションを有効にできました。 OAuth を使用すると、Azure Pipelines は個人の GitHub ID を使用してコードをフェッチし、GitHub でビルドの状態を更新します。 ただし、チームのメンバーは時間の経過と同時に変化する可能性があるため、個人の GitHub ID とアクセス許可を使用することは望ましくない場合があります。 Azure Pipelines アプリをインストールすることで、代わりにアクションを実行するアプリを承認できます。
また、アプリを使用すると、ビルド結果が GitHub の新しい チェック 機能で使用可能になり、ビルド、テスト、コード カバレッジの結果の詳細ビューが表示されます。
開始するには、GitHub Marketplace から GitHub アカウントまたは組織にアプリをインストールします。 別の Azure アカウントではなく、既存の GitHub 支払いアカウントで追加の並列ジョブを購入することもできます。 価格はどちらの方法でも同じです。
Azure Pipelines を使用してオープンソース プロジェクトを無料でビルドする
Azure Pipelines は、Linux、macOS、および Windows 用のクラウドでホストされるパイプラインを提供し、オープンソースには無制限の分数と 10 個の無料の並列ジョブを提供します。
詳細については、 ビルド パブリック リポジトリ と 並列ジョブ のドキュメントを参照してください。
YAML を使用してビルドを構成する
重要
この機能を使用するには、組織でビルド YAML パイプラインプレビュー機能が有効になっている必要があります。
YAML ベースのビルド パイプラインが広く使用できるようになりました。 コードの残りの部分と共にリポジトリにチェックされた YAML ファイルを使用して、継続的インテグレーション パイプラインを自動化します。 単一ジョブ のビルドを簡単に開始できます。 ニーズの拡大に合わせて、複数のジョブ、外部テンプレート、マトリックス実行を使用して簡単にスケールアウトできます。
新しいウィザードを使用して YAML ビルド パイプラインを作成する
重要
この機能を使用するには、プロファイルまたは組織で 新しい YAML パイプライン作成エクスペリエンスプレビュー機能 が有効になっている必要があります。
新しいウィザードを使用すると、GitHub と Azure Repos を使用して YAML ベースのビルド パイプラインを作成するこのプロセスが簡略化されます。 ビルドするリポジトリを選択すると、YAML ファイルが含まれている場合、パイプラインが自動的に作成されます。 それ以外の場合、Azure Pipelines によってリポジトリが分析され、プロジェクトをビルドするための YAML ベースのテンプレートが推奨されます。 [保存して実行] をクリックして、推奨される YAML のプル要求を作成し、最初のビルドを実行するだけです。 継続的インテグレーションと pull request トリガーは自動的に有効になります。
新しい [ビルド] ページを使用してビルド パイプラインを管理する
重要
この機能を使用するには、プロファイルまたは組織で 新しいビルド ハブプレビュー機能 が有効になっている必要があります。
いくつかの機能強化を行い、[ビルド] ページの新しいバージョンをロールアウトしています。 この新しいバージョンでは、すべてのビルド パイプラインのディレクトリと現在のビルドの一覧が結合されるため、プロジェクトのビルド間をすばやく移動して状態を確認できます。 また、選択したパイプラインのテスト分析のプレビューも含まれています。
GitHub pull request ビルドをリビルドする
GitHub リポジトリに pull request を送信すると、パッケージ レジストリが使用できない、不安定なテストなど、断続的なエラーが発生したため、pull request ビルドが失敗する可能性があります。 このような場合は、もう一度ビルドを実行する必要があります。 現時点では、pull request に別の人工更新をプッシュする必要があります。 これで、新しい [ビルド] ページで、失敗したビルドを選択し、別のビルドをキューに登録できます。
リビルドするこのジェスチャは、プル要求ビルドの開始に対してのみ使用できます。 失敗したすべてのビルドで同様の機能を使用できるようにする方法を検討しています。
新しいビルドステータスバッジの URL
リポジトリのホームページに埋め込まれたビルド バッジは、リポジトリの正常性を示す一般的な方法です。 ビルド バッジの構築に役立つ新しい URL が追加されました。 新しい URL を使用すると、ユーザーはブランチごとの状態を発行でき、選択したブランチの最新のビルドにユーザーを移動できます。 新しい [ビルド] ページで [ステータス バッジ] メニュー アクションを選択すると、新しいステータス バッジ URL のマークダウンを取得できます。 下位互換性のために、古いビルド バッジ URL を引き続き受け入れます。
Microsoft がホストする Linux エージェントでさらに多くのツールを活用する
この更新プログラムでは、Microsoft がホストする Linux エージェントにいくつかのビルド、テスト、およびデプロイ ツールが追加されているため、ビルドまたはリリース中に自分でインストールする必要がなくなります。
- Erlang/OTP
- Firefox
- Haskell
- Heroku CLI
- Imagemagick
- Mercurial
- Microsoft SQL Server クライアント ツール
- MySQL サーバー。
- PhantomJS
- 受粉
- PyPy2 と PyPy3
- rebar
- rsync
- ShellCheck
- Sphinx
- Terraform
- Xvfb
リリースで GitHub のコミットと関連する問題を追跡する
リリースでデプロイされる変更を把握することは、アプリの改善を追跡するために重要です。 GitHub リポジトリで行われたコミットと、リリースでデプロイされている関連する GitHub の問題の一覧を取得できるようになりました。
改善された書式設定を使用してビルドとデプロイの完了メールをより適切に管理する
ビルドとデプロイの完了メールが、電子メール ルールでフィルター処理できるように更新されました。 これで、件名に一目で関連性の高い情報が含まれるようになり、本文に詳細が含まれるようになり、そのスタイルが最新のブランドで更新されました。
新しい形式の要素は次のとおりです。
[Build result] [pipeline name] - [repository:branch] - [project name] - [commit][Deployment result] [pipeline name] > [release name] : [stage name]
次に例をいくつか示します。
[Build succeeded] IdentityService.CI - MyRepo:master - MyProject - d3b90b80[Deployment succeeded] New release pipeline > NotificationSpecialRelease-1 : Stage 1
新しい統合 Azure Pipelines の用語に従う
ビルドとリリースを通じて、似た概念のためにさまざまな用語が歴史的に使用されてきました。 他のケースでは、用語の意味はあいまいでした。 たとえば、エージェント プールとエージェント キューの違いを示します。
用語は、その概念を明確にするために Azure Pipelines で統一されています。 次の統一された用語が表示されます。
| 従来の用語 | 統一された用語 | 意味 |
|---|---|---|
| ホストされたエージェント | Microsoft によってホストされるエージェント | Microsoft によって管理されるクラウドでホストされるインフラストラクチャ上で実行されるビルド/リリース エージェント。 |
| プライベート エージェント | 自己ホスト エージェント | ユーザーが提供および管理するコンピューター上で実行されるビルド/リリース エージェント。 |
| エージェント プール | エージェント プール | ビルドまたはリリースを実行できるエージェント マシンの組織レベルのセット。 |
| エージェント キュー | エージェント プール | ビルドまたはリリースを実行できるエージェント マシンのプロジェクト レベルのセット。 これは、組織レベルのエージェント プールにリンクされています。 |
| ビルド定義 | ビルド パイプライン | アプリケーションのビルド ステップのエンド ツー エンドセット。 |
| Build | Build | 実行中または実行済みのビルド パイプラインのインスタンス。 |
| 段階 | ジョブ | エージェントで順次または並列に実行される一連のタスク。 ビルドまたはリリース パイプラインには、1 つのジョブまたは複数のジョブのグラフを含めることができます。 |
| リリース定義 | リリース パイプライン | さまざまなステージにまたがってアプリケーションをデプロイするための、エンド ツー エンドのリリース手順のセット。 |
| リリース | リリース | 実行中または実行済みのリリース パイプラインのインスタンス。 |
| 環境 | 段階 | リリース パイプラインから生成されたリリースをデプロイする場所を表す論理エンティティと独立エンティティ。 |
| 同時実行ジョブ/パイプライン | 並列ジョブ | 並列ジョブを使用すると、組織内で一度に 1 つのビルドジョブまたはリリース ジョブを実行できます。 使用可能な並列ジョブが増えるので、より多くのビルド ジョブとリリース ジョブを同時に実行できます。 |
| サービス エンドポイント | サービス接続 | ビルドまたはリリースでタスクを実行するために外部サービスに接続するために使用される設定のグループ (資格情報など)。 |
詳細については、 概念に関する ドキュメントを参照してください。
Marketplace
最新の拡張機能カテゴリを活用する
拡張機能の共同作成者として、Marketplace で名前が変更された Azure DevOps Services と一致するように拡張機能カテゴリが調整されていることがわかります。 以前のカテゴリは新しいカテゴリに自動的にマップされていますが、拡張機能のマニフェストを更新して新しいカテゴリに切り替えることをお勧めします。 詳細については、マニフェストのドキュメントを参照してください。
管理
新しい doメイン 名前 URL を使用するように既存の組織を切り替える
新しい組織の URL として新しい dev.azure.com doメイン 名に移動しましたが、通常どおり doメイン を使用してvisualstudio.com引き続き組織にアクセスできます。 URL を基dev.azure.comに変更する場合は、組織管理者 (Project Collection 管理istrator) が組織の設定ページからこれを変更できます。 新しい doメイン 名を採用してもすべての要求がリダイレクトされるわけではありませんが、組織のルート URL への要求や、多くの電子メールや Web ベースのリンクからのリンクは変更されます。
お客様からのフィードバックに基づいて、新しい URL に徐々に移行します。 オプトインとして開始され、後で組織の既定値になります。 組織を意図的に組織からvisualstudio.com移動するためのタイムラインはまだ設定されていませんメイン。
重要
組織が既存のファイアウォールまたは IP 制限に確実に対応できるようにするには、適切な doメイン 名前と IP アドレスが許可されていることを確認します。 詳細については、この エージェントの Q&A セクション を参照してください。
利害関係者ユーザーを追加して Azure Pipelines のライセンス コストを節約する
重要
この機能を使用するには、組織で 有効になっている Pipelines for Stakeholdersプレビュー機能 への無料アクセスが必要です。
うれしいことに、 Azure Pipelines サービスのみを使用している場合は、Basic ライセンスを通じてユーザーの料金を支払う必要がなくなります。 Azure Pipelines のすべての機能は、すべてのユーザーが無料で利用できます。 プロジェクトにユーザーを追加する際に、関係者としてメインを無料で再開し、適切なアクセス許可があれば、パイプラインを作成、表示、更新、承認できるようになります。 このライセンス変更に関する追加の注意事項を次に示します。
- Azure Pipelines の追加の並列ジョブに対してのみ料金が発生します。 ユーザーは無制限です。
- Azure Pipelines 機能へのすべてのアクセスは、セキュリティとアクセス許可のモデルを通じて引き続き管理されます。
- 他の Azure DevOps Services を使用する場合でも、無料制限を超えてこれらのサービスのユーザーごとのライセンスを支払う必要があります。
- 既存の組織では、利害関係者は既定で無料の Azure Pipelines 特典を受け取りません。 組織の管理者 (Project Collection 管理istrator) は、このプレビュー機能を明示的に有効にする必要があります。 このプレビュー機能を有効にすると、利害関係者が実行できる動作が変わります。 現時点では、ビルドやリリースを管理することはできません。 ただし、プレビュー機能が有効になると、Azure Pipelines の Basic ユーザーと利害関係者に違いはありません。 このため、利害関係者を無料の Azure Pipelines ユーザーとして扱うことを許可する選択は、管理者に任されます。
詳細については、 ビルド パイプラインとリリース パイプラインを編集するための利害関係者アクセス権の提供に関する ドキュメントを参照してください。
フィードバックの提供方法
これらの機能に関するご意見をお聞かせください。 フィードバック メニューを使用して、問題を報告したり、提案を提供したりします。
Stack Overflow のコミュニティからアドバイスや質問に回答してもらうこともできます。
よろしくお願いします。
Jeremy Epling
フィードバック
以下は間もなく提供いたします。2024 年を通じて、コンテンツのフィードバック メカニズムとして GitHub の issue を段階的に廃止し、新しいフィードバック システムに置き換えます。 詳細については、「https://aka.ms/ContentUserFeedback」を参照してください。
フィードバックの送信と表示