TeamCity 2021.1 の新機能。

Kotlin スクリプトビルドランナー

JetBrains (英語) による Kotlin は、広く採用されている簡潔なプログラミング言語です。 TeamCity がサポートするすべてのプラットフォームで動作し、ビルドタスクのスクリプト化に最適です。 TeamCity でのこのようなツールへの高い需要に応えるため、新しい Kotlin スクリプトビルドランナーを設計しました。

カスタムチェック、 サービスメッセージの送信、HTTP 経由のファイルのダウンロードなど、繰り返し行うルーチンを自動化するために使用できます。 Ant または コマンドラインビルドステップを使用していて、代わりに Kotlin を試したい場合、新しいランナーはそのための良い機会になります。 Kotlin でタスクを書き換えて、既存のビルドステップを新しいランナーに切り替えるだけです。

Kotlin スクリプトビルドステップを構成するには、スクリプトコードを入力するか、スクリプトコードへのパスを指定します。 デフォルトでは、TeamCity は Kotlin 1.5.0 を使用して実行しますが、 管理 | ツール に他の任意のコンパイラーバージョンをインストールできます。

詳しくは この記事を読む。

Node.js ビルドランナー

TeamCity で JavaScript プロジェクトをビルドする体験を向上させるため、 Node.js 専用のビルドランナーを導入します。 ビルド内で npm (英語)、 yarn (英語)、 ノード (英語) コマンドを実行し、詳細なテスト結果をレポートできます。

Node.js ステップを手動で追加するか、TeamCity にプロジェクトのリポジトリをスキャンさせることができます。 スキャン時に、TeamCity は パッケージ.json ファイルを解析して、プロジェクトで使用されているフレームワークを確認します。 この情報に基づいて、必要な依存関係のインストールやテストの実行など、それぞれのビルドステップの追加が提案されます。 必要に応じて、後でこれらの手順を調整できます。

プロジェクトに ESlint、 Jest 、または Mocha の依存関係がある場合、TeamCity は対応するテスト結果をビルド概要に直接表示します。

Node.js ビルドステップを構成するには、必要なシェルコマンドを含むスクリプトを入力するだけです。

現在、すべての Node.js ステップは Docker/Podman コンテナー内で実行されるため、ビルドエージェントに Docker(英語) または Podman(英語) をインストールする必要があります。 TeamCity はデフォルトで ノード:lts バージョンを使用しますが、プロジェクト内に .nvmrc ファイルがある場合は、そこでイメージ仕様を検索します。

詳しくは この記事を読む。

自動的にトリガーされるビルドをカスタマイズする

ビルドトリガーは、カスタムパラメーターをサポートするようになりました。 この機能により、自動的にトリガーされるビルドがカスタム実行モードで開始されたビルドと同じように用途が広がるため、ユーザーはこの機能を期待していました。

このインストルメントを使用して、同じ構成内で異なるビルドを自動実行する方法には、無限の組み合わせがあります。 最も重要なことは、ソースブランチや起動時間などの前提条件に応じて、同じスクリプトでトリガーされたビルドを異なるターゲットにデプロイできるようになったことです。

ビルドトリガーの設定では、次のオプションを含む新しい ビルドカスタマイズ タブを見つけることができます。

• 一般設定: トリガーされたすべてのビルドをクリーンなソースで開始する必要がある場合は、 チェックアウトディレクトリ内のすべてのファイルを削除することを選択します。

• ビルドパラメーター: 現在のビルド構成で使用される任意の パラメーターの値をカスタマイズします。 または、新しいパラメーターを追加すると、このトリガーによって開始されたビルドでのみ使用できるようになります。 これを使用して、 依存関係ビルド構成のパラメーターをオーバーライドすることもできます。そのためには reverse.dep.<dependencyBuildID>.<property> 構文を使用します。

この機能は、 ビルドステップの実行条件と組み合わせるとさらに効果的になります。 ステップにパラメーターベースの条件を追加してから、二つのトリガーを構成するだけです。一方はこのステップを含むビルドを実行し (条件が満たされた場合)、もう一方は含まないビルドを実行します。 一般的なユースケースとして、失敗したビルドが 再試行トリガーで再開されたときに追加のクリーンアップステップを実行することが挙げられます。これにより、ユーザーが関与しなくても多くのビルド問題を解決できます。

マルチノードセットアップの改善

TeamCity の最優先事項の 1 つは、ビルドプロセスに高可用性ソリューションを提供することです。 このリリースでは、パフォーマンスが高く安定したクラスター設定を簡単に構成できるようにする複数の更新を導入しました。

ランタイムでノードをセカンダリからメインに切り替える

これで、メインノードが何らかの理由でダウンした場合、そのメインのロールとそれぞれのロールを別のサーバーに迅速に割り当てることができます。

デフォルトでは、新しい「メイン TeamCity ノード 」の責任は現在のメインサーバーにありますが、このサーバーが利用できなくなると空きになります。 その後、 管理 | ノード構成 内の任意のセカンダリサーバーに割り当てることができます。

割り当てられたサーバーがメインノードになり、他のすべての責任 (ビルドの処理、エージェントの管理など) を自動的に受け取ります。 この新しいメインノードは、実行中のすべてのビルドを保持し、 セットアップでプロキシが構成されている場合、エージェントは自動的にそのビルドに再接続します。

以前のメインサーバーが再び起動すると、「メイン TeamCity ノード 」の責任はすでに別のサーバーによって占有されているため、セカンダリノードになります。 必要に応じて、上記の手順を繰り返して、これらのサーバー間のロールを切り替えることができます。

セカンダリノード上のビルド最大数を管理する

セカンダリノードがビルド処理に割り当てられている場合、実行できる並列ビルドの数を制限できるようになりました。 以前は、ノードに対して「ビルドの実行によって生成されたデータの処理 」責任が有効になっていると、すべてのビルドが処理されていました。 現在は、複数のノード間で負荷を分散したり、一部のビルドをメインノードに割り当てたままにしたりすることもできます。

制限を設定するには、 管理 | ノード構成 に移動し、リストから必要なノードを見つけて、その「ビルドの実行によって生成されたデータの処理 」責任の横にある 編集 をクリックします。 ビルドを制限するダイアログで、このノードで実行できるビルドの相対制限を入力します。 ノードのハードウェア機能に応じて制限を設定することをお勧めします。

すべてのセカンダリノードで許可されたビルドの上限に達した場合、TeamCity は、いずれかのセカンダリノードがビルドを完了するまで、メインノードで新しいビルドを開始します。

Elastic ベースの新しい検索モード

ローカルの Lucene ベースの検索の代わりに、TeamCity は Elasticsearch ベースの検索モードを提供するようになりました。 どちらのモードでも、番号、タグ、その他多くのパラメーターでビルドを検索できます。 主な違いは検索インデックスの場所です。TeamCity サーバーの隣、または Elastic ホスト上に保存できます。

新しいモードには次の利点があります: (1) TeamCity サーバーマシンのディスク容量を節約でき、(2) TeamCity のパフォーマンスに優れています。 マルチノードインストールでは特に効果的です。ノードは複数のローカルインデックスよりも単一のリモートインデックスを維持するほうが少ないリソースで済むためです。
比較的小規模なインストールでは、何も再構成せずに Lucene 検索を引き続き使用できます。

プロジェクト設定 | ビルド検索 のルートプロジェクトレベルで検索モードを選択できます。 Elastic ホストまたはクラスターに接続するには、その URL と資格情報を入力します。

新しい設定を保存すると、TeamCity はビルドの再インデックスにしばらく時間をかけます。 正確な所要時間はサーバーのサイズによって異なります。 進行状況は 診断テーブルで追跡または制御できます。

読み取り専用プロジェクト設定

バージョン管理されたプロジェクト設定は、TeamCity で最も人気のある機能の 1 つです。 フィードバックに基づいて、この機能にさらに多くの制御を追加し続けています。このバージョン以降、TeamCity UI でプロジェクト設定を読み取り専用にできます。

プロジェクトの設定の同期が有効になっている場合、UI で行われたすべての変更は設定リポジトリにコミットされ、その逆も同様です。 ただし、場合によっては、UI による設定の編集を禁止すると便利な場合があります。 例: プロジェクト設定をそのソースコードと同じリポジトリに保存する場合、VCS を使用してすべての変更を完全に追跡および承認することができます。 また、読み取り専用ブランチから設定をインポートして UI で変更した場合、TeamCity はリポジトリへのコミットバックに失敗し、その結果、VCS で行われた新しい変更を適用します。

このようなケースや同様のケースに対処するために、新しいオプション UI 経由でプロジェクト設定を編集できるようにするを追加しました。 プロジェクトで無効にすると、そのプロジェクトの設定は UI で読み取り専用になり、TeamCity が設定のリポジトリへコミットするのを防ぎます。

新しいオプションを切り替えるには、 プロジェクト設定 | バージョン対応設定 | 構成 に移動します。

詳しくは この記事を読む。

アクセストークンの権限を制限する

制限付きのアクセス許可を持つアクセストークンを作成し、これらのトークンを REST API リクエストに使用できるようになりました。 これにより、スクリプトを TeamCity と統合する方法をより細かく制御できます。 例: タイムアウト設定と組み合わせて使用すると、特定のタスクに対して有効期間の短いトークンを生成できます。

デフォルトでは、トークンの 権限の範囲は "現在のユーザーと同じ " に設定されています。 これは、作成されたトークンが現在のユーザーと同じ 権限を付与することを意味します。 このようなトークンは、UI での認証と REST API リクエストの両方に使用できます。

スコープを「プロジェクトごとの制限 」に変更すると、トークンのアクセスを特定のプロジェクトに制限し、特定の権限を選択することもできます。 使用可能なプロジェクトと権限のリストは、ユーザーロールによって異なります。 スコープが制限されたトークンは、REST API リクエストにのみ使用できます。

Perforce サポートの改善

このリリースでは、 Perforce(英語) でバージョン管理されたプロジェクトに複数の改善が加えられています。

Perforce サーバー上のストリームワークスペースをクリーンアップする

TeamCity では Perforce ストリームを機能ブランチとして使用できます。 このようなストリームの変更を最適に処理するには、Perforce サーバー上に専用のワークスペースを作成して維持する必要があります。 時間が経つにつれて、これらのワークスペースは Perforce サーバーのマシン上で大量のリソースを消費する可能性があります。 また、タスクストリームを閉じる場合、それに関連付けられたワークスペースがあると閉じることができません。 これらの問題は両方とも、不要になったワークスペースを削除することで解決できます。 以前は、自動的にクリーンアップする手段がなく、手動でクリーンアップするには Perforce サーバー管理者の関与が必要でした。 新しい Perforce 管理者アクセス接続を使用すると、プロジェクト管理者は TeamCity UI から直接ワークスペースをクリーンアップできます。

この統合を構成するには:

1. プロジェクト設定を開き、 接続設定タブに移動します。

2. Perforce 管理者アクセスタイプで新しい接続を追加します。 Perforce サーバーにアクセスするためのホストとユーザーの資格情報を入力すると (ユーザーには 管理者権限が必要です)、TeamCity がサーバーに接続します。

クリーンアップのたびに、TeamCity は 7 日を超えて非アクティブなワークスペースを検出して削除します。 または、接続設定でこれらのワークスペースを削除をクリックして、いつでも削除できます。 ワークスペースはサーバー上でのみ削除され、ビルドエージェント上では削除されません。また、TeamCity によって作成された場合にのみ削除されることに注意してください。

機能ブランチのサポートが Perforce ルートで有効になっている場合、このルートで使用可能なストリームに関連付けられているワークスペースを削除することもできます。 ビルド構成ホーム に移動し、 アクション メニューを開き、 Perforce ストリームワークスペースの削除 をクリックします。 デフォルトでは、このアクションはプロジェクト開発者ロールを持つすべてのユーザーが使用できます。 このメニューでは、ストリームへのパスを指定でき、TeamCity は Perforce サーバー上の関連ワークスペースを削除します。

オンボーディング UI アシスタント

TeamCity には豊富なユーザーインターフェースがあり、多数の便利な機能の一部は初心者にはわかりにくい場合があります。 新規ユーザーがインターフェースを移動できるように、オンボーディング UI アシスタントを紹介します。

有効にするには、画面の右上隅にある ヘルプ メニューを開き、 ヒントを表示 をクリックします。 アシスタントメニューを閉じることで、いつでも非表示にできます。

特定の要素のヒントを表示するには、アシスタントメニューでその名前にカーソルを合わせます。 一部のヒント名は、関連ドキュメントへの リンクも提供します。

ヒントは、 実験的なプロジェクトホーム、 ビルド構成ホーム 、および ビルド概要 、一部の 設定 ページで利用できます。

実験的 UI の改善

実験的 UI は開発中です。早期段階の機能を導入しているため、すでにそれらのメリットを得ることができます。 各リリースでは、既存のページを磨き上げ、重要なクラシック機能をすべて新しい UI で再現しています。

実験的 UI のロードマップは、ユーザーからのフィードバックに大きく依存しています。 バージョン 2021.1 では、ビルド概要ページの改善に重点を置きました。以下で、 テストのツリーモードと新しい コードカバレッジの可視化について説明します。 また、ご要望に基づいて デザインを調整したプロジェクトホーム ページにしました。

ビルド概要でテストをツリーモードで表示する

ビルド詳細を開くとき、テスト結果は多くの場合、探している最も重要な情報です。 実験的 UI でテストをどのように表示するかを改善し続けています。目標は、クラシック UI で利用できるすべてのツールを再現し、さらに使いやすくすることです。 新しい UI で、 ビルド概要 のテストツリーモードがサポートされるようになりました。

テストブロックで グループ化されたテストを表示 をクリックすると、TeamCity はテストを プロジェクト → ビルド構成 → テストスイート → テストパッケージ → テストクラス ごとにグループ化したツリーモードで表示します。 現在のタスクに応じて、いつでもツリー構造とフラット構造を切り替えることができます。

同じグループ内のテストは目的が似ているため、すばやくすべて選択したり、一時的に折りたたんで他のグループに集中したりできます。 ツリーモードはこれに非常に適しており、ビルド構成に多数のテストがある場合に特に役立ちます。 グループを選択すると、 調査 や ミュート などのアクションを、そのグループのすべてのテストに一度に適用できます。

キーボードナビゲーションを使用する場合は、 アップ および ダウン キーを使用してツリーを移動し、 Space キーを使用して選択したグループまたはテストを折りたたんだり展開したりします。

新しいコードカバレッジプレビュー

TeamCity は 複数のビルドランナーにコードカバレッジを提供できます。 このリリースでは、 ビルド概要 のコードカバレッジプレビューがさらに視覚的になりました。

ビルド構成でカバレッジが利用できる場合は、ビルドのテストの視覚化された統計をすばやくプレビューして、前のビルドと比較してどのように変化したかを確認できます。

洗練されたプロジェクトホーム

試験的な プロジェクトホーム ページに関するフィードバックを集めた後、2 つのタスクに注力しました: このページのスペースをより効果的に使用することと、プロジェクトツリーをより簡単にナビゲートできるようにすることです。 洗練されたページが、同じプロジェクトのすべてのビルドをプレビューして実行するための便利なダッシュボードとして役立つことを願っています。

個人用パッチを使用したビルドのカスタマイズを制限する

TeamCity では、VCS に保存されている共通プロジェクトのコードを実際に変更せずに、ローカル変更を含むカスタムビルドを実行できます。 このようなビルドを実行するには、変更を含むパッチを TeamCity サーバーに送信する必要があります。IDE の リモート実行を使用するか、UI または REST API 経由で アップロードします。 このパッチはビルドエージェントマシンに配信され、カスタムビルドでのみ使用されます。 ただし、パッチはエージェントのファイルシステムに保存されるため、このエージェントで実行される次のビルドに潜在的な害を与えない、信頼できる変更のみが含まれていることを確認するのが賢明です。

この目的のために、新しい ユーザー権限 カスタムパッチでビルドソースコードを変更するを作成しました。 2021.1 にアップグレードすると、デフォルトのプロジェクト開発者ロールと、 ビルドパラメーターをカスタマイズする権限を持つその他のロールに対して自動的に有効になります。 この権限を切り替えることで、ビルドにパッチを適用できるユーザーを細かく制御したり、必要に応じて重要なプロジェクトでこの機能を完全に制限したりできます。

Amazon S3 へのアーティファクトのマルチパートアップロードをカスタマイズする

ビルドアーティファクトを Amazon S3 に保存すると、アップロード方法を制御できるようになりました。 TeamCity はデフォルトで大きなファイルの マルチパートアップロードを使用しますが、アップロードしきい値とアップロードパートサイズというパラメーターをカスタマイズできるようになりました。 これにより、ネットワーク帯域幅をより効果的に使用し、スループットを向上させることができます。

ビルド構成ごとに複数の VCS トリガーを追加する

ビルド構成に複数の VCS トリガーを追加できるようになりました。 これは、同じ構成で異なるトリガールールに従って、異なるブランチフィルターを使用してビルドをトリガーする場合に便利です。 これにより、新しい変更がコミットされるとすぐにビルドが開始される 1 つを除いて、すべてのブランチのビルドに 沈黙期間を設定できます。 または、指定された 1 つのブランチでのみ、チェックインごとにビルドを開始するようにトリガーを構成できます。

Git ルートのチェックアウトポリシーを選択する

Git VCS ルートには、新しい チェックアウトポリシーオプションがあります。 ビルドエージェントのライフサイクルに応じて、4 つのポリシーから選択して、さまざまなメリットを得ることができます。

デフォルトのポリシーは AUTO です。これは、判断が常に TeamCity に委ねられることを意味します。 ただし、他のオプションのいずれかを選択することで、VCS ルートに特定のポリシーを適用できます。

• 鏡を使う: 多数のビルドを実行する長期稼働エージェントに最適です。 リポジトリミラーがエージェント上に保持されるため、連続ビルドが高速化されます。

• ミラーを使用しないでください: ミラーを作成せずに、ビルドチェックアウトディレクトリ内のリポジトリを取得するだけです。 Less はディスク使用量の点で最適であり、既存のビルド構成との下位互換性のために保持されています。

• 浅いクローン: 短命のエージェント（クラウド内の使い捨てエージェントなど）に最適です。 1 つのビルドに必要な 1 つのリビジョンのみを取得します。 これにより、特にプロジェクトリポジトリに長いリビジョン履歴がある場合に、ビルドの開始が大幅に速くなります。

詳しくは この記事を読む。

コンテナー内で実行中のプロセスのスレッドダンプを表示する

TeamCity では、ビルドエージェントマシンで実行中のプロセスのスレッドダンプをビルド結果で直接表示できます。 プロセスがコンテナー内で実行されている場合でも、これを表示できるようになりました (たとえば、 コンテナーラッパー または Docker Compose 機能を使用)。 Windows コンテナーの場合、TeamCity は Java プロセスとそのスレッドダンプを表示します。 Linux コンテナーの場合、実行中のすべてのプロセスと Java プロセスのスレッドダンプを表示します。

ビルドの実行中に、その 概要 で スレッドダンプを表示 をクリックします。

TeamCity は、エージェントプロセスに関する構造化された情報を表示します。

ビルドステータスウィジェットへのクイックアクセス

ビルドステータスウィジェットには、構成内の最後のビルドのステータスが表示されます。 ウィジェットは認証を必要としないため、TeamCity の外部の任意の場所 (たとえば GitHub) にビルドステータスアイコンを表示できます。 これで、 ビルド概要 からこのウィジェットにすばやくアクセスできるようになりました。

ビルド構成ホーム からウィジェットメニューにアクセスするには、 アクション メニューを開き、 ビルドステータスアイコンを取得 をクリックします。

ステータスイメージメニューにはアイコンのプレビューが表示され、サポートされている形式のいずれかでコードをコピーできます。

このコードを外部ページに埋め込み、TeamCity を開かずにビルドステータスを表示できます。

その他の改善

• クロスプラットフォーム ReSharper インスペクションと重複ファインダー
  ReSharper、 インスペクション、 重複ファインダーはクロスプラットフォームモードをサポートするようになり、Docker 内で実行できるようになりました。

• ビルドエージェントの .NET SDK 要件の設定
  .NET ビルドランナーで、ビルドエージェントにインストールされている SDK に対する要件を設定できるようになりました。 .NET ステップを構成するときに、想定される SDK バージョンのリストを入力できます。TeamCity はエージェント要件を自動的に作成し、現在のビルドは必要な SDK をすべて備えたエージェントでのみ実行されます。

• Python ランナーの更新

  • Python ステップは、 Venv 仮想環境内で実行できます。

  • ランナーは、Flake8、Pylint、Pytest がビルドエージェントにない場合、自動的にインストールできます。

  • ランナーは、依存関係をパッケージ化および管理するための Poetry(英語) 環境ツールをサポートします。

• Marketplace プラグインの検証
  TeamCity は、 JetBrains Marketplace からインストールされたすべての新しいプラグインが有効な証明書で署名されているかどうかを確認します。 これにより、インストールされたプラグインが安全に使用でき、ソースコードがそのままであることが保証されます。

修正された課題

TeamCity 2021.1 リリースノートを参照してください。

アップグレードノート

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

以前のリリース

• TeamCity 2020.2 の新機能

• TeamCity 2020.1 の新機能

• TeamCity 2019.2 の新機能

• TeamCity 2019.1 の新機能

ロードマップ

今後の更新について詳しく見るには、 TeamCity ロードマップを参照してください。