TeamCity 2022.04 の新機能。

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

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

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

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

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

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

Amazon Web Services との統合の強化

TeamCity 2022.04 では、クラウド統合に新機能が追加されました。

ビルド承認の要求

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

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

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

よりスマートな VCS 統合

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

Space マージリクエスト

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

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

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

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

   

   
   指定した条件に一致するターゲットブランチのみでマージリクエストを監視するには、 ブランチフィルターを指定できます。 たとえば、 +:refs/heads/feature-* フィルターを設定すると、TeamCity はお名前が 機能- で始まるブランチに送信されたマージリクエストのみを監視します。

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

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

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

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

セキュリティ

サーバー上の VCS 関連操作にネイティブ Git を使用する

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

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

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

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

新しい UI

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

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

変更ページ

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

ビルドで生成された Docker イメージをパブリック ECR レジストリに保存する

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

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

ビルドで Docker レジストリ接続 も有効にすることを忘れないでください。

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

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

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

複数のビルドへのアクションの適用

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

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

• タグ

• 別のビルドと比較する

• コメントの追加

• お気に入りに追加

• 除去

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

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

コミットステータスパブリッシャー には、ビルドステータスレポートを Perforce Helix Swarm に送信するための新しいオプション Swarm テストを作成 が追加されました。 これを有効にすると、TeamCity は Helix Swarm サーバーで テスト実行を作成し、TeamCity のビルドステータスに従ってそのステータスを更新します。

パッケージ名にバージョンを含まない Kotlin DSL API

以前の TeamCity バージョンで生成された Kotlin DSL コードには、パッケージ名に v2019_2 を含むインポートがありました。例:

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

コード補完の問題を修正するため、TeamCity 2022.04 では新しいバージョンの DSL API Maven アーティファクトが導入されました。 これらの DSL API アーティファクトのパッケージ名にはバージョンが含まれていません。 新しく生成された 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 ロードマップを参照してください。