TeamCity 2022.04 の新機能

複数のエージェントでの並列テスト

TeamCity は、ビルドのテストをバッチに分割し、各バッチを個別のビルドエージェントで実行できるようになりました。このように、テストは並行して実行され、ビルドはより速く終了します。スピードブースト率は、ビルド内のテストクラスの数と使用されるエージェントの数によって異なります。

詳細については、この記事を参照してください。

高度なコード品質インスペクションと Qodana

Qodana プラグインは TeamCity にバンドルされています。Qodana ビルドランナーを有効にして、静的解析をビルドチェーンに追加し、高度なコードインスペクションを実行し、コードの重複を見つけて、コードのコード品質の進捗状況を追跡できるようになりました。ビルドランナーの詳細については、Qodana を参照してください。

以前にバンドルされていない Qodana プラグインをインストールし、DSL を使用していた場合は、アップグレードに関する注意事項を確認してください。

Amazon Web サービスとの統合の強化

TeamCity 2022.04 は、クラウド統合に新しい機能を追加します。

ビルド承認が必要

実稼働環境での手順によっては、複数の人の承認が必要になる場合があります。TeamCity では、ビルドを実行するために、指定された人またはグループからの手動承認を要求できるようになりました。ユーザーが誤ってビルドをトリガーするのを防ぎ、デプロイ、リソースを消費するビルド、リソースの削除操作をより細かく制御できるようにするには、ビルドのビルド承認機能を構成します。

ブランチごとに実行中のビルドの数を制限する

TeamCity 2022.04 は、ブランチごとに同時に実行されるビルドの数を制限することにより、ビルドエージェントの割り当てを改善できます。例: メインのブランチには、必要な数のビルドエージェントを占有するビルドの数に制限がない場合がありますが、機能ブランチは一度に 1 つのビルドのみを実行するように制限されています。

よりスマートな VCS 統合

TeamCity は、VCS 統合を改善し、次の新機能を提供します。

スペースマージリクエスト

TeamCity と JetBrains Space の統合には、プルリクエストビルド機能が含まれるようになりました。ビルド構成でこの機能を有効にすると、TeamCity は Space リポジトリに送信されたマージリクエストの変更を自動的に検出します。これらの変更に基づいてビルドが実行されると、ビルドの概要にマージリクエストの詳細が表示され、ビルドステータスが JetBrains Space に送信されます。

TeamCity でこの機能を有効にするには:

1. プロジェクト設定で、JetBrains Space への接続を構成し、Space リポジトリ URL と空のブランチ仕様を使用して Git VCS ルートを作成します。

2. ビルド構成設定で、JetBrains Space VCS ホスティングタイプのプルリクエストビルド機能を追加します。
   

   

   
   ブランチフィルターを指定して、指定された基準に一致するターゲットブランチでのみマージ要求をモニターできます。例: +:refs/heads/feature-* フィルターを設定すると、TeamCity は、名前が feature- で始まるブランチにのみ送信されるマージ要求を監視します。

3. JetBrains Space のコミット詳細にビルドステータスを公開できるようにするには、このビルド構成にステータス発行者のコミット機能を追加する必要もあります。

統合が構成されると、TeamCity は JetBrains Space ターゲットブランチに送信されたマージリクエストを検出します。リクエストされた変更に対してビルドが実行されると、マージリクエストの詳細が概要タブに表示されます。

TeamCity は、ビルド変更ごとのステータスを JetBrains Space のマージリクエストのタイムライン (ビルド構成でステータス発行者のコミット機能が有効になっている場合はコミットの詳細) にも送信します。

ターゲットブランチを保護し、検証された要求のみがターゲットブランチにマージされるようにするには、Space リポジトリに品質ゲートをセットアップし、TeamCity ビルドを外部チェックとして使用できます。マージリクエストのビルドが失敗した場合、Space は変更が必要な品質チェックに合格しなかったことを通知します。

セキュリティ

サーバーでの VCS 関連の操作用のネイティブ Git

TeamCity は、サーバーでの Git 操作のデフォルトオプションとしてネイティブ Git を使用できるようになりました。ネイティブ Git に切り替えると、以前に使用された JGit 実装と比較して、サーバーでの変更操作のチェックのパフォーマンスが向上します。また、大規模な Git リポジトリに関連する多くの問題も修正されています。

切り替える前に、ネイティブ Git クライアント(英語)バージョン 2.29 以降がサーバーマシンにインストールされていること、およびその実行可能ファイルへのパスが PATH 環境変数で指定されていることを確認してください。または、teamcity.server.git.executable.path 内部プロパティを介して実行可能ファイルへのフルパスを設定することもできます（サーバーを再起動する必要はありません）。Windows では、パスに二重の円記号を使用することを忘れないでください。

TeamCity サーバーをネイティブ Git に切り替えるには、管理 | 診断に移動し、Git タブを開きます。ここでは、サーバー上の任意の VCS ルートでネイティブ Git を介した接続をテストできます。すべての VCS ルートをテストすることを選択した場合、TeamCity は、JGit を介して正常に接続されているかどうかを確認してから、ネイティブ Git を介して接続をテストします。この対策は、ネイティブ Git に切り替えた後にパイプラインが破損しないようにできます。接続テストが成功した場合は、サーバーでネイティブ Git サポートを有効にできます。

内部 TeamCity サーバーの統計によると、ネイティブ git を使用すると、サーバーでの VCS 関連の操作のパフォーマンスが大幅に向上します。新しい変更とブランチは、JGit と比較して数倍速く表示されます。

新しい UI

エージェントプールの編集

従来の UI モードに切り替えることなく、新しい Sakura UI でエージェントプールを編集し、エージェントとプロジェクトをそれらにすばやく割り当てることができるようになりました。エージェントプールを編集するには、設定でエージェントを割り当てるをクリックします。このダイアログでは、プールに割り当てるエージェントを選択できます。

変更ページ

新しい変更ページには、コメント（コミットメッセージ）、変更されたファイルへのパス、リビジョン番号で変更を並べ替えることができる柔軟な検索オプションを提供するフィルターが付属しています。

パブリック ECR レジストリでのビルドによって生成された Docker イメージの保存

TeamCity は、ビルドによって生成された Docker イメージを、プライベートと（この更新以降）パブリック ECR レジストリの両方に保存できるようになりました。

この機能を使用できるようにするには、プロジェクト設定に Amazon ECR 接続を追加し、ECR パブリックレジストリタイプを選択する必要があります。

ビルドで Docker サポートも有効にすることを忘れないでください。

外部システムからのユーザーアバターの自動インポート

ユーザーが GitHub や Bitbucket などの TeamCity サードパーティのアカウント経由に初めてサインインすると、TeamCity は自動的に外部システムからアバターを取得し、それを TeamCity ユーザープロファイルに接続します。TeamCity は、確認済みのメールを持つユーザーのアバターにのみアクセスできることに注意してください (GitLab を使用している場合は、アカウントにパブリックメールが設定されていることを確認してください)。

後で TeamCity ユーザープロファイル設定で別のアバターをアップロードすることができます。

複数のビルドにアクションを適用する

複数のビルドを選択して、それらすべてに一度にアクションを適用できるようになりました。

• ピン留め / ピン留め解除

• タグ

• 別のビルドと比較する

• コメントの追加

• お気に入りに追加

• 除去

ビルド構成ホームの概要タブで、ビルドにカーソルを合わせると表示されるチェックボックスを使用して、必要なビルドを選択できます。それらにアクションを適用するには、ポップアップコンテキストメニューのそれぞれのコマンドを使用します。ビルドの範囲を選択する必要がある場合は、Shift を押して、選択する範囲の端にあるビルドチェックボックスをクリックします。

Perforce 統合: HelixSwarm テスト実行の自動作成とビルドとのステータス同期

ステータス発行者のコミットには、ビルドステータスレポートを Perforce Helix Swarm — スウォームテストを作成するに送信するための新しいオプションがあります。これを有効にすると、TeamCity は Helix Swarm サーバーでテスト実行を作成し(英語)、TeamCity のビルドステータスに従ってそのステータスを更新します。

パッケージ名にバージョンがない Kotlin DSLAPI

以前の TeamCity バージョンによって生成された Kotlin DSL コードには、パッケージ名に v2019_2 が含まれるインポートが含まれていました。例:

TeamCity 2019.2 以降、DSL API に互換性のない大きな変更がなかったため、新しい DSLAPI パッケージはありませんでした。しかし、パッケージのいくつかのバージョンの存在は、異なるバージョンのパッケージからのいくつかの同様のクラスを提案する場合、IntelliJ IDEA のコード補完で常に問題を引き起こします。

コード補完の問題を修正するために、新しいバージョンの DSLAPI Maven アーティファクトが TeamCity 2022.04 に導入されます。これらの DSLAPI アーティファクトには、パッケージ名にバージョンが含まれていません。新しく生成された Kotlin DSL コードは、これらのバージョン管理されていないアーティファクトに自動的に切り替えられます。既存の Kotlin DSL プロジェクトは手動で切り替えることができます。

UI を介してプロジェクトの SSH キーの公開部分を取得する

アップロードされた暗号化されていない SSH キーの公開部分をプロジェクト設定からコピーできるようになりました。これを行うには、プロジェクト設定 | SSH キーに移動し、キー名にある公開鍵をコピーするをクリックします。

これにより、プロジェクト管理者は、必要なときにいつでもシステム管理者に公開 SSH キーを要求する必要がなくなります（たとえば、TeamCity プロジェクトを VCS ホスティングサービスと統合するため）。TeamCity UI を介して取得できます。

その他の更新

• キューに入れられたビルドの最適化の改善 TeamCity 2022.04 より前では、キュー内のビルドは、すでに開始または終了したビルドのみに最適化できました。たとえば、キューに 2 つのビルドチェーン（A -> B と A -> C）がある場合、両方のビルドチェーンのキューに入れられたビルド A は、同じ設定とリビジョンを持つ別の実行中または終了したビルド A がある場合にのみ、ビルドキューオプティマイザーで置き換えることができます。

  TeamCity 2022.04 以降、このアルゴリズムは改善され、キューに残っているビルドを再利用できるようになりました。上記の例では、両方のビルドチェーンがキューに残っている間にマージされるため、両方のビルドチェーンは同じキューに入れられたビルド A を使用します。

• ビルド失敗条件: 一致するエラーごとにビルドの問題を作成する
  ビルドログの失敗条件 で特定のテキストに基づいてビルドを失敗させるように構成する場合、ビルドログで見つかった最初のテキストの出現に対してのみビルドの問題を作成するか (デフォルト)、指定したパターンに一致する各エラーに対してビルドの問題を作成するかを指定できるようになりました。

• Eclipse プラグインは TeamCity からバンドル解除されました。プラグインが必要な場合はサポートにお問い合わせください(英語)。

修正された問題

TeamCity 2022.04 リリースノートを参照

アップグレードノート

アップグレードする前に、2021.2.x と比較したバージョン 2022.04 の重要な変更点について読むことを強くお勧めします。

以前のリリース

• TeamCity 2021.2 の新機能

• TeamCity 2021.1 の新機能

• TeamCity 2020.2 の新機能

• TeamCity 2020.1 の新機能

• TeamCity 2019.2 の新機能

• TeamCity 2019.1 の新機能

ロードマップ

将来のアップデートについては、TeamCity ロードマップを参照してください。