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 Test Plans 。
Azure Pipelines の立ち上げに伴い、新しいアプリを GitHub Marketplace に導入し開始に役立つエクスペリエンスの数を更新し、オープンソース プロジェクトに対して制限されていない CI/CD 分と 10 個の並列ジョブを提供しました。
詳細については、以下の Features 一覧を参照してください。
機能
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 を追加する
新しい Azure Pipelines アプリは、GitHub Marketplace GitHub リポジトリとの統合を拡張し、並列ジョブの購入を効率化します。
以前は、OAuth 認証を使用して GitHub リポジトリとの継続的インテグレーションを有効にできました。 Azure Pipelines では、OAuth を使用して、 個人の GitHub ID を使用してコードをフェッチし、GitHub でビルドの状態を更新します。 ただし、チームのメンバーは時間の経過と同時に変化する可能性があるため、個人の GitHub ID とアクセス許可を使用することは望ましくない場合があります。 Azure Pipelines アプリをインストールすることで、代わりにアクションを実行 アプリ を承認できます。
また、アプリを使用すると、ビルド結果が GitHub の新しい Checks 機能で利用できるようになり、ビルド、テスト、コード カバレッジの結果の詳細なビューが表示されます。
開始するには、GitHub Marketplace から GitHub アカウントまたは組織にアプリ をインストールします。 別の Azure アカウントではなく、既存の GitHub 支払いアカウントで追加の並列ジョブを購入することもできます。 価格はどちらの方法でも同じです。
Azure Pipelines を使用してオープンソース プロジェクトを無料でビルドする
Azure Pipelines は、Linux、macOS、および Windows 用のクラウドでホストされるパイプラインを提供し、オープンソースには無制限の分数と 10 個の無料の並列ジョブを提供します。
詳細については、 ビルドパブリック リポジトリ および parallel ジョブ ドキュメントを参照してください。
YAML を使用してビルドを構成する
重要
この機能を使用するには、組織で Build YAML パイプライン プレビュー機能 が有効になっている必要があります。
YAML ベースのビルド パイプラインが広く使用できるようになりました。 リポジトリにチェックインされた YAML ファイルを使用して コードの残りの部分と共に継続的インテグレーション パイプラインを自動化します。 単一ジョブ のビルドを簡単に開始できます。 ニーズが拡大するにつれて、 マルチプル ジョブ、 、 external テンプレート、 matrix 実行を使用して簡単にスケールアウト。
新しいウィザードを使用して YAML ビルド パイプラインを作成する
重要
この機能を使用するには、プロファイルまたは組織で 新しい YAML パイプライン作成エクスペリエンス プレビュー機能 が有効になっている必要があります。
新しいウィザードを使用すると、GitHub と Azure Repos を使用して YAML ベースのビルド パイプラインを作成するこのプロセスが簡略化されます。 ビルドするリポジトリを選択すると、YAML ファイルが含まれている場合、パイプラインが自動的に作成されます。 それ以外の場合、Azure Pipelines によってリポジトリが分析され、プロジェクトをビルドするための YAML ベースのテンプレートが推奨されます。 [保存して実行] クリックするだけで 提案された YAML のプル要求を作成し、最初のビルドを実行します。 継続的インテグレーションと pull request トリガーは自動的に有効になります。
新しい [ビルド] ページを使用してビルド パイプラインを管理する
重要
この機能を使用するには、プロファイルまたは組織で New ビルド ハブ プレビュー機能 が有効になっている必要があります。
いくつかの機能強化を行い、 Builds ページの新しいバージョンをロールアウトしています。 この新しいバージョンでは、すべてのビルド パイプラインのディレクトリと現在のビルドの一覧が結合されるため、プロジェクトのビルド間をすばやく移動して状態を確認できます。 また、選択したパイプラインのテスト分析のプレビューも含まれています。
![[新しいビルド] ページ](media/launch_03.png)
GitHub pull request ビルドをリビルドする
GitHub リポジトリに pull request を送信すると、パッケージ レジストリが使用できない、不安定なテストなど、断続的なエラーが発生したため、pull request ビルドが失敗する可能性があります。 このような場合は、もう一度ビルドを実行する必要があります。 現時点では、pull request に別の人工更新をプッシュする必要があります。 これで、 新しい Builds ページで 失敗したビルドを選択し、別のビルドをキューに登録できます。
リビルドするこのジェスチャは、プル要求ビルドの開始に対してのみ使用できます。 失敗したすべてのビルドで同様の機能を使用できるようにする方法を検討しています。
新しいビルドステータスバッジの URL
リポジトリのホームページに埋め込まれたビルド バッジは、リポジトリの正常性を示す一般的な方法です。 ビルド バッジの構築に役立つ新しい URL が追加されました。 新しい URL を使用すると、ユーザーはブランチごとの状態を発行でき、選択したブランチの最新のビルドにユーザーを移動できます。 新しいステータス バッジ URL の Markdown を取得するには、新しい Builds ページ で Status バッジメニュー アクション選択。 下位互換性のために、古いビルド バッジ 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 の用語に従う
ビルドとリリースを通じて、似た概念のためにさまざまな用語が歴史的に使用されてきました。 他のケースでは、用語の意味はあいまいでした。 たとえば、 agent プール と agent キューの違いを示。
用語は、その概念を明確にするために Azure Pipelines で統一されています。 次の統一された用語が表示されます。
| 従来の用語 | 統一された用語 | 意味 |
|---|---|---|
| ホストされたエージェント | Microsoft によってホストされるエージェント | Microsoft によって管理されるクラウドでホストされるインフラストラクチャ上で実行されるビルド/リリース エージェント。 |
| プライベート エージェント | 自己ホスト エージェント | ユーザーが提供および管理するコンピューター上で実行されるビルド/リリース エージェント。 |
| エージェント プール | エージェント プール | ビルドまたはリリースを実行できるエージェント マシンの組織レベルのセット。 |
| エージェント キュー | エージェント プール | ビルドまたはリリースを実行できるエージェント マシンのプロジェクト レベルのセット。 これは、組織レベルのエージェント プールにリンクされています。 |
| ビルド定義 | ビルド パイプライン | アプリケーションのビルド ステップのエンド ツー エンドセット。 |
| ビルド | ビルド | 実行中または実行済みのビルド パイプラインのインスタンス。 |
| フェーズ | ジョブ | エージェントで順次または並列に実行される一連のタスク。 ビルドまたはリリース パイプラインには、1 つのジョブまたは複数のジョブのグラフを含めることができます。 |
| リリース定義 | リリース パイプライン | さまざまなステージにまたがってアプリケーションをデプロイするための、エンド ツー エンドのリリース手順のセット。 |
| リリース | リリース | 実行中または実行済みのリリース パイプラインのインスタンス。 |
| 環境 | 段階 | リリース パイプラインから生成されたリリースをデプロイする場所を表す論理エンティティと独立エンティティ。 |
| 同時実行ジョブ/パイプライン | 並列ジョブ | 並列ジョブを使用すると、組織内で一度に 1 つのビルドジョブまたはリリース ジョブを実行できます。 使用可能な並列ジョブが増えるので、より多くのビルド ジョブとリリース ジョブを同時に実行できます。 |
| サービス エンドポイント | サービス接続 | ビルドまたはリリースでタスクを実行するために外部サービスに接続するために使用される設定のグループ (資格情報など)。 |
詳細については、 Concepts ドキュメントを参照してください。
Marketplace
最新の拡張機能カテゴリを活用する
拡張機能の共同作成者として、 Marketplaceで名前が変更された Azure DevOps Services と一致するように拡張機能カテゴリが調整されていることがわかります。 以前のカテゴリは新しいカテゴリに自動的にマップされていますが、拡張機能のマニフェストを更新して新しいカテゴリに切り替えることをお勧めします。 詳細については、 Manifest ドキュメントを参照してください。
管理
新しいドメイン名 URL を使用するように既存の組織を切り替える
新しい組織の URL として新しい dev.azure.com ドメイン名に移動しましたが、通常どおり、 visualstudio.com ドメインを使用して組織に引き続きアクセスできます。 dev.azure.comに基づいて URL を変更する場合は、組織管理者 (プロジェクト コレクション管理者) が組織の設定ページからこれを変更できます。 新しいドメイン名を採用してもすべての要求がリダイレクトされるわけではありませんが、組織のルート URL への要求や、多くの電子メールや Web ベースのリンクからのリンクは変更されます。
お客様からのフィードバックに基づいて、新しい URL に徐々に移行します。 オプトインとして開始され、後で組織の既定値になります。 visualstudio.com ドメインから意図的に組織を移動するためのタイムラインはまだ設定されていません。
重要
組織が既存のファイアウォールまたは IP 制限に対応していることを確認するには、適切なドメイン名と IP アドレスが許可されていることを確認します。 詳細については、この agent Q&A セクション を参照してください。
利害関係者ユーザーを追加して Azure Pipelines のライセンス コストを節約する
重要
この機能を使用するには、組織で有効になっている Free の Pipelines for Stakeholders preview 機能 アクセスできる必要があります。
うれしいことに、 Azure Pipelines サービスのみを使用している場合は、Basic ライセンスを通じてユーザーの料金を支払う必要がなくなります。 Azure Pipelines のすべての機能は、すべてのユーザーが無料で利用できます。 プロジェクトに追加するユーザーを増やすと、ユーザーを利害関係者として無料で維持できます。適切なアクセス許可があれば、パイプラインを作成、表示、更新、承認できます。 このライセンス変更に関する追加の注意事項を次に示します。
- Azure Pipelines の追加の並列ジョブに対してのみ料金が発生します。 ユーザーは無制限です。
- Azure Pipelines 機能へのすべてのアクセスは、セキュリティとアクセス許可のモデルを通じて引き続き管理されます。
- 他の Azure DevOps Services を使用する場合でも、無料制限を超えてこれらのサービスのユーザーごとのライセンスを支払う必要があります。
- 既存の組織では、利害関係者は既定で無料の Azure Pipelines 特典を受け取りません。 組織の管理者 (プロジェクト コレクション管理者) は、このプレビュー機能を明示的に有効にする必要があります。 このプレビュー機能を有効にすると、利害関係者が実行できる動作が変わります。 現時点では、ビルドやリリースを管理することはできません。 ただし、プレビュー機能が有効になると、Azure Pipelines の Basic ユーザーと利害関係者に違いはありません。 このため、利害関係者を無料の Azure Pipelines ユーザーとして扱うことを許可する選択は、管理者に任されます。
詳細については、ビルド パイプラインとリリース パイプラインを編集するための Provide Stakeholders アクセス ドキュメントを参照してください。
フィードバックの提供方法
これらの機能に関するご意見をお聞かせください。 フィードバック メニューを使用して、問題を報告したり、提案を提供したりします。
Stack Overflow のコミュニティからアドバイスや質問に回答してもらうこともできます。
よろしくお願いします。
Jeremy Epling