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 (英語) コマンドを実行し、詳細なテスト結果をレポートできます。

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

プロジェクトに ESlint(英語)、Jest(英語)、または Mocha(英語) 依存関係がある場合、TeamCity はビルド概要にそれぞれのテスト結果を表示します。

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

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

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

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

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

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

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

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

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

この機能は、ビルドステップの実行条件と組み合わせるとさらに効果的です。パラメーターベースの条件をステップに追加して、2 つのトリガーを設定するだけです。1 つはこのステップでビルドを実行し (条件が満たされたとき)、もう 1 つはそれなしでビルドを実行します。一般的な使用例は、失敗したビルドが再試行トリガーで再起動されたときに追加のクリーンアップ手順を実行することです。これは、ユーザーが関与しなくても、多くのビルドの問題を解決できます。

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

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

実行時にノードをセカンダリからメインに切り替える

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

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

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

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

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

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

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

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

Elastic に基づく新しい検索モード

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

新しいモードには 2 つの利点がある: (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 から直接ワークスペースをクリーンアップできます。

これを構成するには、TeamCity のプロジェクト設定に移動し、接続に、Perforce 管理者アクセスタイプの新しい接続を追加します。Perforce サーバーにアクセスするためのホストとユーザーの資格情報を入力すると（ユーザーには管理者権限(英語)が必要です）、TeamCity がそれに接続します。

clean-up ごとに、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 に保存されている共通プロジェクトのコードを実際に変更することなく、ローカルの変更でカスタムビルドを実行できます。このようなビルドを実行するには、IDE でリモート実行を使用するか、UI または REST API を介してアップロードすることにより、変更を加えたパッチを TeamCity サーバーに送信する必要があります。このパッチはビルドエージェントマシンに配信され、カスタムビルドでのみ使用されます。ただし、パッチはエージェントファイルシステムに保存されるため、信頼できる変更のみを含めるようにするのが賢明です。これにより、このエージェントで実行される次のビルドに害を及ぼす可能性はありません。

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

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

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

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

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

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

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

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

• ミラーの使用 : 多数のビルドを実行する長期間有効なエージェントに最適です。リポジトリミラーはエージェントに保持され、後続のビルドを高速化します。

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

• 浅いクローン : 有効期間の短いエージェント (たとえば、クラウド内の使い捨てエージェント) に最適です。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 ステップは、ヴェンヴ(英語)仮想環境内で実行できます。

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

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

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

修正された問題

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

アップグレードノート

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

以前のリリース

• TeamCity 2020.2 の新機能

• TeamCity 2020.1 の新機能

• TeamCity 2019.2 の新機能

• TeamCity 2019.1 の新機能

ロードマップ

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