TeamCity 2020.2 ヘルプ

TeamCity 2019.2 の新機能

新しい柔軟なクリーンアップルール

自動ビルドクリーンアップは、初期バージョン以降、TeamCity に存在していました。古い、不要なビルドデータを簡単に削除できます。提供されたカスタマイズオプションは非常に簡単に構成できますが、最も一般的なケースのみを対象としており、微調整はできません。

With this release, we are introducing more options for flexible control of the clean-up process. In addition to existing "base rule" for a project or build configuration, you can now create multiple "keep rules" to specify what builds and data to preserve during the clean-up. The keep rules are more fine-grained and can cover cases like keeping all the builds with a certain tag (for example, release ) or in a certain branch. While using the new keep rules requires a better understanding of different kinds of builds and their data, it also offers greater flexibility.

プロジェクト設定クリーンアップ規則セクションを使用すると、現在のプロジェクトとそのサブプロジェクトとビルド構成の基本ルールと保持ルールを管理できます。

Clean-Up Rules page

キープルールを追加するときに、次を指定できます。

  • 保存するデータを作成する : 履歴、アーティファクト、ログ、統計、またはすべて。

  • ビルド範囲 : ルールの影響を受ける時間間隔または最後のビルドの数。

  • Optionally, filter the builds by their status, tags, and branches. Choose if to limit the builds to personal or non-personal only.
    You can also choose if the rule is applied per each matching branch individually or to all the builds in the selected branches as a single set.

キープルールの例:

Keep Rule example

さらに読む掃除

メトリックスレポート

TeamCity は、診断 | メトリクスタブに表示されるプロメテウス (英語) -compatible サーバーメトリックスを提供し、app/metrics API エンドポイントを介して利用可能になりました。

To access the metrics, make sure your TeamCity user account has the "View usage statistics" permission assigned to it.

メトリックには以下が含まれます。

  • CPU、メモリ、システムの負荷

  • ビルドキューの処理にかかった時間

  • アクティブなユーザーセッションの数

  • そして詳細

完全なリストは https://<teamcity-server-host>/app/metrics で入手できます。

Some of the metrics are experimental, but you can already access them by adding the ?experimental=true query string to the endpoint URL or enabling "Show experimental metrics" option on the メトリクス tab.

メトリックを収集するには、Prometheus データベースまたはテレグラフ(英語)InfluxDB(英語) の組み合わせを使用することをお勧めします。メトリックを視覚的に表現するには、グラファナ(英語)または他の同様のソリューションを使用できます。

Grafana で表される TeamCity メトリックの例:

Example of TeamCity metrics represented in Grafana

ビルドランナーのスクリプトでのコードのハイライト

コマンド行AntPowerShellDockerNAntRake のスクリプト、および Amazon EC2 イメージの構成に対して、自動コードハイライトと行番号付けを追加しました。

読みやすくするために、入力フォームの横にある code-wrap-icon.png をクリックして、コードにソフトラップを適用できるようになりました。

TeamCity での Dockerfile ハイライトの例:

Example of Dockerfile highlighting in TeamCity

EC2 起動テンプレートのサポート

TeamCity は、クラウドインスタンスの Amazon EC2 起動テンプレート(英語)をサポートするようになりました。多くの EC2 ユーザーは、すべての新しいインスタンスに対して一度定義された起動仕様を再利用できるため、起動テンプレートを高く評価しています。これにより、新しいインスタンスが要求されるたびに起動設定を記述する必要がなくなります。

If your cloud profile is connected to the Amazon server, TeamCity will automatically detect launch templates available on this server. Simply select a template as an image Source and specify its version, and TeamCity will request instances based on the template parameters.

さらに読む Amazon EC2 用の TeamCity のセットアップ

TeamCity 起動時のバックアップの復元

TeamCity サーバーインスタンスを初めて起動し、以前の TeamCity インストールのバックアップデータを復元する場合、起動画面の UI から直接バックアップを復元できます。

Automatic backup restore

さらに読むバックアップからの TeamCity データの復元

統合された差分での個人ビルドの実行

これで、TeamCity UI または REST API を介してアップロードされた差分パッチに基づいて、ローカルの変更を含むパーソナルビルドを実行できます。

以前は、TeamCity サーバーをサポートされている IDE と統合することによってのみ、ローカルの変更に基づいて個人用ビルドを実行できました。これで、パッチを .diff ファイルとして統一形式で保存し(たとえば、IntelliJ IDEA または git diff コマンドを使用)、サーバーに直接アップロードできます。

パーソナルビルドのこの機能の詳細を参照してください。

これは実験的な機能であることに注意してください。TeamCity は、Git および IntelliJ IDEA によって生成された unidiff ファイルの安定した解析を提供します。非バイナリファイルでのバイナリ変更はサポートされていません。

クラウドプロファイル用の拡張 REST API

TeamCity REST API now provides the .../app/rest/cloud/profiles.../app/rest/cloud/images.../app/rest/cloud/instances endpoints that expose the same cloud integration details as those provided in the TeamCity UI. Read more in REST API.

プルリクエストの定義済みビルドパラメーター

プルリクエストに関する重要な情報を公開するために、いくつかの定義済みビルドパラメーターを追加したため、ビルド構成の設定またはビルドスクリプトで使用できます。

teamcity.pullRequest.number //pull request number teamcity.pullRequest.title //pull request title teamcity.pullRequest.source.branch //VCS name of the source branch; provided only if the source repository is the same as the target one teamcity.pullRequest.target.branch //VCS name of the target branch

クロスプラットフォーム dotCover のサポート

TeamCity では、クロスプラットフォーム JetBrains dotCover バージョン 2019.2.3+ をサポートすることにより、Linux および macOS 上の .NET Core プロジェクトのコードカバレッジを収集できるようになりました。

dotCover 2019.2.3 for Windows は TeamCity にバンドルされています。Windows 以外のプラットフォームでコードカバレッジを収集する必要がある場合は、管理 | ツールでクロスプラットフォーム dotCover ツールを追加し、.NET CLI ビルドステップで dotCover カバレッジを有効にします。Windows でもクロスプラットフォーム dotCover を使用する場合は、エージェントに .NET フレームワーク SDK 4.6.1+ がインストールされていることを確認してください。

また、Docker ラッパー拡張を使用して、Docker コンテナー内の dotCover でコードカバレッジ分析を実行できます。

マルチノードセットアップの更新

セカンダリノードでのユーザーレベルのアクション

TeamCity の以前のバージョンでは、セカンダリノードは読み取り専用インターフェースを提供していました。ビルドをキューに追加したり、ビルドをタグ付け / 固定したり、その他のユーザーレベルのアクションを実行したりすることはできませんでした。このリリースでは、変更されます。これで、セカンダリノードに責任が与えられた場合(つまり、読み取り専用サーバーとして機能しない場合)、ユーザーのビルドアクションが有効になります。現在、サポートされているユーザーレベルのアクションは次のとおりです。

  • カスタムまたは個人のビルドを含むビルドのトリガー

  • ビルドを停止する

  • ビルドのピン留め / タグ付け / コメント

  • ビルドを削除する

  • 調査の割り当てとミュートのビルドの問題とテスト

  • ビルドを成功 / 失敗としてマークする

  • ソースのマージとソースのラベル付けアクション

トラッカー TW-62749(英語) でサポートされているアクションの完全なリストを参照してください。

管理者レベルのアクションは、セカンダリノードではまだ使用できません。サーバー構成を変更する必要がある場合は、メインサーバーを使用します。

最適化されたサーバー側パッチがエージェントにダウンロードされます

Since this release, agents can download server-side patches from secondary nodes — not only from the main server, as it was before.

Server-side patches are mostly used when an agent cannot find a VCS client executable (for example, Git or Perforce) on an agent machine. In this case, the agent will request the server to create a patch with VCS changes and send it to the agent. Now, if you assign the " VCS リポジトリのポーリング " and " ビルドによって生成されたデータの処理 " responsibilities to a secondary node, the agents will be able to request patches from this node as well, which significantly reduces the load on the main server.

DSL ベースのプロジェクトの更新

TeamCity Kotlin DSL は、次の更新を受信します。

  • DSL は、ビルドチェーンをパイプラインスタイルで構成する代替方法を提供します(詳細を参照)。

  • TeamCity UI で設定されたコンテキストパラメーターを使用して、DSL 生成動作をカスタマイズできるようになりました(詳細を参照)。

  • If the "Store secure values outside of VCS" option is enabled for a project, TeamCity allows you to see all the project tokens and generate new ones on the バージョン設定 | トークン tab (read more).

テスト運用版 UI の新機能

TeamCity 2019.2 は、再設計されたビルド詳細およびエージェントページ、およびその他の実験的機能を導入しています。

テスト的なビルドの詳細ページ

ビルドの詳細を表示する方法を再考するために、ビルド詳細ページを再設計して、視覚化を改善し、サイドバーを介して他のすべてのプロジェクトにすばやくアクセスできるようにしました。

Experimental Build Details page

現在のビルドページを移動せずに、以前のすべてのビルドとその詳細を即座にプレビューできます。

Build trends preview

視覚化されたビルドタイムラインは、各ステージの期間を反映し、ビルドの問題を示します。

Build timeline

ビルドステージをクリックして、ビルドログの対応する行を開きます。新しい UI では、長いログであっても、ダウンロードする必要がなく、プレビューに直接表示できます。

ビルドタイムラインとビルドログ以外に、概要タブからビルドの問題、テスト、変更、依存関係にすばやくアクセスできます。対応するタブも更新され、新しい機能が提供されるようになりました。

  • 変更タブには、ビルドの変更に関する詳細情報が表示されます。ユーザーとアーティファクトの変更を個別に参照し、オプションでビルド設定の変更を表示できます。変更をクリックして詳細をプレビューします。

    Experimental Changes tab

  • テストタブを使用すると、失敗したテスト、無視されたテスト、成功したテストをすばやく切り替えることができます。テストをクリックして詳細を表示し、調査を割り当てます。

    Experimental Tests tab

  • 依存関係タブには、ビルドの依存関係を表示する 3 つの代替モードがあります。視覚的なタイムライン、構造化リスト、ビルドチェーンです。

    Experimental Dependencies tab

実験エージェントのページ

実験的なエージェントページは、多数のエージェントに対してより高速にロードされ、エージェントの詳細をすばやく切り替えることができます。サイドバーを使用して、エージェントプール階層を参照し、名前でエージェントとプールを検索できます。レポートセクションは、すべてのプールで実行中、アイドル、切断されたエージェントに関する統計を提供します。

Experimental Agents page

テスト運用版 UI のその他の新機能

  • 2 つのビルドの比較
    With the Compare Builds feature, you can select two builds from the same configuration and review information about their parameters, revisions, statistics, and tests side-by-side. This allows for easier monitoring and is especially helpful when multiple users manage and monitor builds. For example, if a build has no changes in the project code but fails for no obvious reason, you can compare this build with the last successful build and analyze their differences to find the most probable cause of the failure.
    To compare a build with another, open the アクション menu of this build, click 比較 , and select a build for comparison.

  • ビルドリストのビルドプレビューを展開
    TeamCity では、ビルドのリストで最も重要なビルド結果を直接プレビューできるようになりました。ビルド構成ホームページで、リストのビルド行をクリックして詳細を表示します。

  • お気に入りプロジェクトセクション
    お気に入りのプロジェクトにすばやくアクセスできるプロジェクトセクションを移行しました。

  • 再設計された変更ポップアップ
    ビルドの変更は時系列でソートされ、コードの変更とアーティファクトの依存関係の変更によってグループ化されます。また、作成者で変更をフィルタリングし、ビルド構成設定で行われた変更の表示を切り替えることもできます。

  • ビルドキューイングの理由に関する情報
    If a build has been staying in a queue for too long, you can now see a reason for the delay by clicking the "In queue" label when previewing the build in トレンド or in the build list.

その他の改善

  • ブランチフィルターが、アーティファクトの依存関係、再試行トリガー、プル要求ビルド機能用に追加されました。

  • Dockerfile の変更の自動検出: Docker Compose ビルドランナーがエージェントで Docker イメージを作成すると、このエージェントに保存され、後のビルドで使用されます。これで、TeamCity は、イメージの作成に使用された Dockerfile が変更されたことを自動的に検出し、Docker Compose ステップにこのイメージの再構築を強制します。

  • サーバー上のすべての VCS ルートの最小ポーリング間隔として、グローバル設定で指定された VCS 変更チェックの間隔を実施できるようになりました。これにより、プロジェクト管理者はデフォルトよりも大きい間隔のみを設定できます。これにより、ポーリング要求の頻度が制限され、サーバーの負荷が軽減されます。

  • Project administrators with the enabled "Change user / group notification rules in project" permission can edit notification rules for users and user groups assigned to their projects.

  • これで、通常のビルドと同様に個人用ビルドを再実行できます。完成したビルドのコンテキストメニューを開き、このビルドを再実行をクリックします。

  • TeamCity can automatically manage the amount of memory used by the git fetch process.
    If you have previously used the teamcity.git.fetch.process.max.memory internal property to set the memory amount available for fetching in each VCS root, you can now disable it to delegate the detection of memory consumption to the TeamCity server. You can control the limit of available memory via the teamcity.git.fetch.process.max.memory.limit property.

  • 1 つのビルドに対して複数の SSH キーを構成できます。ビルドが複数の外部システムまたはリポジトリで認証する必要がある場合に役立ちます。ビルドで複数の SSH キーを使用するには:
    • プロジェクトレベル: これらのキーを SSH キーで指定します。

    • ビルド構成レベルで: キーごとに 1 つずつ、複数の SSH エージェントビルド機能を追加します。

  • TeamCity は、割り当てられた調査を解決するために改善されたルールを使用し、アクティブなブランチでミュートされた問題とテストをミュート解除します。現在、ビルドの問題(または失敗したテスト)がすべてのアクティブブランチで修正されるまで待機してから、ミュートを解除するか、調査を解決します。

  • 再試行ビルドトリガーは、同じリビジョンの新しいビルドをトリガーし、キューの先頭に配置できるようになりました。

修正された問題

修正された問題の全リスト (英語)

アップグレードノート

2019.1.x から 2019.2 への変更

以前のリリース

TeamCity 2019.1 の新機能

関連ページ:

クリーンアップ

TeamCity のクリーンアップ機能により、古いビルドデータや不要なビルドデータを自動的に削除できます。サーバーのクリーンアップ構成は管理 | サーバー管理 | クリーンアップ設定で使用可能です。クリーンアップスケジュールの設定が可能で、一般的なクリーンアップ情報が表示されます。特定のプロジェクトに関連するクリーンアップルールは、プロジェクト設定 | クリーンアップ規則で構成されます。これらのルールは、どのデータをクリーンアップし、何を保存するかを定義します。これらは、プロジェクトまたはビルド...

コマンド行

コマンドラインビルドランナーを使用すると、OS でサポートされている任意のスクリプトを実行できます。コマンドラインランナー設定:一般設定作業ディレクトリコマンドを実行する作業ディレクトリを指定します(ビルドチェックアウトディレクトリと異なる場合)。実行モードを指定します: パラメーターを指定して実行可能ファイルを実行するか、カスタムシェル / バッチスクリプトを実行します(以下を参照)。コマンド実行可能このオプションは、実行ドロップダウンメニューでパラメーターで実行可能が選択されている場合に使...

Amazon EC2 用の TeamCity のセットアップ

TeamCity Amazon EC2 統合により、Amazon アカウントで TeamCity を構成し、キューに入れられたビルドに基づいて TeamCity エージェントでオンデマンドでイメージを開始および停止できます。他のクラウドソリューションとの統合が可能です。概要:マシンイメージは、起動時に TeamCity エージェントを開始するように事前設定されていることが前提となっています(詳細を参照)。TeamCity で 1 つまたは複数のイメージを使用してクラウドプロファイルを構成すると...

パーソナルビルド

パーソナルビルドは、通常、バージョン管理にまだコミットされていない変更を使用する一般的なビルドシーケンスのビルドアウトです。パーソナルビルドは通常、サポートされている IDE の 1 つからリモート実行手順を介して開始されます。以下に説明するように、変更を加えたパッチをサーバーに直接アップロードすることもできます。パーソナルビルドは、現在の VCS リポジトリソースと、リモートの実行開始時に識別された変更されたファイルを使用します。パーソナルビルドの結果は、対応する IDE プラグインのマイチェン...

セカンダリノードの設定

メインの TeamCity サーバーに加えて、データディレクトリと外部データベースをメインサーバーと共有するセカンダリサーバー(ノード)を起動できます。詳細については、マルチノード設定を参照してください。このページでは、セカンダリノードの構成方法について説明します。TeamCity 2019.2 以降、ビルドノードの実行は 2 次ノードのために廃止されることに注意してください。詳細はマルチノード設定を参照してください。セカンダリノードのインストール:セカンダリノードをインストールするには、セカ...

ビルドチェーン

ビルドチェーンは、スナップショットの依存関係によって相互接続された一連のビルドです。ビルドチェーンは「パイプライン」と呼ばれることもあります。リビジョンの同期が有効になっているスナップショットの依存関係にリンクされたビルドチェーンの一部は、ソースの同じスナップショットを使用します。一般的なユースケース:ビルドチェーンを指定するための最も一般的な使用例は、異なるプラットフォームでプロジェクトの同じテストスイートを実行することです。例: リリースビルドの前に、テストがさまざまなプラットフォームや環境...